You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Glen Mazza <gl...@gmail.com> on 2010/04/07 18:12:22 UTC
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
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.
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.
>
>