Actually, I've added rt/core/src/main/java/org/apache/cxf/interceptor/security/SecureAnnotationsInterceptor.java
to the patch as well. I did not mean to, this file was sitting on my disk for few months at least :-) but got included as I added few more files there. So I guess I'll just add few tests for it, the idea for it is that users just register it and initialize with a service bean reference and the interceptor will ensure @RolesAllowed are enforced. This is the alternative to using SimpleAuthorizingInInterceptor which is initialized with a map of roles/permissions explicitly cheers, Sergey 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 >
