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
