Sergey, be careful with your first reason--that of using the CallbackHandlers to *return* passwords, that's an old erroneous design apparently since fixed in WSS4J (https://issues.apache.org/jira/browse/WSS-183) that should not necessarily be used as a reason for doing what you're doing--that process should be taken out of CXF instead when it upgrades to the new WSS4J.
Actually, I think Metro does what you want--allows the option for container-managed authentication *without* the callbackhandler (http://www.jroller.com/gmazza/entry/metro_usernametoken_profile#MetroUT3). If you can repeat the same with CXF, great! Glen Sergey Beryozkin-5 wrote: > > There are few problems with depending on CallbackHandlers only : > > - when passwords have been digested, WSS4JInterceptor requires a clear > text > password back to verify a digest which is not realistic in cases where an > external system can authenticate a user with the digest password but have > no > way of returning an actual password for this CallbackHandler to give it to > WSS4JInterceptor > - authentication is only part of the story, what is really important is > that > the authorization can be done further down the line. I don't think trying > to > do the authorization from the CallbackHandler is a good approach - we > don't > even know the method name to be invoked upon > > Now, perhaps one can even authenticate and authorize from a callback > handler > by somehow getting to the current Message, figuring out the method name, > etc. But IMHO the proposed approach is cleaner and it gives more options > as > to when an authorization should be done due to the fact we have a valid > SecurityContext in scope > -- View this message in context: http://old.nabble.com/Using-WS-Security-UsernameToken-to-authenticate-users-and-populate--SecurityContexts-tp28165583p28167255.html Sent from the cxf-dev mailing list archive at Nabble.com.
