Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of sberyozkin@gmail.com designates
 209.85.220.212 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=lCXwHdDuF6DuiUdluDw7wF4DKrBjjDziHoLSwcpXfTR3Yab57c+MDsweMzXyyRmAPQ
         XTVLZgJjlwnhcn3sgU5EWVhyb30+ATzhxThyVwYVy8sJvsxRLjJUuXd8XIZKsXla1iZX
         GKtx/AqS08E6A6IavkbEC7XeV/lZywrbyjuUw=
MIME-Version: 1.0
In-Reply-To: <z2q602da591004070922w4d0b73c8w8b90eedd64ea25b1@mail.gmail.com>
References: <v2z602da591004070711g45bd754i14461fd9aa7c2313@mail.gmail.com>
	 <4BBC9E8F.8050105@redhat.com>
	 <u2h602da591004070855p49ca2b56lc13dd84b5f368969@mail.gmail.com>
	 <28167255.post@talk.nabble.com>
	 <z2q602da591004070922w4d0b73c8w8b90eedd64ea25b1@mail.gmail.com>
Date: Wed, 7 Apr 2010 18:00:05 +0100
Message-ID: <p2n602da591004071000u6ed3fd9av83e6c68890a929d2@mail.gmail.com>
Subject: Re: Using WS-Security UsernameToken to authenticate users and
	populate SecurityContexts
From: Sergey Beryozkin <sberyozkin@gmail.com>
To: dev@cxf.apache.org
Content-Type: multipart/alternative; boundary=001485f7beda6d40180483a87ef4

--001485f7beda6d40180483a87ef4
Content-Type: text/plain; charset=ISO-8859-1

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 <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.
>>
>>
>

--001485f7beda6d40180483a87ef4--