cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: Using WS-Security UsernameToken to authenticate users and populate SecurityContexts
Date Wed, 07 Apr 2010 17:00:05 GMT
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

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 <>wrote:

> Glen,
> On Wed, Apr 7, 2010 at 5:12 PM, Glen Mazza <> 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 ( 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
>> (
>> ).
>> 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:
>> Sent from the cxf-dev mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message