cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessio Soldano <asold...@redhat.com>
Subject Re: Using WS-Security UsernameToken to authenticate users and populate SecurityContexts
Date Wed, 07 Apr 2010 15:02:39 GMT
Hi Sergey,
needless to say, I really like this.
Just ping me of course when you move to the JBossWS side of this topic 
to do the tests.
Cheers
Alessio

Sergey Beryozkin wrote:
> Hi
>
> I've been looking recently at extending the CXF WS-Security component such
> that a current UsernameToken could be used by custom interceptors
> to authenticate a user with the external security systems and, if possible,
> provide enough information for CXF to populate a SecurityContext [1] to be
> used later on for
> authorization decisions.
>
> Here is the approach I've taken so far.
> A custom interceptor extends
> AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only method it
> overrides is
>
> abstract Subject createSubject(String name, String password, boolean isDigest,
>
>                                     String nonce,
>                                     String created) throws WSSecurityException;
>
>
> For example, see [3].
>
> The idea here is that a custom interceptor interfaces whichever way it needs
> to with the external system and populates a Subject following this simple
> rule : first Subject principal is the current user (identified by a 'name'
> argument), followed by one or more Groups this user is a member of.
> AbstractWSS4JSecurityContextProvidingInterceptor will use this Subject to
> provide a functional SecurityContext instance.
>
> This is the first part, next is how to utilize a SecurityContext and get the
> expected roles associated one way or the other with a current method to be
> invoked. There's a number of usual options available here, perhaps even
> SpringSecurity can be used now that SecurityContext is available, or
> application code or other custom CXF interceptor can check the known roles
> against SecurityContext.
>
> I've also added AbstractAuthorizingInInterceptor interceptor which custom
> interceptors can override and return a list of expected roles given a
> (service) Method to be invoked upon, AbstractAuthorizingInInterceptor will
> then ask available SecurityContext to match the roles; one concrete
> implementation is SimpleAuthorizingInterceptor[5], it can be injected with a
> method specific or class (applying to all methods) roles. Another
> implementation which I will likely add later on will be injected with a name
> of annotation such as RolesAlloved and it will introspect a method and its
> class.
>
> Note that I haven't looked into the case when a policy runtimes adds the
> interceptors yet (as opposed to interceptors being configured form
> Spring/programmatically). I think an optional contextual property will need
> to be setup in such cases for users be able to indicate that say an
> interceptor such as [3] has to be used as opposed to WSS4JInInterceptor,
> etc.
>
> I'm going to validate this approach with JBoss CXF. If you have any comments
> then please let me know.
>
> I think we may have a simpler alternative eventually to the way
> authorization decisions are made. [1]-[3] is specific to ws-security, but
> [4]-[5] is not
>
> cheers, Sergey
>
> [1] https://issues.apache.org/jira/browse/CXF-2754
> [2]
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingInterceptor.java
> [3]
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/apache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java
> [4]
> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/cxf/interceptor/security/AbstractAuthorizingInInterceptor.java
> [5]
> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/cxf/interceptor/security/SimpleAuthorizingInterceptor.java
>
>   


-- 
Alessio Soldano
Web Service Lead, JBoss


Mime
View raw message