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 17:25:16 GMT
I've done an initial merge[1]. This should make it easier to explain what
has been done so far.
WSS4J-neutral SecurityTokens will implement [2], ex, see [3].

When opting for doing the authorization based on WSSE tokens, one configures
a jaxws endpoint using a property [4]
(see a jaxws bean with the "UsernameOverTransport" id), property is named
"" - can change it to a better name. We can also
introduce a more neutral property which would work better with all types of

This  property instructs WSS4JInInterceptor to ensure UT is processed
without callbacks and persist the UT details in an instance of [3]. Similar
work can be done for other tokens. Currently an instance of UT [3] is saved
on a message as SecurityToken[2]. If we have multiple tokens in the same
request we can also save in the list, say, SecurityTokensList.class.

If you check the jaxws bean at [3], you'll see it has two interceptors, one
is the custom subject creating interceptor [5] which creates a Subject and
it extends [6] which a utility abstract class for dealing with UTs which are
likely to be used often. It extends [7] which is a base utility class which
handlers for other tokens will extend, it ensures a security context using a
newly created subject is created.

This is all totally WSS4J neutral.

It might make sense to update AbstractUsernameTokenAuthenticating
interceptor to check if [3] is available on thje message and if yes then
just use it - it will let users who have already starting extending it work
their interceptors with the new approach too

Comments are welcome


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