Specification of validateRequest "doing nothing"

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](http://code.google.com/p/openid4java-jsr196/source/browse/trunk/src/main/java/org/imixs/openid/openid4java/OpenID4JavaAuthModule.java#325):

```
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()](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 #15.