The only way I found was to go with a JASPI auth module.

https://community.jboss.org/wiki/JBossAS7EnablingJASPIAuthenticationForWebApplications

I extended the org.jboss.as.web.security.jaspi.modules.WebServerAuthModule class and overrode the validateRequest method.  JASPI requires that the request and response are available in the messageInfo.

    @Override

    public AuthStatus validateRequest(MessageInfo messageInfo, Subject clientSubject,

            Subject serverSubject) throws AuthException {

        log.trace("valdidateRequest");

        Request request = (Request) messageInfo.getRequestMessage();

        Response response = (Response) messageInfo.getResponseMessage();

        ...

The side affect of this was that JASPI is implemented with a valve which means the jboss-web.xml will have to reference the JASPI authenticator you want to use since AS 7 does not let you define a valve that gets applied to all deployed web apps.

This looks like I will have to add JBoss Specific code to my application, yes?

No jboss code in your application.

Or at least classes that the jboss-web.xml will refer to.

Yes.  you will write a custom JASPI authenticator and reference it from the jboss-web.xml.  Keeping the jar in a module separate from your app fine.  Note that this is different from a JAAS custom login module.  The JAAS login module stack will be invoked in the authenticate method of your custom JASPI authenticator.  You will have access to the http request and response both before and after the actual authentication happens via the JAAS login module stack, but not during the execution of the login modules themselves. Not sure if this will work for your particular situation.  If not I recommend looking at thread local to pass around the info you need and I apologize for taking you down the wrong path.  It was how I solved the problem but the more I think about it my use case is probably much different from yours.

Can you give me some further information on how To acheive this?

For an example check out the code for the JASPI authenticator referenced in the valve in the documentation mentioned previously. (org.jboss.as.web.security.jaspi.WebJASPIAuthenticator)  You probably just want to extend the WebJASPIAuthenticator and override as needed.

I need a Custom AuthModule?

Yes and no assuming you are referring to a JASPI Server Auth Module.  You need one but JBoss AS 7 provides it already.  Your custom JASPI authenticator will use it.  See the org.jboss.as.web.security.jaspi.modules package.

That bit you put in will put the request/response in context for my login module?

No, its available in the JASPI authenticator.  Though I'm sure you could make it available using thread local or a callback.  If you did that though... might be easier to stick with the older catalina authenticator valve which there are lots of examples for on the web.

Do I need a custom AUthenticator as well?

Yes, most likely an authenticator that extends WebJASPIAuthenticator and is referenced by the valve defined in your jboss-web.xml.

If you don't find a solution be sure to open a feature request.  And if you have an EAP subscription be sure to open a case with Redhat.  I know other major JEE vendors provide JAAS callback handlers for the http request/response.  Very useful if JBoss did too.

I'm looking to augment my LoginModule to support SSO with Crowd.  My Token comes back from the authentication logic and to persist that to a cookie I'd need (from what I can see) access to the Request/Response within the LoginModule.  Based upon your description I do not think that a JASPI implementation is going to help me.

This is similar to what I had to do but with a SAMLSessionToken authenticating with a SAML IDP.  Moved the authentication logic into the JASPI server auth module in order to be able to set the token on the response.  I never found a means to access the response in the JAAS login module.  Could only get the request in a login module using the PolicyContext.

I was interested in the Callback Handler approach.  if you look at the thread in my first response, you could access the request through the PolicyCOntext prior to Jboss 7 but there is a new approach.  I haven't been able to find helpful documentation on how to us SubjectPolicyContextHandler or CallbackHandlerPolicyContextHandler to see if that is a solution that would help.

The PolicyContext is part of the JACC spec.  To learn more about the SubjectPolicyContextHandler and/or CallbackHandlerPolicyContextHandler check out the JACC spec http://jcp.org/jsr/detail/115.jsp   The spec requires a HttpServletRequestPolicyContextHandler.  The post you referenced is over a year old and the HttpServletRequestPolicyContextHandler is now in the org.jboss.as.web.security package.  Have you  tried:

HttpServletRequest request = (HttpServletRequest) PolicyContext.getContext("javax.servlet.http.HttpServletRequest");

However there is no HttpServletResponsePolicyContextHandler to get the http response to set the cookie.  So not sure a PolicyContextHandler is going to get you what you need.

Now you are are discovering why I went with a JASPI auth module.  You can do what you need with the token and still invoke the login module stack.

I'm not sure how This is going to work.  I get my SSO token returned to me within my Login module.

If you must get and set the token in the login module then the custom authenticator will need to make the response object available to the login module.  The only way to do this in JBoss that I am aware of is with a ThreadLocal variable.

private static final ThreadLocal<Response> activeResponse = new ThreadLocal<Request>();

Before calling "super.authenticate(request, response, config)" set the response on the ThreadLocal.


  activeRespose.set(respose);

Give a static public method to expose the response.

public static Response getActiveRespose() {

        return activeResponse.get();

    }

In a finally block after the call to super.authenticate remove the threadlocal reference so you don't introduce a thread leak.

finally{

  activeResponse.set(null);

}

In your login module reference the response by calling the public static method of the authenticator.

CustomAuthenticator.getActiveResponse()

With that said let me add my disclaimer.  I have not tried this in JBoss 7 so I don't know if the new modular architecture will cause any headaches or not.  In addition I personally don't like using authenticators this way because now the login module is dependent on your application config.  Fine if you are in control of both and willing to manage it but this has never been a luxury for me.

If I were in your shoes I would patch the org.jboss.as.web.security.SecurityContextAssociationValve to expose the response similar to what it currently does with the request in order to make it available for the JACC PolicyContext.  This would free you from having to define valves in all your web apps.  Then open a feature request and reference all the forum posts talking about this exact topic.  If your company has an EAP subscription escalate it through your Redhat rep.