cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: How to use WSSE tokens for authorization decisions without extending WSS4JInInterceptor
Date Thu, 14 Oct 2010 11:05:18 GMT

My current concern is that I've added a SecurityToken interface into a
common/common, alongside with UsernameToken which implements it. Perhaps the
interface should be moved into cxf/api and UsernameToken (and other similar
SecurityToken beans) can be moved into rt/core. Not sure if we want to
introduce another dedicated module such as rt/security.
I'm inclined to go ahead and merge into 2.4.0-SNAPSHOT, it will be easier to
see how things are implemented and then we will do a couple of more
follow-up merges if needed

cheers, Sergey

On Wed, Oct 13, 2010 at 6:16 PM, Sergey Beryozkin <>wrote:

> Hi there
> Few months ago I created an AbstractUsernameTokenAuthenticatingInterceptor
> which extends WSS4JInInterceptor and provides an easy extension point for
> custom interceptors to be able to create a Subject by delegating to their
> own stores. Combining it with a shipped SimpleAuthorizingInterceptor made it
> easy to do the authorization decisions based on the information originally
> extracted from WSSE UserTokens only.
> This works pretty well in cases with no built-in WS-Policy expressions and
> when only UsernameTokens are used to create Principals.
> David V. had some thoughts around delegating instead. So we've hit an issue
> with PolicyBasedWSS4JInInterceptors being used alongside with
> AbstractUsernameTokenAuthenticatingInterceptor-extending ingterceptors
> recently and it just does not work.
> Note that earlier on, in case when only UsernameToken WS-Policies are used,
> I modified UsernameTokenInInterceptor (which is used instead of
> WSS4JInInterceptor in policy first cases) such that a custom interceptor can
> easily extend it as well.
> However, I've thought that extending PolicyBasedWSS4JInInterceptors too is
> just not a very good idea. It is time to start looking for a new solution,
> so I've created CXF-3063 [1] and attached a patch.
> The idea is that WSS4JInInterceptor is asked via a jaxws property that no
> callbacks have been registered for either plain or digest passwords which
> instructs
> WSS4JInInterceptor to register empty callbacks and custom UT processors for
> WSS4J to work nicely (something what
> AbstractUsernameTokenAuthenticatingInterceptor) does now.
> Additionally, WSS4JInInterceptor saves the UsernameToken details in a
> common/utility CXF UsernameToken bean. This provides for 2 advantages : no
> WSS4J dependencies are needed for custom interceptors further down the line
> and also they will deal with token beans as opposed to individual properties
> which will  make it easy for us to update UsernameToken.
> Note that CXF UsernameToken implements CXF SecurityToken interface which
> has a single method getTokenType() which returns the enum type. Thus custom
> interceptors can check if they recognize a current type, and if yes then
> cast to UsernameToken, BinaryToken, etc.
> rt/core has a base abstract interceptor and UT-aware abstract interceptor
> which makes it very easy for users to focus on creating Subjects only. Whcih
> is shown in the tests.
> Additionally, I kind of expect that CXF UsernameTokens, etc, will be used
> by future JAXRS advanced security code...
> Comments are welcome.
> thanks, Sergey
> [1]

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