Rejeev Divakaran wrote:
> Hi Ron,
> I have modified the sun-web.xml to include class-name attribute to
> principal-name tag and got things rolling. Thank you.
> However I am little puzzled in the following.
> 1) why we need to provide class-name of principal Impl to App server
> runtime? Is it a logical requirement or limitation of current
> implementation?
neither (assuming I understand what you mean by these terms).
the principal in the mapping needs to match some principal that you are
adding to the subject. If you are adding a custom principal, then you
will need to qualify the mapping as such. you could also use the
CallerPrincipalCallback to add a principal by name to the subject, in
which case a defualt principal type native to the application server,
will be constructed with the name and added to the subject. In that case
you need not specify the class-name in the mapping. similarly if your
mapping is basedon group names, you can add group principals by name
using the groupprincipalcallback, in which case you will not have to
designate the class name of the group principal in the mapping.
> 2) Why do we MUST use CallbackHandler.handle with
> CallerPrincipalCallback, GroupPrincipalCallback etc? Isn'it it
> sufficient for App server runtime to return value of validateRequest
> and process the subject accordingly?
>
these callbacks effectively implement a contract between the container
and the SAM, so that a portable SAM can be implemented, and such that it
can cause the appropriate results to be established in the subject, in
whatever fashion is compatible with the principal types known to the
container, and more significantly so that the container can knwo what
principal to return when getCallerPrincipal is called. This is described
in the spec.
> I have modified the code further to make using a basic authentication,
> and that also working.
> I am curious now how to get hold of the login page mentioned in the
> web.xml to use a form based authentication. Is it possible?
not sure how to do this, but I think it is possible. you might try
asking just that question in a servlet forum.
Ron
>
> Regards,
> Rejeev.
>
> On 7/11/07, Rejeev Divakaran <rejeev_at_gmail.com> wrote:
>
>> Thanks Ron for the detailed explanations!
>> I will try them and will get back to you.
>>
>> Regards,
>> Rejeev.
>>
>> On 7/10/07, Ron Monzillo <Ronald.Monzillo_at_sun.com> wrote:
>> > 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
>> > >>
>> >
>> >
>>