<< Back to previous view

[JASPIC_SPEC-12] Leverage SAML Web SSO from Nobis in JASPIC TCK Created: 14/Nov/12  Updated: 08/Mar/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: JeffTancill Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 2 weeks
Time Spent: Not Specified
Original Estimate: 2 weeks

Tags:
Participants: JeffTancill

 Description   

The Nobis project is the RI for JSR-351. It also contains the SAML Web SSO implementation that will be leveraged within the JASPIC TCK in order to do two things:
1) Ensure that an actual and useful SAM can be configured for use within an application server implementation using standard mechanisms. To date the TCK has only tested spec compliance with a special set of implementation classes that ensure that the correct APIs are being called at the correct times

2) Ensure that Java EE 6+ environments are capable of participating in three party authentication exchanges and enterprise SSO products
the current implementation encompasses the resource first usecase wherein the resource is requested first and the user is redirected to the configured IDP for authentication

The TCK will need to acquire the appropriate implementation from Nobis, make it available in the system classpath for the appserver being tested
and configure it for use within the system and for a particular application.






[JASPIC_SPEC-1] AppContextID of Servlet profile includes name of virtual host; for which Servlet provides no portable api Created: 13/Feb/13  Updated: 09/Mar/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: monzillo Assignee: monzillo
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms and monzillo

 Description   

During programmatic AuthConfigProvider registration - especially
self-registration via

AuthConfigFactory.registerConfigProvider(AuthConfigProvider provider,
String layer,
String appContextID,
String description);

the AuthConfigProvider has no portable way to determine the name of the virtual
host, and thus to register using the same virtual host name that will be used
by the runtime in its call to

AuthConfigFactory.getConfigProvider(String layer, String appContextID,
RegistrationListener listener);

Servlet 3.1 does not intend to provide a portable api by which the name of the
virtual host can be obtained.

this problem was first reported by Arjan Tijms



 Comments   
Comment by arjan tijms [ 09/Mar/13 12:08 AM ]

I just read that the MR document at http://jcp.org/aboutJava/communityprocess/maintenance/jsr196/standard_appContextID_generation.pdf

Mentions the following:

A Servlet container that implements a version of the Servlet specification that defines the getVirtualServerName method on the ServletContext interface, must construct its application context identifiers using a value for hostname that is equivalent to the value returned by calling getVirtualServerName on the ServletContext corresponding to the web application.

I couldn't however find a method called getVirtualServerName on ServletContext. I checked javax.servlet-api-3.1-pdr-javadoc, but it doesn't seem to be there. Is this a method planned for the future?

Comment by arjan tijms [ 09/Mar/13 09:59 AM ]

Even though the method does not seem to appear in the PDR javadoc, I found one reference to it here: GLASSFISH-19814, so it does seem to be a Servlet 3.1 method





[JASPIC_SPEC-2] AuthConfigFactory javadoc indicates methods throw AuthException but method signatures do not Created: 13/Feb/13  Updated: 13/Feb/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: monzillo Assignee: monzillo
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: monzillo

 Description   

avadoc of four AuthConfigFactory methods indicate that they throw
AuthException (which is a checked exception) but method signatures do not
declare that they throw AuthException, and thus the exception cannot be thrown.
Moreover, the inability to throw this exception, makes it unclear how errors
are to be signaled by these methods.

public static AuthConfigFactory getFactory();

public abstract java.lang.StringregisterConfigProvider(
java.lang.String className,
java.util.Map properties,
java.lang.String layer,
java.lang.String appContext,
java.lang.String description);

public abstract java.lang.String registerConfigProvider(
AuthConfigProvider provider,
java.lang.String layer,
java.lang.String appContext,
java.lang.String description)

public abstract void refresh()

javadoc if refresh method of AuthConfig interface also indicates that it throws
AuthException although method signature does not declare that it does.

javadoc if refresh method of AuthConfigProvider interface also indicates that
it throws AuthException although method signature does not declare that it
does.






[JASPIC_SPEC-3] No portable way for auth module to ask the container to create a container authentication session Created: 13/Feb/13  Updated: 13/Feb/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: monzillo Assignee: monzillo
Resolution: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms and monzillo

 Description   

The spi is optimized for the case where the auth module is responsible for
creating and managing authentication sessions internally and separate from
Servlet's HttpSession machinery.

Still there are repeated requests for this enhancement. The RI provides this
functionality via an undocumented messageInfo flag; which when set by an auth
module, instructs the Glassfish container to "register" and authentication
session.

The enhancement request is to standardize a portable means for an auth module
to cause the encompassing container to create an authentication and to bind it
to the response. This might be done by a flag, or by a new Callback handler, or
perhaps by another mechanism.



 Comments   
Comment by arjan tijms [ 13/Feb/13 11:39 PM ]

Maybe interesting to know that JBoss AS/EAP always "remembers" the authentication automatically. There does not seem to be a way to not let the container remember the authentication. WebLogic remembers the principal (obtained via HttpServletRequest.getUserPrincipal), but doesn't grant access to protected resources if the auth module doesn't authenticate again at the start of a (new) request.

GlassFish, Geronimo and WebSphere all don't seem to remember anything between requests.

A clarification in the spec could be that without the portable mechanism that's proposed for this issue the container should not remember anything (leaving the auth module fully responsible) and that with this mechanism the container should remember the full authentication between followup requests until either the http session times out or is explicitly ended (implying authentication session is bound to the http session), or HttpServletRequest.logout is called.





[JASPIC_SPEC-4]  servlet profile does not profile the use of the spi under HttpServletRequest#authenticate Created: 13/Feb/13  Updated: 13/Feb/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: monzillo Assignee: monzillo
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: monzillo

 Description   

when jsr 196 is configured for a Servlet application, the jsr 196 configuration
must be applied when HttpServletRequest#authenticate is called.

In that case, a call to HttpServletRequest#login must throw an exception since
the configured authentication mechanism may not be password based.

the servlet profile must also define what happens when
HttpServletRequest#logout is called






[JASPIC_SPEC-5] Portable way to distinguish between invocation at start of request and invocation following authenticate() call Created: 13/Feb/13  Updated: 27/Feb/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: monzillo
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms and monzillo

 Description   

The validateRequest method of an auth module can be called at the "start" of an HTTP request (before the target resource or any servlet filters are invoked), or it can be called following a call to the Servlet 3.0 HttpServletRequest.authenticate() method.

In some cases it may be necessary for the auth module to distinguish between these cases. One use case is that following a call to HttpServletRequest.authenticate(), the auth module fully runs within the context of the calling code. E.g. if the calling code is a CDI bean backing a JSF view, then both the CDI contexts as well as the Faces context are available to the auth module. An auth module that is created specifically for CDI/JSF may take advantage of this.

It might thus be convenient to have a portable way for the auth module to find out at which of those two different points it's invoked.

Note that WebSphere 8.5 solves this issue by putting a key com.ibm.websphere.jaspi.request in the MessageInfo map, with authenticate as value (see http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphere.nd.doc%2Fae%2Ftsec_jaspi_create.html step 4).



 Comments   
Comment by monzillo [ 27/Feb/13 03:59 PM ]

Perhaps WebSphere added their flag to ensure that authentication would be mandatory, even if the policy of the auth context is not; the new "subprofile for authenticte, etc" deals with that problem by requiring that the isMandatory flag be set in MessageInfo.

that said, I can see how being able to tell distinguish such cases could be useful, so I will add an ability to do so to the sub-profile. thanks for the suggestion.





[JASPIC_SPEC-7] Support for RequestDispatcher#forward in auth module Created: 17/Feb/13  Updated: 28/Feb/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: monzillo
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms and monzillo

 Description   

In the Servlet Container Profile of JASPIC, a RequestDispatcher can be obtained from the request message in the ServerAuthModule.validateRequest method, and subsequently used to forward to a specific resource.

The fact that this can be done is not described in the JASPIC specification, and in practice not all currently certified JASPIC implementations are capable of handling this.

E.g. consider the following fragment in a ServerAuthModule.validateRequest implementation:

HttpServletRequest request = (HttpServletRequest) messageInfo.getRequestMessage();
HttpServletResponse response = (HttpServletResponse) messageInfo.getResponseMessage();

RequestDispatcher requestDispatcher = request.getRequestDispatcher("/index.xhtml");
requestDispatcher.forward(request, response);

return AuthStatus.SEND_CONTINUE;

(index.xhtml is a JSF Facelets page backing by a CDI backing bean)

This works is GlassFish 3.1.2.2 and Geronimo V3.0, but fails in some way or the other on JBoss AS 7.1.3/EAP 6.0.1, WebLogic 12.1.1 and WebSphere 8.5.

On JBoss EAP 6.0.1 the following exception is immediately thrown when invoking the forward() method:

 An exception or error occurred in the container during the request processing: 
java.lang.ClassCastException: org.apache.catalina.connector.Request cannot be cast to javax.servlet.ServletRequestWrapper
	at org.apache.catalina.core.ApplicationFilterFactory.createFilterChain(ApplicationFilterFactory.java:164) [jbossweb-7.0.17.Final-redhat-1.jar:]
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:827) [jbossweb-7.0.17.Final-redhat-1.jar:]
	at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:622) [jbossweb-7.0.17.Final-redhat-1.jar:]
	at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:560) [jbossweb-7.0.17.Final-redhat-1.jar:]
	at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:488) [jbossweb-7.0.17.Final-redhat-1.jar:]
	at jaspic.TestServerAuthModule.validateRequest(TestServerAuthModule.java:120) [classes:]

On WebLogic 12.1.1. the following exception is immediately thrown:

javax.servlet.ServletException: Must call associate() before calling activate()
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:606)
	at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:242)
	at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:216)
	at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:132)
	at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:338)
	at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:221)
	at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:564)
	at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:263)
	at jaspic.TestServerAuthModule.validateRequest(TestServerAuthModule.java:120)

On WebSpere 8.5 the following exception is thrown after the auth module returns:

0000006c WebCollaborat A   
SECJ0056E: Authentication failed for reason Jaspi authentication failed, unexpected HttpServletResponse status: 200
0000006c webapp E com.ibm.ws.webcontainer.webapp.WebApp logServletError 
SRVE0293E: [Servlet Error]-[servlet.TestServlet]: 
java.lang.IllegalStateException: Response already committed.
	at com.ibm.ws.webcontainer.webapp.WebAppDispatcherContext.sendError(WebAppDispatcherContext.java:599)
	at com.ibm.ws.webcontainer.webapp.WebAppDispatcherContext.sendError(WebAppDispatcherContext.java:656)
	at com.ibm.ws.webcontainer.srt.SRTServletResponse.sendError(SRTServletResponse.java:1255)
	at com.ibm.ws.security.web.WebReply.sendError(WebReply.java:61)
	at com.ibm.ws.security.web.DenyReply.writeResponse(DenyReply.java:35)
	at com.ibm.ws.security.web.EJSWebCollaborator.handleException(EJSWebCollaborator.java:735)
	at com.ibm.ws.webcontainer.collaborator.WebAppSecurityCollaboratorImpl.handleException(WebAppSecurityCollaboratorImpl.java:267)
	at com.ibm.wsspi.webcontainer.collaborator.CollaboratorHelper.processSecurityPreInvokeException(CollaboratorHelper.java:153)

On WebSphere 8.5 the forwarded resource is processed correctly. After some experimentation, it seems WebSphere 8.5 only allows http status codes 302, 303, 307 and 401 after an auth module returns SEND_CONTINUE. On WebLogic, the forward does work when the application hasn't activated CDI (e.g. when no beans.xml is present in WEB-INF). On JBoss EAP, forwarding works if the request is casted to a proprietary type and the result of a getRequest() call is provided to the dispatcher.

Since all the mentioned implementations are Java EE 6 certified, the JASPIC spec probably has to be clarified here and if possible a TCK test for this should be added.

Since forwarding can be an important use case, e.g. for displaying a login form as response to the original request, I would like to request that forwarding is being covered by the JASPIC spec. Specifically:

  • Specify that forwarding is a supported operation
  • Specify which status the auth module should return when forwarding
  • Specify which HTTP response codes are legal following a SEND_CONTINUE return value (perhaps there should be no limitation?)
  • Add a TCK test in which an auth module does a forward (if possible for a TCK: forward to a complex resource like a JSF page, with CDI being enabled, and where the JSF page uses a CDI backing bean)


 Comments   
Comment by monzillo [ 27/Feb/13 04:38 PM ]

I think the websphere implementation is probably most correct (in terms of what the spec currently requires, as
they are apparently enforcing the following for SEND_CONTINUE -

"The module must have set the HTTP status code of the response to a value (for example, HTTP 401 unauthorized, HTTP 303 see other, or HTTP 307 temporary redirect) that will indicate to the client that it should retry the request."

I will add a clarification in the section around SEND_CONTINUE, but we will have to better understand all the ramifications of doing forwards, from auth modules before I will be able to require support for doing so. I will add some mention of being able to do forwards for example to a login form, to raise awareness.

is redirecting to the login-form a suitable work-around?

Comment by arjan tijms [ 27/Feb/13 09:46 PM ]

I will add a clarification in the section around SEND_CONTINUE, but we will have to better understand all the ramifications of doing forwards, from auth modules before I will be able to require support for doing so. I will add some mention of being able to do forwards for example to a login form, to raise awareness.

Okay, that would be great. I agree that if it's not fully clear what impact forwards can have that this should be investigated first. I did notice that JBoss ships a JASPIC module that mimics the Servlet form based authentication, and uses a forward for this (they use proprietary API for this though). It's at org.jboss.as.web.security.jaspi.modules.HTTPFormServerAuthModule.

is redirecting to the login-form a suitable work-around?

It's a workaround for sure. And we have indeed used this for a SAM.

A forward is more natural though for those use cases where the session can't be used to temporarily store data from the original request like headers, (post) parameters, cookies, and such. With a forward this data could be passed to the login form within the same request. The login form can then render this (encoded and encrypted if necessary) in a hidden field, so it can be posted back when the user authenticates. Theoretically this could be done via one huge GET request parameter, but that's not really ideal.

Comment by monzillo [ 28/Feb/13 04:37 PM ]

I am thinking that the servlet profile needs to allow for a third case, that where validateRequest is called before the service invocation and returns after the effective service invocation; which is one way to look at what happens when an auth module does a forward.

In that case, the module could return SEND_SUCCESS, which would cause the runtime to skip the authorization check, the dispatch to the component, and the call to secureResponse (as it does when validateRequest is called after the service invocation). In this case, the module would also need to do whatever it would do if secureResponse were to be called.

this can also work beneath authenticate, in which case the runtime knows it is calling validateRequest after the service invocation (and must never dispatch to the component, independent of what the module returns). Perhaps this is another reason why Websphere sets an authenticate indication in MessageInfo, so that the module will know not to return SUCCESS; although I don't think that really matters, since the runtime knows that the call to validateRequest was made in the context of a call to authenticate. As above (in this case, if a forward is done by the auth module, it could return SEND_SUCCESS, and it would need to do whatever secure response processing it would do if secureResponse were to be called.

what do you think, and if you have a chance to try this out let me know what you find

Comment by arjan tijms [ 28/Feb/13 11:00 PM ]

I am thinking that the servlet profile needs to allow for a third case, that where validateRequest is called before the service invocation and returns after the effective service invocation; which is one way to look at what happens when an auth module does a forward.

This sounds useful. If I understand correctly, it would work a little like a Servlet Filter when it calls FilterChain.doFilter, wouldn't it? This could also address the use case for supplying a wrapped request and/or response then (see also JASPIC_SPEC-8).

In code, would it then look something like this?

public AuthStatus validateRequest(MessageInfo messageInfo, Subject clientSubject, Subject serviceSubject) throws AuthException {

    SomeType someType = messageInfo.getMap().get("someKey");

    someType.invokeService(
         (HttpServletRequest) messageInfo.getRequestMessage(),
         (HttpServletResponse) messageInfo.getResponseMessage()
    };

    return SEND_CONTINUE;
}

what do you think, and if you have a chance to try this out let me know what you find

It sounds like a good idea. If there's any code or prototype available for this I can surely try it out.

In case some extra type of some sort is needed to invoke the service during the call to validateRequest, then could it also be an idea to introduce a specific sub-interface of ServerAuthModule for the Servlet Profile?

The Servlet spec has something similar. There's a javax.servlet.GenericServlet which is a protocol-independent servlet and there's javax.servlet.http.HttpServlet, which contains Http specific functionality. I experimented a little with this idea here: HttpServerAuthModule (but this may be better addressed via a separate issue)





[JASPIC_SPEC-8] Clarify and/or add TCK test for request/response wrapping Created: 18/Feb/13  Updated: 20/Feb/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms

 Description   

According to section Section 3.8.3.4 of the JSR 196 specification, an auth module can wrap a request and response during validateRequest processing. Such a wrapped request and response should then be available "downstream":

When a ServerAuthModule returns a wrapped message in MessageInfo, or unwraps a message in MessageInfo, the message processing runtime must ensure that the HttpServletRequest and HttpServletResponse objects established by the ServerAuthModule are used in downstream processing.

It is perhaps not entirely clear what "downstream" means.

A user might expect that such a wrapped request and response means that all filters and the Servlet that gets invoked for that request get to see these types (e.g. like a Servlet Filter does when it provides wrapped types to the FilterChain.doFilter method). However, this happens in none of the well known and certified JASPIC implementations (GlassFish, JBoss EAP, Geronimi, WebLogic and WebSphere).

For instance consider the following wrapper class:

public class MyTestWrapper extends HttpServletRequestWrapper {
    public MyTestWrapper(HttpServletRequest request) {
        super(request);
    }
}

and the following fragment in a ServerAuthModule.validateRequest implementation:

HttpServletRequest request = (HttpServletRequest) messageInfo.getRequestMessage();
        
messageInfo.setRequestMessage(new MyTestWrapper(request));

return SUCCESS;

Then the following assert in an HttpServlet that is invoked during the same request in which the auth module wrapped the HttpServletRequest instance fails for every of the above mentioned JASPIC implementations:

public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {   	
    assert(request instanceof MyTestWrapper);
}

Looking at the source code of various implementations, it looks like GlassFish could indeed provide the wrapped response downstream. In RealmAdapter the following code fragment appears right after the auth module is invoked:

HttpServletRequest newRequest = (HttpServletRequest) messageInfo.getRequestMessage();
if (newRequest != req) {
    request.setNote(Globals.WRAPPED_REQUEST, new HttpRequestWrapper(request, newRequest));
}

Then in StandardPipeline the following code could pass the wrapped request downstream, if chaining were to be true:

Request req = request;
Response resp = response;
if (chaining) {
    req = getRequest(request);
    resp = getResponse(request, response);
}
basic.invoke(req, resp);

The method getRequest would indeed get the wrapped request when it exists:

private Request getRequest(Request request) {
    Request r = (Request) request.getNote(Globals.WRAPPED_REQUEST);
    if (r == null) {
        r = request;
    }
    return r;
}

In practice though, the chaining boolean in the StandardPipeline fragment is always false, causing the original objects to be passed along instead of the wrapped ones. Moreover, similar analysis in the source code of e.g. JBoss EAP reveals that there is no code present whatsoever that could pass the wrapped request downstream.

Since wrapping is an important use case (it's a common technique used to "restore" the original request after a form based authentication), I would like to request:

  • A clarification about what "downstream available" means, perhaps by providing a code sample such as shown above.
  • A TCK test that tests whether a request and response wrapped by an auth module are indeed available in a simple servlet in a way as shown above.


 Comments   
Comment by arjan tijms [ 20/Feb/13 12:23 AM ]

B.9 in the JASPIC specification more explicitly mentions that wrapping the response should be possible.





[JASPIC_SPEC-9] Clarify and/or add TCK test for validateRequest/invoke service/secureResponse ordering Created: 20/Feb/13  Updated: 27/Feb/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: phendley
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms, monzillo and phendley

 Description   

Section 3.8.2.2 of the JASPIC spec discusses the invocation of validateRequest after a service invocation for the Servlet Container Profile.

It does however not give any details under which circumstances the runtime should call this method after a service invocation, and neither does it give any details about how an implementation of this method should distinguish between being called before service invocation (in which its job is to do authentication) and after service invocation (in which its job is to secure a response). For the SOAP profile, footnote 6 in 4.9.5.3 does give an explanation.

Section 3.8.3.3 says that the semantics of secureResponse are as defined in Section 3.8.2.2, which thus means that secureResponse should be called after a service invocation. Figure 1.1 in Section 1.1 shows this as well, and the general flow as described is Section 3.8 also mentions this.

Unfortunately, not all JASPIC implementations indeed call secureResponse after a service invocation. GlassFish 3.1.2.2, Geronimo V3.0 and WebSphere 8.5 do make the call afterwards, but the certified implementations of JBoss EAP 6.0.1 (and AS 7.1.1) as well as WebLogic 12.1.1 call secureResponse before a service invocation. In fact, both those implementations call secureResponse nearly immediately after validateRequest is called. In case of WebLogic 12.1.1 this can be deduced from the call stack in debug mode, while in case of JBoss EAP 6.0.1 it can be seen directly in its source code.

E.g. consider the following abbreviated excerpt from JBoss EAP's WebJASPIAuthenticator:

GenericMessageInfo messageInfo = new GenericMessageInfo();
messageInfo.setRequestMessage(request);
messageInfo.setResponseMessage(request.getResponse());

// [...]

ServerAuthenticationManager sam = getServerAuthenticationManager();
       
if (sam != null) {
    // Calls through to validateRequest on SAM
    result = sam.isValid(messageInfo, clientSubject, messageLayer, appContext, cbh);
}

if (result) {

    // [Jboss specific login]

    if (this.secureResponse)
        // Calls through to secureResponse on SAM
        sam.secureResponse(messageInfo, new Subject(), messageLayer, appContext, cbh);
    }
 }

return result; // Service invocation will happen after this if result == true

In case of JBoss EAP, secureResponse is not only seemingly called at the wrong time, it's also an optional operation (default false) but the spec does not mention this operation to be optional.

I would like to request a TCK test to be added that tests that secureResponse is indeed called after a service invocation, and clarification of the following items:

  • 3.8.2.2 - Why or when would validateRequest be called after a service invocation
  • Perhaps in 3.8.3.3 an explicit statement that secureResponse is to be called after a service invocation and not before.


 Comments   
Comment by monzillo [ 27/Feb/13 03:13 PM ]

the spec states that secureResponse is to be called at point 3 (point 3 is defined to occur after the service invocation), and that the service invocation is only done when validateRequest returns AuthStatus.SUCCESS and the container authorization check succeeds. The only case in which secureResponse must not be called after the service invocation, is when the service invocation throws an exception.

validateRequest must be called on every incoming request. If for example, secureResponse invokes a challenge response mechanism, validateRequest will be called for the requset that is the response to the challenge from secureResponse (which occurs after the server invocation) This is described in 3.8.3

Comment by arjan tijms [ 27/Feb/13 03:50 PM ]

the spec states that secureResponse is to be called at point 3 (point 3 is defined to occur after the service invocation)

Indeed, so at least to me this part of the spec seems clear. But apparently, it wasn't clear to the WebLogic and JBoss AS/EAP engineers, since they both call secureResponse before the service invocation.

Both implementations passed the TCK.

What would be the best thing to do, to ensure that WebLogic, JBoss AS/EAP and any possible future implementations don't make this mistake (again)? Would just adding a TCK test for this be enough?

Comment by monzillo [ 27/Feb/13 04:14 PM ]

I assigned this to the tck team. I think it would help to check compatibility for this requirement.
what you are doing is also a great help, in that you are pointing out where the problems are, and
hopefully the product engineers will be working to fix this product. If you have a way to create an
issue in their issue trackers that would also help (or send us any info you have on where such info
could be entered)

Comment by arjan tijms [ 27/Feb/13 04:32 PM ]

I assigned this to the tck team.

Great!

what you are doing is also a great help, in that you are pointing out where the problems are

Happy to do so, it's great that Oracle and the JCP offer the community a vehicle to be able to help.

If you have a way to create an issue in their issue trackers that would also help

If have created an issue for JBoss EAP/AS here: SECURITY-727.

I couldn't find an issue tracker for WebLogic though. It seems they don't have a public one. But since WebLogic is from Oracle and you work for Oracle as well, it might be easier for you to enter this or ask around where the WebLogic issue tracker is located?





[JASPIC_SPEC-10] Update JASPIC to take advantage of new Java language features Created: 20/Feb/13  Updated: 20/Feb/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms

 Description   

As one of the very last specs in Java EE, JASPIC still uses the Java 1.4 syntax. In the API are a couple of raw Maps that could really benefit from at least the Java 5 syntax (generics in this case).

I would like to request to update JASPIC to take advantage of newer Java language features.






[JASPIC_SPEC-11] made public permissions required to call static methods of abstract AuthConfigFactory Created: 03/Mar/13  Updated: 03/Mar/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: monzillo Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: monzillo

 Description   

this issue was reportd to me by Will Hopkins

documented permissions used to protect getFactory and setFactory.
also defined public static final Strings and permissions to
assist runtimes in creating or using these permissions.

also added new permission to protect factory registration and deregistration methods.






[JASPIC_SPEC-13] correct AuthConfigFactory.getConfigProvider inconistency in whether layer and appContextID may be null Created: 11/Mar/13  Updated: 11/Mar/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: monzillo Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: monzillo

 Description   

the version of the javadoc embedded in the 1.0 spec is out of sync with the javadoc
generated from the api src. The javadoc in the spi src is correct and allows these
parameters to be null in the general case. Note that profiles (e.g. the Servlet profile)
establish specific values (and may not allow null values) to be used when implementing
the profile.

Reported to me by Yi Wang.

will be fixed in 1.1, when mifdoclet is re-run to convert javadoc into the mif files that are
included in the framemaker spec document






[JASPIC_SPEC-14] Support CDI and other container services in SAM Created: 27/Mar/13  Updated: 27/Mar/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 4
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: cdi ejb jpa integration
Participants: arjan tijms

 Description   

In JASPIC 1.0 it has not been specified whether under the Servlet profile container services like CDI should be available at the time that a SAM is called at the start of a request.

In some implementations (e.g. JBoss EAP 6.0.1) those services are indeed fully available, while in other implementations (e.g. GlassFish 3.1.2.2) the services are partially available. In yet other implementations (e.g. WebLogic 12c 12.1.1) those services are not available at all.

For a number of use cases having this support is important, e.g.

  • Fetching users via EJB/JPA for a database based auth module
  • Generating and persisting tokens for "remember me" functionality
  • Creating a user locally after a first time authentication with an external provider (e.g. OpenId)

Ideally the support would be at the same level as that of a Servlet Filter, meaning the CDI request and session scopes are available, the "java:comp", "java:module", "java:app", etc JNDI namespaces have been set up, injection is possible, etc.

In order to support injection as well, the Factory API might need to have variants of its methods that take a Class type instead of an object instance, like e.g. addFilter(String, Filter) vs addFilter(String, Class). There might also need to be methods like createSam(Class) in analogy to createFilter and similar methods.






[JASPIC_SPEC-15] Define a standardized way to stack auth modules Created: 27/Mar/13  Updated: 05/Apr/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: stacking jaas pam
Participants: arjan tijms and monzillo

 Description   

According to JASPIC 1.1.2 an authentication context can manage multiple auth modules:

An authentication context is responsible for constructing, initializing, and coordinating the invocation of one or more encapsulated authentication modules.

If the context implementation supports the configuration of multiple authentication modules within a context (for example, as sufficient alternatives), the context coordinates the invocation of the authentication modules on behalf of both the message processing runtime and the authentication modules.

JASPIC 2.1.5.1 gives some more details:

If a context encapsulates multiple authentication modules, the context must embody the control logic to determine which modules of the context are to be invoked and in what order.

Contexts which encapsulate alternative sufficient modules must ensure that the same message values are passed to each invoked alternative of the context. If a context invokes multiple authentication modules, the context must combine the AuthStatus values returned by the invoked authentication modules to establish the AuthStatus value returned by the context to the messaging runtime.

The context implementation must define the logic for combining the returned AuthStatus values.

This gives a framework to work with, but it does not specify the exact semantics of how the handling of multiple modules (stacking) should take place. Each implementation is free to do this largely in an implementation specific way. This makes it hard to cary over a configuration of modules from one server to the other.

In order to improve portability and as a possible precursor to a standardized declarative way to configure auth modules, I would like to request to standardize a specific way of handling multiple auth modules and demanding the runtime to make an authentication context available that implements this.

Possibly the JAAS/PAM semantics of Required, Requisite, Sufficient and Optional could be formally specified for use with JASPIC. (the existing specification already hints to supporting the Sufficient semantics)



 Comments   
Comment by monzillo [ 05/Apr/13 01:52 PM ]

When the expert group discussed stacking (auth modules), we decided that stacking was a configuration specific behavior, that might only be supported by some authconfig systems/providers, and that might be done differently by any such systems; thus the existing language in the spec (for example in section 1.1.2 Authentication Contexts)

"An authentication context is responsible for constructing, initializing, and coordinating the invocation of one or more encapsulated authentication modules. If the context implementation supports the configuration of multiple authentication modules within a context (for example, as sufficient alternatives), the context coordinates the invocation of the authentication modules on behalf of both the message processing runtime and the authentication modules."

that said, there are various reasons why we should make it easy for jaspic users to work with an existing and portable authconfigprovider (e.g., so that they can focus on auth module development), and a JAAS style configuration provider (that supports stacking) has been available in Glassfish for some time.

That said, I need to a better job of improving the visibility, availability, and portability of that provider; which supports stacking according to the JAAS model of REQUIRED,REQUISITE, etc. At this time it does very little in terms of "coordinating" calls to handle the CallerPrincipalCallback originating form multiple modules within the stack. It currently depends on com.sun.security.auth.login.ConfigFile, which
is not be available in all JVMs, and I am working to replace (that parser of the JAAS config file syntax)such that this will not detraact from the portability of the authconfigprovder; which is (currently) in the glassfish codebase at:

./security/jaspic-provider-framework/src/main/java/com/sun/jaspic/config/servlet/JAASServletAuthConfigProvider.java





[JASPIC_SPEC-16] Ability for application to choose authentication method at runtime Created: 27/Mar/13  Updated: 27/Mar/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms

 Description   

In Java EE and specifically in JASPIC there is somewhat of the assumption that a single authentication method is configured (in many cases even mostly outside the application).

While for some classes of applications this has clear benefits, it doesn't particularly play nice with the increasingly popular practice that web applications offer their users a choice for their login method.

For instance, stackoverflow.com currently displays the following login choices:

  • Log in with StackExchange
  • Log in with Google
  • Log in with facebook
  • Log in with Yahoo!

See http://stackoverflow.com/users/login

To make it to implement this use case I would like to request that JASPIC adds some level of support for this.

One way to do this could be via the existing authentication context and perhaps via the concept of having different "authentication stacks". (Note that JASPIC_SPEC-15 is related to this, but instead asks how auth modules in a single stack interact)

With this concept, each such stack (possibly consisting of only a single SAM) is named and corresponds with an authentication mechanism (e.g. "native form", or "OpenId-Wordpress", etc).

For the Web Profile the application can then programmatically set an authentication mechanism for the current session by calling a variant on the request#authenticate method, e.g. request#authenticateWith(String, Request, Response), where the provided String parameter is a name that corresponds with one of the pre-configured stacks. Such a new method would require coordination with the Servlet spec of course.






[JASPIC_SPEC-17] Servlet profile specific types to increase ease of use Created: 31/Mar/13  Updated: 31/Mar/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ease-of-use ease_of_development
Participants: arjan tijms

 Description   

JASPIC as it's currently defined has an exceptionally flexible and abstract API. It can handle authentication for different kinds of environments, which are defined in profiles. Profiles demand certain behavior and specific keys to be present in otherwise generic maps that are used throughout the API.

While this indeed makes the API flexible, it comes at the cost of a reduced ease-of-use. Developers wishing to program for e.g. the Servlet Profile have to read through documentation to see in what way they need to fulfill the contract of the profile and which keys can be inserted or retrieved from the mentioned maps. A certain amount of casting from type Object is also required to work with the profile.

This required effort can likely be significantly reduced by the introduction of specific Java types for a profile. The Servlet spec uses something similar to this. There is a GenericServlet which is protocol independent and an HtppServlet that's provided as a convenience for HTTP usage (which is overwhelmingly the common usage).

In practice those specific types are already created by JASPIC users, e.g. JBoss uses WebServerAuthModule as a Servlet Profile specific base class for a ServerAuthModule, and in OmniSecurity we're prototyping a base class as well with HttpServerAuthModule.

A standardized convenience ServerAuthModule base class for the Servlet Profile could have the following properties:

  • Default implementation of getSupportedMessageTypes returning the two mandated classes.
  • Default initialize that just stores the incoming parameters for later retrieval
  • Default secureResponse just returning a success status
  • Default cleanSubject that just removes the Principals from the given Subject
  • A new validateRequest method that has HttpServletRequest and HttpServletResponse as parameters and perhaps a context object of some kind (e.g. called HttpMsgContext or something similar (just like ServletContext, FacesContext, etc).

The context object mentioned above can contain a number of convenience methods for working with the Servlet Profile, e.g.

  • an isProtected method corresponding to the javax.security.auth.message.MessagePolicy.isMandatory key.
  • a registerWithContainer(String, List<String>) method as a convenience shortcut for working directly with the CallerPrincipalCallback and GroupPrincipalCallback
  • a setRegisterSession and isRegisterSession corresponding to the javax.servlet.http.registerSession key.
  • getters for the (raw) MessageInfo, Subject parameters of the super validateRequest method and the CallbackHandler that was passed into the initialize method.

The above mentioned types, names, and semantics are just examples to kickoff a discussion about this matter. Note that the proposed convenience types and methods are just conveniences and should never be the only way to work with the API.






[JASPIC_SPEC-18] Add some documentation of JASPIC in Oracle's Java EE 7 tutorial Created: 03/Apr/13  Updated: 03/Apr/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: documentation tutorial
Participants: arjan tijms

 Description   

Although JASPIC has been part of Java EE since Java EE 6, it's still a relatively unknown technology. One of the reasons might be that not a lot of tutorials or books mention it.

As Oracle is the spec lead for JASPIC I wonder if it's possible to include some documentation of JASPIC in Oracle's upcoming Java EE 7 tutorial. In the Java EE 6 tutorial, the section Specifying Authentication Mechanisms would probably have been a good location.






[JASPIC_SPEC-19] Specification of validateRequest "doing nothing" Created: 04/Apr/13  Updated: 05/Apr/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms and monzillo

 Description   

JASPIC specifies that for among others the Servlet Profile an auth module (and its context) should be called before every request.

In several situations an auth module's validateRequest method may choose to "do nothing". For instance, the requested resource may not be a protected one and the trigger to do a pre-emptive authentication is not present in the request.

The JASPIC spec is not entirely clear how this situation should be handled. 3.8.3.1 comes close and mentions the following:

Independent of whether the authentication policy is satisfied, the module may return AuthStatus.SUCCESS.

If the module returns AuthStatus.SUCCESS (and the authentication policy was satisfied), the module (or its context) must employ a CallerPrincipalCallback as described above.

If the authentication policy was not satisfied, and yet the module chooses to return AuthStatus.SUCCESS, the module (or its context) must use a CallerPrincipalCallback to establish the container's representation of the unauthenticated caller within the clientSubject.

This text mentions the authentication policy, but does not seem to take the situation into account where authentication is not mandatory for the request (i.e. as explained in 3.8.1.1 and represented by the MessageInfo map key javax.security.auth.message.MessagePolicy.isMandatory).

Studying several available authentication modules it looks like the prevailing opinion is to just return AuthStatus.SUCCESS without employing the CallerPrincipalCallback. E.g. as done by the OpenID4Java SAM:

if (isMandatory) {                                      
    respondWithLoginForm(request, response);
} else {
    // the request is not protected so simple succeed the
    // request...
    return AuthStatus.SUCCESS;
}

This indeed works on many JASPIC implementations, but not on all (it doesn't work on JBoss AS/EAP).

The possible option of using "CallerPrincipalCallback to establish the container's representation of the unauthenticated caller within the clientSubject." is practically not possible, since there doesn't seem to be any portable way for a SAM to do this. A representation of the unauthenticated caller can not be obtained in a standard way (GlassFish e.g. uses the proprietary SecurityContext.getDefaultCallerPrincipal(). It's also not clear how a CallerPrincipalCallback can be used to communicate that special identity back to the runtime.

I would like to request to specify what should happen if a SAM does not want to do any authentication, but does want the requested resource to be invoked.

A simple solution could be to just specify that validateRequest can always return AuthStatus.SUCCESS without employing the CallerPrincipalCallback in any way, and that it depends on the authorization requirements if the resource is indeed invoked.

Additional it might be worthwhile to introduce a new AuthStatus, perhaps called CONTINUE that explicitly means that the SAM (or its context) did not employ the CallerPrincipalCallback or any other callback and just wishes that the request continues. This additional status may also be convenient for JASPIC_SPEC-15.



 Comments   
Comment by monzillo [ 05/Apr/13 01:26 PM ]

The CallerPrincipalCallback defines a portable contract for setting the container's represented of the authenticated or unauthenticated caller, as defined in the apidocs; so that is not an issue.

(one example rome the api docs)

"p - The Principal that will be distinguished as the caller principal. This value may be null.
The CallbackHandler must use the argument Principal to establish the caller principal associated with the invocation being processed by the container. When the argument Principal is null, the handler must establish the container’s representation of the unauthenticated caller principal."

the same semantic is defined for the name based callback constructor.

more generally, the contract basically states that in order to return success the authmodule must have set the container's representation of authentication state, under the assumption, that an appropriate state will NOT have been set prior to the invocation of the module. Under that assumption, changing the contract to allow the authmodule to do nothing could lead to unpredictable results.

multi-module contexts introduce another level of complication, and for that case the spec requires that the context coordinate the various callerprincipalcallback calls such that the appropriate caller principal is established.

In the servlet profile, if a module is called with an optional policy, and the module want's to return success, then the module gets to decide whether what principal it wants to set in the container authentication state. One strategy might be to handle a CallerPrincipalCallback constructed with the value obtained from request.getCallerPrincipal(). Other modules, may look at other content in the request, and decide to handle a CallrPrincipalCallback constructed in a different way, but in all cases, when the module returns success, it must have handled a CallerPrincipalCallback.





[JASPIC_SPEC-20] Portable way for auth module to ask container to automatically apply auth session Created: 20/Apr/13  Updated: 20/Apr/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ease-of-use ease_of_development
Participants: arjan tijms

 Description   

Per JASPIC_SPEC-3 an authentication module can ask the container to create an authentication session, meaning the container "remembers" the established authenticated identity. This is a major step forward for authentication modules that don't have a requirement to maintain such a session in a custom way.

However, even when the SAM has asked the container to create this session, the SAM is called at every request (as per the Servlet Container profile requirements) and the SAM has to tell the container it (still) wants to continue with the previously established authenticated identity by executing code like the following:

public AuthStatus doValidateRequest(MessageInfo messageInfo, Subject clientSubject, Subject serviceSubject) throws AuthException {
 
    HttpServletRequest request = (HttpServletRequest) messageInfo.getRequestMessage();
    Principal userPrincipal = request.getUserPrincipal();
    
    try {
        if (userPrincipal != null) {   
            handler.handle(new Callback[] { 
                new CallerPrincipalCallback(clientSubject, userPrincipal) }
            );
                 
            return SUCCESS;   
        }
 
        // Rest of auth code here

    } catch (ServletException | IOException e) {
        throw (AuthException) new AuthException().initCause(e);
    }
}

In order to make a common case easier, where the SAM simply always wants to continue with the previously established authenticated identity until the authentication session is ended (by whatever means), I'ld like to propose to add a way for the SAM to ask the container to automatically apply the identity stored in the authentication session to the current request.

After the SAM has asked for this AND an authenticated identity has been established, the SAM would indeed not be called anymore as long as the authentication session is valid (exists).

This might be implemented by defining another key to be put in the MessageInfo map that works alongside the existing key for asking a session, as follows:

  • javax.servlet.http.registerSession - Container registers a session, but SAM still called every request and SAM decides to use this or not.
  • javax.servlet.http.autoApplySession - If container has a session, it uses this and does not call the SAM.





[JASPIC_SPEC-21] Support for events Created: 30/Apr/13  Updated: 09/Oct/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms and kithouna

 Description   

For several use cases it would be quite convenient if JASPIC would throw events at several important moments of the authentication message exchange.

Such events could be:

  • PreAuthenticate
  • PostAuthenticate
  • PreLogout
  • PostLogout

User code could possibly register for such events in the same way such code can register for events from the Servlet container; annotating the listener class and implementing an interface.

E.g.

@SecurityListener
public class MyListener implements AuthenticationListener  {

    public void preAuthenticate(AuthEvent authEvent) {
        // ...
    }

    public void postAuthenticate(AuthEvent authEvent) {
        // ...
    }
}

Additionally CDI style events can be supported as well.

Use cases for such event listeners are among others:

  • Keeping track of the number of logged-in users
  • Protecting against brute-force attacks by keeping count of failed login attempts for a certain account
  • Creating a new local user after the first successful authentication via a remote authentication provider
  • Loading application specific preferences into the HTTP session after a user logs-in

Specifically for the second use case a PreAutenticate listener should be able to veto the authentication attempt (at which JASPIC could respond by e.g. sending a 403 to the client).



 Comments   
Comment by kithouna [ 09/Oct/13 02:49 PM ]

Another use case: increase the Http session timeout after a user logs in. The AuthEvent should therefor give access to the JASPIC request/response.





[JASPIC_SPEC-22] Modification of authenticated identity without re-authentication Created: 04/May/13  Updated: 04/May/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms

 Description   

A common use case in web applications is that users log-in with their email address, which then becomes the user/caller principal once authenticated.

A user should be allowed to change her email address, but this is not easily supported by JASPIC, since this also requires a re-authentication, which on its turn likely needs the original credentials used for authentication (which a secure application of course does not store, so can not use for this case).

This means that a user either needs to provide these credentials together with the action of changing the email, which is not entirely user friendly in the first place. Those provided credentials may possibly not even be useable for programmatic re-authentication if the SAM that's used only supports asking them directly from the user.

Another option is to immediately log the user out after changing the email, which again is not really user friendly.

Something similar holds for roles; a user may obtain new roles during a session (for example by making a payment, or obtaining a reward for some online action, etc). Requiring the user to log-out and log-in again for the new role to take effect is not always desirable.

See also: http://stackoverflow.com/questions/2487224/how-to-handle-dynamic-role-or-username-changes-in-jsf

In order to support such use cases I'd like to propose that the possibility to handle changes to the authenticated identity without the need for a manual logout and login (re-authenticate) be added to JASPIC.

One possibility could be for a variant on HttpServletRequest#authenticate that takes one or more Callbacks, and the definition of several new Callbacks, e.g.

  • AddGroupPrincipalCallback - Adds a new group/role to the authenticated identity
  • RemoveGroupPrincipalCallback - Removed an existing group/role from the authenticated identity
  • UpdateCallerPrincipalCallback - Updates the caller principal in the authenticated identity





[JASPIC_SPEC-23] Status code for processing handler but not invoking resource Created: 10/Aug/13  Updated: 10/Aug/13

Status: Open
Project: jaspic-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms

 Description   

In the Servlet Container Profile of JASPIC the ServerAuthModule.validateRequest method can return the SUCCESS} status code, which means the given handler should be processed by the JASPIC runtime and the requested resource should be invoked. This same method can also return {{SEND_CONTINUE which means the handler should not be processed and the resource should not be invoked.

Neither of those status codes address the use case where a SAM wishes authentication to happen first (and ask the container to remember this) and then immediately redirect to a new resource.

This happens for instance when the user tries to access protected resource /A after which the SAM redirects the user to an external authentication provider at http://example.com which then redirects the user back to a general resource at /return which the SAM is monitoring. The SAM could redirect to /A first and then do authentication, but this slightly complicates the logic that needs to be coded.

Fragment of code from an actual SAM demonstrating a similar case:

if (...) {
    // [...]
    
    if (authenticated) {
                
        String savedURL = getSavedURL(request);
        // [...]
        
        // Note: JASPIC doesn't really support authenticating AND redirecting during the same request, 
        // so we need to redirect first and then finally do the authentication with the container on 
        // the request we redirected to.
        redirect(response, savedURL);
        return SEND_CONTINUE;
    } else {
        // [...]
    }
    
} else if (isOnOriginalURLAfterAuthenticate(request)) {
    
    Authenticator authenticator = getSavedAuthenticator(request);

Source

For completeness and to make some flows easier to code, I'd like to suggest the introduction of a new status code, something like SUCCESS_SEND_CONTINUE, meaning:

  • Process the handler and any directives put into the MessageInfo map (such as asking the container to remember the auth session)
  • Don't invoke the resource





Generated at Sun Apr 20 05:55:06 UTC 2014 using JIRA 4.0.2#472.