On Wednesday, October 19, 2011 11:00:51 AM Oliver Wulff wrote:
> Hi guys
>
> I've got a question with respect to a deployment of CXF in an intermediary
> scenario. The service implementation of the intermediary injects the proxy
> instance for the target service it will call. Of course, this is a multi
> threaded environment where the service implementation gets the current user
> as part of the incoming message (not ws-security).
>
> The target service expects to get a security token issued by the STS. The
> username is expected to be set for the proxy and the
> WSSUsernameCallbackHandler is configured to get the user from there.
>
> Here a snippet of the configuration:
>
> <jaxws:client
> name="{http://www.example.org/contract/DoubleIt}DoubleItTransportIONABSTPor
> t" createdFromAPI="true"> <jaxws:properties>
> <entry key="ws-security.sts.client">
> <bean class="org.apache.cxf.ws.security.trust.STSClient">
> <constructor-arg ref="cxf"/>
> <property name="onBehalfOf"
> ref="delegationCallbackHandler" />
>
>
> The implementation of the intermediary service gets the BindingProvider and
> adds the username like this:
>
> BindingProvider.getRequestcontext().put(BindingProvider.USERNAME_PROPERTY,
> "myuser)
>
> Has the request context the scope of the current thread or is it tight to
> the proxy instance.
This is answered in the FAQ:
http://cxf.apache.org/faq#FAQ-AreJAXWSclientproxiesthreadsafe%3F
> If latter, an intermediary must create a new proxy per
> request. If the former, what is the scope of the STSClient instance?
Per proxy.
> If
> there are several requests coming in, the proxy instance is global, the
> request context is correlated with the thread (assumption) it might not
> work because there is only one STSClient instance.
The SecureConv and IssuedToken interceptors current "sync" on the client
object to make sure this case works. It definitely can be a performance
issue though.
--
Daniel Kulp
[email protected]
http://dankulp.com/blog
Talend - http://www.talend.com
