cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Using WS-Security UsernameToken to authenticate users and populate SecurityContexts
Date Wed, 07 Apr 2010 15:55:10 GMT
Glen Mazza asks :

Quote: "Higher level containers should be able to delegate to their own
subsystems for authenticating a user and populating SecurityContext"

I'm not clear on something, why can't that be done (or why would it be
suboptimal/inconvenient for doing that) from the already provided
CallbackHandler anyway--have that class call whatever it needs to for
authentication to occur?

Glen, hope you're ok with me answering here:

There are few problems with depending on CallbackHandlers only :

- when passwords have been digested, WSS4JInterceptor requires a clear text
password back to verify a digest which is not realistic in cases where an
external system can authenticate a user with the digest password but have no
way of returning an actual password for this CallbackHandler to give it to
WSS4JInterceptor
- authentication is only part of the story, what is really important is that
the authorization can be done further down the line. I don't think trying to
do the authorization from the CallbackHandler is a good approach - we don't
even know the method name to be invoked upon

Now, perhaps one can even authenticate and authorize from a callback handler
by somehow getting to the current Message, figuring out the method name,
etc. But IMHO the proposed approach is cleaner and it gives more options as
to when an authorization should be done due to the fact we have a valid
SecurityContext in scope

cheers, Sergey



On Wed, Apr 7, 2010 at 4:02 PM, Alessio Soldano <asoldano@redhat.com> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message