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 16:23:40 GMT
typo, missed 'not'

"I'm sorry but this does *not* sounds convincing."

On Wed, Apr 7, 2010 at 5:22 PM, Sergey Beryozkin <sberyozkin@gmail.com>wrote:

> Glen,
>
>
> On Wed, Apr 7, 2010 at 5:12 PM, Glen Mazza <glen.mazza@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.
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message