> Couple of approaches:
>
> 1) (simple) In the "anonymous" case, the getUserPrincipal()
> will just return
> null. It will return non-null for everyone else. Thus,
> in your impl, just
> detect it that way.
Hmm. I though that a request doesn't get to the protected resource if
it is not authenticated, as in a web.xml:
<security-constraint>
<web-resource-collection>
<web-resource-name>Remote builder</web-resource-name>
<url-pattern>/service/integration/</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>service-user</role-name>
</auth-constraint>
</security-constraint>
Slava
>
> 2) (complex) You CAN write an interceptor that replaces the
> Principal in the
> context with something else. If the principal is null,
> create an anonymous
> principal and reset the security context information to point
> to that. In
> general (1) is much easier. :-)
>
> Dan
>
>
> On Fri February 20 2009 3:55:56 pm Slava Imeshev wrote:
> > Daniel,
> >
> > Thanks!
> >
> > I have another question. I have also a use case when the web
service
> > should provide the result w/o authentication at all. The options I
> > have right now are
> >
> > 1. To say that the authentication is always required.
> >
> > 2. To bind the service to a URL that does not require
> authentication.
> >
> > 3. Somehow pre-process the request and replace a request w/o
> > authentication with a request with synthetic user "anonymous".
> >
> > I think # 1 and # 2 are easy but don't do exactly what is
> required. #3
> > seem to be optimal but I am not sure how to approach it.
> >
> > Any suggestions/ideas?
> >
> > Regards,
> >
> > Slava Imeshev
> >
> > > -----Original Message-----
> > > From: Daniel Kulp [mailto:[email protected]]
> > > Sent: Friday, February 20, 2009 12:43 PM
> > > To: [email protected]
> > > Cc: Slava Imeshev
> > > Subject: Re: Authentication and authorization
> > >
> > > On Fri February 20 2009 1:21:42 pm Slava Imeshev wrote:
> > > > Daniel,
> > > >
> > > > I am pretty new to CXF. I'd very grateful if you could you
point
> >
> > me
> >
> > > > in the right direction. Any examples/tutorials?
> > >
> > > It's pretty simple acutally. In your Impl bean, add a field:
> > >
> > >
> > > @Resource
> > > private WebServiceContext context;
> > >
> > > That will get the context injected.
> > >
> > >
> > > Then in your method, do:
> > >
> > > context.getUserPrincipal()
> > > or
> > > context.isUserInRole("blah");
> > >
> > > As long as the user has authenticated (basic auth), then
> > > those methods should
> > > return the information that the app server returns from the
> > > HttpServletRequest.
> > >
> > > Dan
> > >
> > > > Regards,
> > > >
> > > > Slava Imeshev
> > > >
> > > > > -----Original Message-----
> > > > > From: Daniel Kulp [mailto:[email protected]]
> > > > > Sent: Friday, February 20, 2009 7:58 AM
> > > > > To: [email protected]
> > > > > Cc: Slava Imeshev
> > > > > Subject: Re: Authentication and authorization
> > > > >
> > > > >
> > > > > The JAX-WS spec kind of covers this.
> > > > >
> > > > > If you inject WebServiceContext, from the context, you can
> > > > > get the user
> > > > > principal and call the isUserInRole call which would call
> > > > > back into the tomcat
> > > > > auth modules. From that, you can act on it any way
> you please.
> > > > >
> > > > > Dan
> > > > >
> > > > > On Thu February 19 2009 5:58:12 pm Slava Imeshev wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > I have an interesting use case that I am not sure how
> > >
> > > to approach.
> > >
> > > > > > Consider a service MyService on Tomcat, pseudocode:
> > > > > >
> > > > > > MyService {
> > > > > > Set<Entry> getEntries();
> > > > > > }
> > > > > >
> > > > > > For that service, if the requester did not authenticate,
the
> > > > > > getEntries would return a limited list of entries, only
> > > > >
> > > > > those allowed
> > > > >
> > > > > > for "public" access. If the requestor did authenticate,
the
> > > >
> > > > service
> > > >
> > > > > > returns an extended set. How can this be done with CXF?
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Slava Imeshev
> > > > >
> > > > > --
> > > > > Daniel Kulp
> > > > > [email protected]
> > > > > http://www.dankulp.com/blog
> > >
> > > --
> > > Daniel Kulp
> > > [email protected]
> > > http://www.dankulp.com/blog
>
> --
> Daniel Kulp
> [email protected]
> http://www.dankulp.com/blog
