Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: dev@cxf.apache.org
Cc: janb <jan.bernhardt@sopera.com>
Subject: Re: Changing username via Callback Handler
Date: Tue, 06 Dec 2011 15:25:56 -0500
Message-ID: <1484368.yBFcOAraSH@dilbert.dankulp.com>
User-Agent: KMail/4.7.3 (Linux/3.0.1; KDE/4.7.3; x86_64; ; )
In-Reply-To: <1323173296289-5051891.post@n5.nabble.com>
References: <1323173296289-5051891.post@n5.nabble.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"


I have no problem with the proposal, but I would like to point out that you 
can accomplish much of it today using existing functionality.   The call for 
the SecurityConstants.USERNAME property is done via a contextual property.   
Thus, it COULD be set via spring, but it can also be set in a variety of other 
ways such as an interceptor run before hand, via the request context of the 
client, etc....   I'm not sure how you are passing the password along, but you 
should likely be able to pass the username in a similar way and get it set to 
the unique value for that invokation.

Dan


On Tuesday, December 06, 2011 4:08:16 AM janb wrote:
> Hi I would like to start a discussion on extending the usage of a
> ClientCallbackHandler.
> 
> Currently the username for a a service consumer is rather static configured
> via ws-security.username property. This works great for situations where a
> user is fixed assigned to a service-consumer. But if different users call
> the same service consumer, it would be great, if these user-information
> could be dynamically forwarded to the service. Surely one way to do this
> (the recommended way) would be via ActAs or OnBehalfOf Token /
> CallbackHandler. But this works only, if the sts server can handle these
> token. In situations, where the sts server can not handle delegated
> identities, the usual ws-security authentication token could be used
> instead.
> 
> In my case a UsernamePassword Token should contain credentials from the
> person that calls my cxf client.
> Via CallbackHandler it is easy to pass the password along, but the username
> will always be taken from the (spring config) property. As far as I can see,
> there would be to methods within cxf that could be updatet to use the
> Username provided via a CallbackHandler instead of using the
> ws-security.username property.
> 
> This would be:
> *
> org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder#addUs
> ernameToken(UsernameToken token)
> *
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor#addUsernameToken(S
> oapMessage message, UsernameToken token)
> 
> Instead of calling
> utBuilder.setUserInfo(userName, password);
> with the username from
> String userName =
> (String)message.getContextualProperty(SecurityConstants.USERNAME);
> the callback handler should be called to provide both username and password.
> 
> The username from ws-security.username property would still be the initial
> (default) value, and only of the callbackhandler changes the username the
> WSSecUsernameToken would contain another username.
> 
> I hope I was able to transfer my thoughts via text ;-)
> 
> What are your thoughts about my proposal?
> 
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Changing-username-via-Callback-Handler-tp50
> 51891p5051891.html Sent from the cxf-dev mailing list archive at Nabble.com.
-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com