Specification of validateRequest "doing nothing"
------------------------------------------------
Key: JASPIC_SPEC-19
URL:
http://java.net/jira/browse/JASPIC_SPEC-19
Project: jaspic-spec
Issue Type: New Feature
Reporter: arjan tijms
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:
{quote}
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.
{quote}
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|
http://code.google.com/p/openid4java-jsr196/source/browse/trunk/src/main/java/org/imixs/openid/openid4java/OpenID4JavaAuthModule.java#325]:
{code}
if (isMandatory) {
respondWithLoginForm(request, response);
} else {
// the request is not protected so simple succeed the
// request...
return AuthStatus.SUCCESS;
}
{code}
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()|
http://grepcode.com/file/maven.java.net/content/groups/promoted/org.glassfish.main.security/security/4.0-b78/com/sun/enterprise/security/SecurityContext.java#243]. 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira