cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: How to use WSSE tokens for authorization decisions without extending WSS4JInInterceptor
Date Wed, 13 Oct 2010 17:20:39 GMT
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 <sberyozkin@gmail.com>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
>

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