cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Mansfield <>
Subject Re: STSClient validateSecurityToken question
Date Wed, 24 Apr 2013 15:24:15 GMT
Hi Colm:

Basically it seems the problem is that I would have to meddle around 
with the config of the WSS4JOutInterceptor all the time (per request), I 
guess, changing the 'action' configuration from UsernameToken to 
SAMLTokenSigned and all that.

I'm not sure I understand how to do that except for via spring 
configuration files which are static - also it's not "my" web service 
client object, it's a web service client object held by the STSClient 

Regarding issue #2: you got it, they don't want a ValidateTarget element 
at all (although I don't know what would happen if it was provided 
anyway). Since the token is in the security header, I guess it's all 
they need.

On 04/24/2013 11:04 AM, Colm O hEigeartaigh wrote:
> Hi,
> What's stopping you from meeting the requirements for (1)? If you have
> access to the SecurityToken object from the issue call, it should be
> possible to set the STSClient up accordingly.
> In respect to (2), I'm not sure I follow exactly. You want to call the
> Validate operation without passing a ValidateTarget Element at all?
> Colm.
> On Wed, Apr 24, 2013 at 2:42 PM, David Mansfield <> wrote:
>> Hi All,
>> I've been working trying to get the CXF STSClient to work with a partner's
>> almost-compliant implementation, and so far (with help from you all) gotten
>> the "issue" (requestSecurityToken) to work perfectly.  Now I'm looking at
>> "validate"
>> Note: there is no security policy so everything is configured manually
>> (including adding and configuring the WSS4JOutInterceptor to the bus used
>> by the sts client).
>> The default validateSecurityToken is not working because with CXF
>> STSClient:
>> 1) the same UsernameToken (with different nonce etc). that was used in the
>> issue request is used in the validate request inside the wsse:Security
>> header in the soap:header (and used for signing)
>> 2) the previously issued security token is placed in the soap:body inside
>> the wst:ValidateTarget element.
>> But our partner's STS wants:
>> 1) to authenticate with the previously issued security token (which is a
>> signed saml:Assertion) in the wsse:Security and use the BinarySecret
>> provided in the "issue" to sign the various required signed elements in the
>> document
>> 2) elide the ValidateTarget element in the body completely.
>> I don't know if #2 is necessary or not, but it's what their documentation
>> shows.
>> Is this behavior anything like any implementation seen anywhere "in the
>> wild'?  Is there any reasonably direct way to make this happen with cxf
>> STSClient?

View raw message