Rejeev Divakaran wrote:
> 1) Yes I am using a SAM to protect conventional Web app.
> 2) within validateRequest, it is determined that the message is
> sufficiently authenticated, and a principal is created and the
> principal is pushed into the subject passed (see the attached
> ServerAuthModuleImpl.java in the attached zip file)
> 3) I am not using CallbackHandlers. I am not using any JAAS API for
> authentication.
Rejeev,
thanks for sending your SAM code, that should make it easier for us to
communicate.
> /**
> * @author Rejeev Divakaran
> *
> */
> */
> public AuthStatus validateRequest(MessageInfo arg0, Subject arg1,
> Subject arg2) throws AuthException {
the first Subject, arg1, is the clientSUbject, you should add your
principal only to it. AYK, the second Subject arg, is the
serviceSubject, which may be null. If you were to add principals or
credentials to the serviceSubject, they would pertain to the recipient
of the request, i.e, the web container (not the client).
your module is clearly an attempt to get something working. AYK, a real
module needs to evaluate some proof provided in the servletrequest to
determine whether authentication has succeeded, and to determine the
authentication identity to be established in the subject. moreover as
defined by the spec, the module needs to evaluate whether it was
initialized with a mandatory or optional policy as defined in section
3.7.4 of the spec. when called with an optional policy, the module
should attempt to continue an authenticated result established in a
previous interaction within the session, but it should not force an
authentication (since the resource is not protected by an
auth-constraint). COnversly when the the policy is mandatory, the module
must not return SUCCESS unless an authentication was successfully
performed. the applicable requirements relating to validateRequest are
spelled out in section 3.8.3.1 "validateRequest Before Service
Invocation" of the spec. your SAM must need use the callback Handler
passed to it when it was initialized to handle (at least) a
CallerPrincipalCallback
form the spec
> 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. If the module determines
> that an invalid or incomplete security context was used to secure the request, then the module may return
> AuthStatus.SEND_FAILURE, AuthStatus.SEND_CONTINUE, or throw an AuthException.If the call to validateRequest returns AuthStatus.SUCCESS, the runtime must establish return values for getUserPrincipal, getRemoteUser, and getAuthType as defined in Section 3.8.4, “Setting the Authentication Results on the HttpServletRequest”.
also take a look at the javadocs for the CallerPrinicpalCallback, as it
will describe various details of its use, such as how to establish an
unathenticated identity.
since you are using a custom principal, you must include its type as an
attribute in the role mapping. please look at the documentation of the
sun specific dtd to see the proper syntax. you can find the dtds under
publish/glassfish/lib/dtds.
I think only this last thing is necessary for you to get past the
authorization check, but others things may not work correctly if you do
not use the callback handler as described above.
> logger.severe("validate request is called");
> Principal principal = new PrincipalImpl("rejeev");
> arg1.getPrincipals().add(principal);
delete the following line
btw, the spec will begin its final approval ballot today (lasting for 14
days) so, imo, your timing is perfect.
Ron
> if(arg2 != null) arg2.getPrincipals().add(principal);
> return AuthStatus.SUCCESS;
> }
>
> /* (non-Javadoc)
> * @see javax.security.auth.message.ServerAuth#secureResponse(javax.security.auth.message.MessageInfo, javax.security.auth.Subject)
> */
> public AuthStatus secureResponse(MessageInfo arg0, Subject arg1)
> throws AuthException {
> logger.severe("secure response is called...");
> return AuthStatus.SEND_SUCCESS;
> }
>
> 4) Principal to role mapping is done (see the attached sun-web.xml)
> 5) I will try specifying principal class name in security role mapping
> 6) Meanwhile I am attaching the relevant files.
>
> Thanks in advance.
>
> Regards,
> Rejeev.
>
>> <response>
>> I think he is trying to use a SAM at to protect a conventional web
>> application. within validateRequest, when his module has determined that
>> the message is sufficinetly authenticated, the module should add a
>> principal to the clientSubject, and it must use the callbackhandler
>> (passed to it by the container) to handle a CallerPrincipalCallback.
>>
>> The CallerPrincipalCallback can be constructed with a name or with a
>> cuustom principal.
>>
>> If a principal-to-role mapping is defined for the app (alternatively a
>> default p2r mapping can be enabled) then the mapping must map at least
>> one of the principals added to the subject to a role that is granted
>> permissision to access the web resource.
>>
>> If only custom principals are added to the clientSubject, then the
>> security-role-mapping defined by the app for a granted role, must
>> include both the principal class-name and the principal-name of the
>> principal resulting from the authentication by the SAM.
>>
>> If Rejeev can send us his generated policy files, his web.xml, and the
>> sun-specific-dtd file in which he has defined his p2r mapping (e.g.
>> sun-web.xml), along with a representation of the class name and name
>> values of the principals that his authentication module has added to the
>> clientSubject, then I think we should be able to explain the failed
>> authorization check, and instruct him on how to define an appropriate
>> security-role-mapping (or to employ the default mapping).
>> </response>
>>
>> thanks
>> sreeni
>>