Jaspic ServerAuthModule delegating to JAAS Krb5Log

Question

I have to write a custom Jaspic ServerAuthModule (which needs to add a proprietary Authentication Cookie to the HTTP Response AND HTTP Request to be propagated to the applications running on the App Server). The Authentication must be done using Kerberos, SPNEGO.

The Application Server to be used is JBOSS EAP 6.4.x

I managed to get the Authentication using the JAAS Krb5LoginModule working.

The JBOSS EAP Standone.xml I use:

  <security-domain name="host" cache-type="default">
    <authentication>
      <login-module code="com.sun.security.auth.module.Krb5LoginModule" flag="required">
          <module-option name="debug" value="true"/>
          <module-option name="principal" value="HTTP/[e-mail]"/>
          <module-option name="storeKey" value="true"/>
          <module-option name="useKeyTab" value="true"/>
          <module-option name="doNotPrompt" value="true"/>
          <module-option name="keyTab" value="/Users/jet/Downloads/kerberos/macbookAirRCH.keytab"/>
      </login-module>
    </authentication>
  </security-domain>
  <security-domain name="SPNEGO" cache-type="default">
    <authentication>
      <login-module code="SPNEGO" flag="required">
          <module-option name="serverSecurityDomain" value="host"/>
      </login-module>
    </authentication>
    <mapping>
      <mapping-module code="SimpleRoles" type="role">
          <module-option name="[e-mail]" value="User,Admin"/>
      </mapping-module>
    </mapping>
  </security-domain>

jboss-web.xml:

 <jboss-web>
   <security-domain>SPNEGO</security-domain>
   <valve>
       <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name>
   </valve>
   <context-root>kerberosREST</context-root>
 </jboss-web>

I also managed to get a customized JASPI Module working (extends org.jboss.as.web.security.jaspi.modules.WebServerAuthModule) using the following configuration:

<security-domain name="testDomain" cache-type="default">
   <authentication-jaspi>
      <login-module-stack name="lm-stack">
         <login-module code="SPNEGO" flag="required">
            <module-option name="serverSecurityDomain" value="host"/>
         </login-module>
      </login-module-stack>
      <auth-module code="ch.test.jaspic.CustomServerAuthModule" flag="required" login-module-stack-ref="lm-stack"/>
    </authentication-jaspi>
       <mapping>
          <mapping-module code="SimpleRoles" type="role">
             <module-option name="[e-mail]" value="User,Admin"/>
             </mapping-module>
          </mapping>
 </security-domain>

jboss-web.xml:

<jboss-web>
   <security-domain>testDomain</security-domain>
   <valve>
       <class-name>org.jboss.as.web.security.jaspi.WebJASPIAuthenticator</class-name>
   </valve>
   <context-root>kerberosREST</context-root>
</jboss-web>

How can I use the default JAAS Krb5LoginModule?

Should I include the two valves in the jboss-web.xml? (the order is important)

jboss-web.xml:

<jboss-web>
   <security-domain>testDomain</security-domain>
   <valve>
       <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name>
   </valve>
   <valve>
       <class-name>org.jboss.as.web.security.jaspi.WebJASPIAuthenticator</class-name>
   </valve>
   <context-root>kerberosREST</context-root>
</jboss-web>

Many thanks in advance

Answer 1

The Application Server to be used is JBOSS EAP 6.4.x

Unfortunately JASPIC isn't implemented very well on this version of JBoss. JBoss EAP 7 will be fine and should be released (if all goes well) this year or perhaps early next year (but nobody knows, not even the people at JBoss). There are several betas of EAP 7 out, the latest one is called JBoss WildFly 10 and a slightly earlier is called EAP 7 beta 1.

In general, there's a JAAS bridge where you let your JASPIC SAM call your JAAS Login Module. You need to understand that a JASPIC SAM is the authentication mechanism and the JAAS Login Module is the identity store.

I'm pretty sure you do not need the JBoss specific configuration of the JAAS Login Module. That is only needed to let JBoss internal code (e.g. their implementation of the Servlet FORM authentication mechanism) find that module.

If JASPIC is used, the SAM is in control.

For the bridge profile, see this article for more info:

https://blogs.oracle.com/nasradu8/entry/loginmodule_bridge_profile_jaspic_in

Answer 2

To my (little) understanding, Valves are, roughly speaking, a lower-level, container-specific and container-wide Servlet Filter counterpart. Therefore what you are trying to do should indeed work with the pipeline (Valve sequence) presented in your question. When NegotiationAuthenticator has completed the actual authentication, WebJASPIAuthenticator--the ServerAuthModule (SAM) ultimately delegated to by it--would check whether an authenticated caller Krb5Principal (or whatever Principal JBoss wraps it with) has been associated with the request by the former, and set the cookies accordingly.

I wonder why you are even willing to use JASPIC merely for setting cookies though, when you could just use a simple Filter instead (and get rid of some of that JBoss-specific configuration as a bonus). Or you could alternatively, if you were willing to give up any trace of authentication mechanism portability, try to extend NegotiationAuthenticator, overriding its authenticate(...) method and setting the cookies from there, depending on the outcome of a delegation to the overriden implementation.

And finally there's the proper (albeit harder) vendor-neutral approach, where you would drop NegotiationAuthenticator and re-implement its functionality as a SAM. Who knows--an open-source SPNEGO SAM might even exist somewhere out there. For Kerberos authentication you could reuse the existing Krb5LoginModule¹, by delegating to it--as dexter meyers wrote--in accordance with JASPIC's LoginModule Bridge Profile (chapter 6 of the specification). LoginModules (LMs) are of course not supposed to be used directly, but via LoginContexts, which in turn need some Configuration to find the right LM through and initialize it with. Whether you are going to reuse JBoss's Configuration (and therefore retain the respective proprietary XML), provide your own persistent representation, or just hard-code it in a custom LoginContext / Configuration is your choice.

_{¹ Ideally you would re-implement the LM too, perhaps in a second SAM, orchestrating calls to the two from a separate ServerAuthContext. Doing so would reduce the proprietary authentication-related configuration to zero, at the cost of added complexity and code to maintain.}