cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessio Soldano <>
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.

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]
> [2]
> [3]
> [4]
> [5]

Alessio Soldano
Web Service Lead, JBoss

View raw message