> -----Original Message-----
> From: KARR, DAVID (ATTCINW)
> Sent: Monday, January 18, 2010 10:33 AM
> To: [email protected]
> Subject: RE: help implementing secured resource methods?
> 
> > -----Original Message-----
> > From: Sergey Beryozkin [mailto:[email protected]]
> > Sent: Monday, January 18, 2010 10:01 AM
> > To: [email protected]
> > Subject: Re: help implementing secured resource methods?
> >
> > Hi
> >
> > <snip/>
> >
> > I've decided that I'm better off letting the container do the
> > authentication and simple authorization and then doing fine-tuned
> > authorization in my handler (my authorizations are data-based, not
> > method-based, so Spring Security doesn't help me).  I finally got
> > through the role/group mapping stuff, so that my request with a
valid
> > Authorization header got serviced without a 401 or 403.
> >
> > However, I'm also seeing that when I get into my handler, the
> > AuthorizationPolicy that I retrieve from the message is null.  I can
> > see
> > the "Authorization" header right in the debugging.  Is there
> something
> > else I have to do to get my principal/credentials automatically
> parsed
> > out so I don't have to do it manually?
> >
> > S.B : Can you try to set a breakpoint in
> > org.apache.cxf.transport.http.AstractHttpDestination#setHeaders ?
> This
> > is where AuthorizationPolicy is set...
> 
> Got it.  The example on the CXF doc appears to be wrong (or the code
is
> wrong).  Instead of calling "getContent()", I had to call "get()".
> That
> gives the name/password, at least.
> 
> > But do you need AuthorizationPolicy which contains a decoded
> > name/password only, or do you need a Principal object ?
> 
> Will getting the Principal object make it easier to eventually get the
> LDAP group membership for that principal?  That's my next step.

Actually, I realized that I can just get the principal from the servlet
request (from the MessageContexgt) and just do "isUserInRole()" queries.
That should work fine.

Reply via email to