Actually Glen, sorry for a speedy reply. Here are some more clarifications. Please have a look at the source of the AbstractWSS4JSecurityContextProviding interceptor. In a nutshell, it is a complex CallbackHandler which simply delegates the authentication to its subclass overriding createSubject method, by passing to it a user name, password(possibly digest), etc.
The subclass will authenticate but also return a populated Subject which this CallbackHandler will store in the thread local storage to be later retrieved, at a moment when WSS4JInterceptor creates SecurityContext. Note that by default WSS4JInterceptor creates an incomplete SecurityContext which always returns 'false' in its isUserInRole. By letting subclasses to authenticate without implementing a CallbackHandler but also requiring them to populate a Subject we ensure that an authentication has been done but also make it possible to utilize a populated SecurityContext later on in the chain. Now, the above works for clear text passwords only at the moment (which might've been encrypted if passed over HTTP). To avoid a current WSS4J restriction with respect to digests, it also implements a simplified UsernameTokenProcessor but ultimately it also delegates to a subclass. Thanks for linking to that WSS4J jira. When CXF gets upgraded I can simplify the implementation dramatically by removing a Processor impl. hope it makes things clearer cheers, Sergey On Wed, Apr 7, 2010 at 5:22 PM, Sergey Beryozkin <sberyoz...@gmail.com>wrote: > Glen, > > > On Wed, Apr 7, 2010 at 5:12 PM, Glen Mazza <glen.ma...@gmail.com> wrote: > >> >> 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. >> > > I'm sorry but this does sounds convincing. You're kind of indicating that > what is proposed > is not good enough ? But you have not said anything about the > authorization. WSS4J is restricting with respects to digests at thje moment > but as I said, we're after the authorization here > > >> >> 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! >> > > I really don't follow why you refer to Metro, what is to do with the use of > CXF ? > > Sergey > > >> >> 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. >> >> >
