cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject How to use WSSE tokens for authorization decisions without extending WSS4JInInterceptor
Date Wed, 13 Oct 2010 17:16:41 GMT
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] https://issues.apache.org/jira/browse/CXF-3063

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