Hi John Please see comments prefixed with S.B inline
-----Original Message----- From: John Klassa [mailto:[email protected]] Sent: Mon 1/4/2010 5:15 PM To: [email protected] Subject: (selective) authentication for REST resources Multi-part question... Part #1 ------- I'm having trouble figuring out how you'd do something simple like fetch the current (authenticated) user's username from inside a resource method. I perused the docs, but saw only a reference to an AuthenticationHandler: public class AuthenticationHandler implements RequestHandler { public Response handleRequest(Message m, ClassResourceInfo resourceClass) { AuthorizationPolicy policy = (AuthorizationPolicy)m.getContent(AuthorizationPolicy.class); policy.getUserName(); policy.getPassword(); return null; } } However, I'm not clear on how I'd make use of this in a way that gets the information into a resource method. From the things that are flat-out available to a resource method, I don't see a way to get the username... >S.B if you have a CXF JAXRS MessageContext injected into you resource class >then you can do mc.getContent(AuthorizationPolicy.class) Really, it looks (to me) like an authentication handler is more like a way to define your own authentication mechanism. > S.B : agreed To that end: Part #2 ------- How *would* I implement a custom authentication mechanism? Obviously, I could read the HTTP headers from inside the resource method, and figure things out from there, but that seems cumbersome. What I'm trying to do is make use of WSSE UsernameToken (the way Atom does), which would seem to require some custom code. Thoughts on how best to approach this? Part #3 ------- Really, what I ultimately want is to have basic authentication turned on for one particular resource (for all HTTP methods), WSSE UsernameToken turned on for certain methods on certain other resources, and no authentication at all for everything else. Something like: /foo - GET, PUT, POST and DELETE all use HTTP basic authentication /bar - GET not authenticated at all, but /bar - PUT, POST and DELETE all use WSSE UsernameToken /baz - all methods unauthenticated Is there a nice, declarative way to accomplish this, or will I need to resort to calls from within each resource method, to do/not-do the authentication in appropriate ways? >S.B : There are probably few options available : 1. Employ SpringSecurity, for example see http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/resources/jaxrs_security_no_annotations/WEB-INF/beans.xml Doing a similar configuration will let you handle all /foo. Both authentication and authorization is done but it is probably relatively easy to avoid even specifying individual resource methods but rather tell Spring Security to do the uri-based authentication only. It is also probably possible to indicate that /bar GET and /baz should not be authenticated. Now, as far as WSSE UsernameToken is concerned, you'd need to write a custom JAXRS Invoker or perhaps just an input RequestHandler filter and if it's /bar then parse a WSSE header, possibly by borrowing some of the code from CXF WSS4JInInterceptor, and then set an authentication token on the SpringSecurity context, see this thread : http://forum.springsource.org/showthread.php?t=64492&highlight=username+token 2. Use a single RequestHandler filter only. If it is /bar POST/PUT then parse a WSSE header, authenticate and return a blocking Response with a custom status. Same for /foo but this time just use the AutorizationPolicy given that it already contains the decoded username/password. For all other cases let the execution to continue by returning null... We should probably need to start looking sooner rather than later into extracting some of the code from the CXF WS-Security module for the purpose of reusing it in JAXRS services (WSSE UsernameToken, message security, etc). Plus start looking into making sure HttpConduit can have redirect handlers plugged in for dedaling with all sorts of secure redirections, it is all internal at the moment... Let me know please if you need some more info thanks, Sergey Thanks!
