Hi > > 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 > > Here it is : http://svn.apache.org/viewvc?view=revision&revision=1022884
So those users who are already working with AbstractUsernameTokenAuthenticating subclasses can continue using them for policy first cases too... Sergey > Comments are welcome > Sergey > > [1] http://svn.apache.org/viewvc?rev=1022599&view=rev > [2] > http://svn.apache.org/repos/asf/cxf/trunk/common/common/src/main/java/org/apache/cxf/common/security/SecurityToken.java > [3] > http://svn.apache.org/repos/asf/cxf/trunk/common/common/src/main/java/org/apache/cxf/common/security/UsernameToken.java > [4] > http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/wssec10/server/server_restricted_authorized.xml > [5] > http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/wssec10/server/SimpleUsernameTokenInterceptor.java > [6] > http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/cxf/interceptor/security/AbstractUsernameTokenInInterceptor.java > [7] > http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/cxf/interceptor/security/AbstractSecurityContextInInterceptor.java > > On Wed, Oct 13, 2010 at 6:16 PM, Sergey Beryozkin <[email protected]>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] https://issues.apache.org/jira/browse/CXF-3063 >> > >
