You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Sergey Beryozkin <sb...@gmail.com> on 2010/04/07 17:55:10 UTC
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
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 <as...@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
>
>
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
typo, missed 'not'
"I'm sorry but this does *not* sounds convincing."
On Wed, Apr 7, 2010 at 5:22 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Glen,
>
>
> On Wed, Apr 7, 2010 at 5:12 PM, Glen Mazza <gl...@gmail.com> wrote:
>
>>
>> Sergey, be careful with your first reason--that of using the
>> CallbackHandlers
>> to *return* passwords, that's an old erroneous design apparently since
>> fixed
>> in WSS4J (https://issues.apache.org/jira/browse/WSS-183) that should not
>> necessarily be used as a reason for doing what you're doing--that process
>> should be taken out of CXF instead when it upgrades to the new WSS4J.
>>
>
> I'm sorry but this does sounds convincing. You're kind of indicating that
> what is proposed
> is not good enough ? But you have not said anything about the
> authorization. WSS4J is restricting with respects to digests at thje moment
> but as I said, we're after the authorization here
>
>
>>
>> Actually, I think Metro does what you want--allows the option for
>> container-managed authentication *without* the callbackhandler
>> (http://www.jroller.com/gmazza/entry/metro_usernametoken_profile#MetroUT3
>> ).
>> If you can repeat the same with CXF, great!
>>
>
> I really don't follow why you refer to Metro, what is to do with the use of
> CXF ?
>
> Sergey
>
>
>>
>> Glen
>>
>>
>> Sergey Beryozkin-5 wrote:
>> >
>> > 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
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Using-WS-Security-UsernameToken-to-authenticate-users-and-populate--SecurityContexts-tp28165583p28167255.html
>> Sent from the cxf-dev mailing list archive at Nabble.com.
>>
>>
>
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Glen
On Wed, Apr 7, 2010 at 6:25 PM, Glen Mazza <gl...@gmail.com> wrote:
>
>
> Glen,
>
>
> On Wed, Apr 7, 2010 at 5:12 PM, Glen Mazza <gl...@gmail.com> wrote:
>
> >
> > Sergey, be careful with your first reason--that of using the
> > CallbackHandlers
> > to *return* passwords, that's an old erroneous design apparently since
> > fixed
> > in WSS4J (https://issues.apache.org/jira/browse/WSS-183) that should not
> > necessarily be used as a reason for doing what you're doing--that process
> > should be taken out of CXF instead when it upgrades to the new WSS4J.
> >
>
> >I'm sorry but this does [not] sounds convincing. You're kind of indicating
> that
> >what is proposed is not good enough ? But you have not said anything about
> the authorization.
> >WSS4J is restricting with respects to digests at thje moment but as I
> said,
> >we're after the authorization here.
>
> All I'm saying is that if you're using the argument of "CXF requires
> passwords to be supplied in the CallbackHandlers!" as a reason for doing
> what you're doing, that's not valid anymore because that problem is fixed
> with the new WSS4J.
I guess I was not specific enough, hope my follow-up response made things
clearer.
> I'm sure however there are plenty of other good reasons
> for doing what you're doing, it's just that that particular one should soon
> no longer be relevant. I was also mentioning this to you in case you were
> unaware of the problem and were thinking of a solution which involved the
> Callbackhandler continuing to serve its erroneous dual role
> (https://issues.apache.org/jira/browse/WSS-183,
> https://issues.apache.org/jira/browse/CXF-2150) of validating credentials
> for password text and providing credentials for password digest for some
> higher entity to validate.
>
I'm aware of this problem but it is an orthogonal one. Likewise not sure
what you mean by a dual role. In this case a callback handler only requires
a subclass to do the authentication.
>
>
> >
> > Actually, I think Metro does what you want--allows the option for
> > container-managed authentication *without* the callbackhandler
> > (
> http://www.jroller.com/gmazza/entry/metro_usernametoken_profile#MetroUT3
> > ).
> > If you can repeat the same with CXF, great!
> >
>
> > I really don't follow why you refer to Metro, what is to do with the use
> > of
> > CXF ?
>
> It was meant as a sanity check that whatever you are proposing is also
> being
> done by another web service stack. But I misunderstood what you were
> proposing, hence what I was saying above is not relevant. You're talking
> about authorization, not authentication. Never min
I'm talking about both authentication and authorization. I believe the
proposed solution makes it more easier to authorize, as I tried to clarify
in the other email.
cheers, Sergey
> d.
>
> Glen
>
> --
> View this message in context:
> http://old.nabble.com/Using-WS-Security-UsernameToken-to-authenticate-users-and-populate--SecurityContexts-tp28165583p28168187.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
>
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Glen Mazza <gl...@gmail.com>.
Glen,
On Wed, Apr 7, 2010 at 5:12 PM, Glen Mazza <gl...@gmail.com> wrote:
>
> Sergey, be careful with your first reason--that of using the
> CallbackHandlers
> to *return* passwords, that's an old erroneous design apparently since
> fixed
> in WSS4J (https://issues.apache.org/jira/browse/WSS-183) that should not
> necessarily be used as a reason for doing what you're doing--that process
> should be taken out of CXF instead when it upgrades to the new WSS4J.
>
>I'm sorry but this does [not] sounds convincing. You're kind of indicating
that
>what is proposed is not good enough ? But you have not said anything about
the authorization.
>WSS4J is restricting with respects to digests at thje moment but as I said,
>we're after the authorization here.
All I'm saying is that if you're using the argument of "CXF requires
passwords to be supplied in the CallbackHandlers!" as a reason for doing
what you're doing, that's not valid anymore because that problem is fixed
with the new WSS4J. I'm sure however there are plenty of other good reasons
for doing what you're doing, it's just that that particular one should soon
no longer be relevant. I was also mentioning this to you in case you were
unaware of the problem and were thinking of a solution which involved the
Callbackhandler continuing to serve its erroneous dual role
(https://issues.apache.org/jira/browse/WSS-183,
https://issues.apache.org/jira/browse/CXF-2150) of validating credentials
for password text and providing credentials for password digest for some
higher entity to validate.
>
> Actually, I think Metro does what you want--allows the option for
> container-managed authentication *without* the callbackhandler
> (http://www.jroller.com/gmazza/entry/metro_usernametoken_profile#MetroUT3
> ).
> If you can repeat the same with CXF, great!
>
> I really don't follow why you refer to Metro, what is to do with the use
> of
> CXF ?
It was meant as a sanity check that whatever you are proposing is also being
done by another web service stack. But I misunderstood what you were
proposing, hence what I was saying above is not relevant. You're talking
about authorization, not authentication. Never mind.
Glen
--
View this message in context: http://old.nabble.com/Using-WS-Security-UsernameToken-to-authenticate-users-and-populate--SecurityContexts-tp28165583p28168187.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
Actually Glen, sorry for a speedy reply.
Here are some more clarifications.
Please have a look at the source of the
AbstractWSS4JSecurityContextProviding interceptor. In a nutshell, it is a
complex CallbackHandler which simply delegates the authentication to its
subclass overriding createSubject method, by passing to it a user name,
password(possibly digest), etc.
The subclass will authenticate but also return a populated Subject which
this CallbackHandler will store in the thread local storage to be later
retrieved, at a moment when WSS4JInterceptor creates SecurityContext. Note
that by default WSS4JInterceptor creates an incomplete SecurityContext which
always returns 'false' in its isUserInRole. By letting subclasses to
authenticate without implementing a CallbackHandler but also requiring them
to populate a Subject we ensure that an authentication has been done but
also make it possible to utilize a populated SecurityContext later on in the
chain.
Now, the above works for clear text passwords only at the moment (which
might've been encrypted if passed over HTTP). To avoid a current WSS4J
restriction with respect to digests, it also implements a simplified
UsernameTokenProcessor but ultimately it also delegates to a subclass.
Thanks for linking to that WSS4J jira. When CXF gets upgraded I can simplify
the implementation dramatically by removing a Processor impl.
hope it makes things clearer
cheers, Sergey
On Wed, Apr 7, 2010 at 5:22 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Glen,
>
>
> On Wed, Apr 7, 2010 at 5:12 PM, Glen Mazza <gl...@gmail.com> wrote:
>
>>
>> Sergey, be careful with your first reason--that of using the
>> CallbackHandlers
>> to *return* passwords, that's an old erroneous design apparently since
>> fixed
>> in WSS4J (https://issues.apache.org/jira/browse/WSS-183) that should not
>> necessarily be used as a reason for doing what you're doing--that process
>> should be taken out of CXF instead when it upgrades to the new WSS4J.
>>
>
> I'm sorry but this does sounds convincing. You're kind of indicating that
> what is proposed
> is not good enough ? But you have not said anything about the
> authorization. WSS4J is restricting with respects to digests at thje moment
> but as I said, we're after the authorization here
>
>
>>
>> Actually, I think Metro does what you want--allows the option for
>> container-managed authentication *without* the callbackhandler
>> (http://www.jroller.com/gmazza/entry/metro_usernametoken_profile#MetroUT3
>> ).
>> If you can repeat the same with CXF, great!
>>
>
> I really don't follow why you refer to Metro, what is to do with the use of
> CXF ?
>
> Sergey
>
>
>>
>> Glen
>>
>>
>> Sergey Beryozkin-5 wrote:
>> >
>> > 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
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Using-WS-Security-UsernameToken-to-authenticate-users-and-populate--SecurityContexts-tp28165583p28167255.html
>> Sent from the cxf-dev mailing list archive at Nabble.com.
>>
>>
>
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
Glen,
On Wed, Apr 7, 2010 at 5:12 PM, Glen Mazza <gl...@gmail.com> wrote:
>
> Sergey, be careful with your first reason--that of using the
> CallbackHandlers
> to *return* passwords, that's an old erroneous design apparently since
> fixed
> in WSS4J (https://issues.apache.org/jira/browse/WSS-183) that should not
> necessarily be used as a reason for doing what you're doing--that process
> should be taken out of CXF instead when it upgrades to the new WSS4J.
>
I'm sorry but this does sounds convincing. You're kind of indicating that
what is proposed
is not good enough ? But you have not said anything about the authorization.
WSS4J is restricting with respects to digests at thje moment but as I said,
we're after the authorization here
>
> Actually, I think Metro does what you want--allows the option for
> container-managed authentication *without* the callbackhandler
> (http://www.jroller.com/gmazza/entry/metro_usernametoken_profile#MetroUT3
> ).
> If you can repeat the same with CXF, great!
>
I really don't follow why you refer to Metro, what is to do with the use of
CXF ?
Sergey
>
> Glen
>
>
> Sergey Beryozkin-5 wrote:
> >
> > 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
> >
>
> --
> View this message in context:
> http://old.nabble.com/Using-WS-Security-UsernameToken-to-authenticate-users-and-populate--SecurityContexts-tp28165583p28167255.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
>
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Glen Mazza <gl...@gmail.com>.
Sergey, be careful with your first reason--that of using the CallbackHandlers
to *return* passwords, that's an old erroneous design apparently since fixed
in WSS4J (https://issues.apache.org/jira/browse/WSS-183) that should not
necessarily be used as a reason for doing what you're doing--that process
should be taken out of CXF instead when it upgrades to the new WSS4J.
Actually, I think Metro does what you want--allows the option for
container-managed authentication *without* the callbackhandler
(http://www.jroller.com/gmazza/entry/metro_usernametoken_profile#MetroUT3).
If you can repeat the same with CXF, great!
Glen
Sergey Beryozkin-5 wrote:
>
> 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
>
--
View this message in context: http://old.nabble.com/Using-WS-Security-UsernameToken-to-authenticate-users-and-populate--SecurityContexts-tp28165583p28167255.html
Sent from the cxf-dev mailing list archive at Nabble.com.