[
http://java.net/jira/browse/JASPIC_SPEC-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360512#action_360512 ]
monzillo commented on JASPIC_SPEC-19:
-------------------------------------
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.
> 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