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?
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?
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?
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
> > >>
> >
> >
>