You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by David Mansfield <cx...@dm.cobite.com> on 2013/04/24 15:42:37 UTC
STSClient validateSecurityToken question
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?
Re: STSClient validateSecurityToken question
Posted by Colm O hEigeartaigh <co...@apache.org>.
> 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.
Could you have a different interceptor for both Issue + Validate? I don't
see a way around this to be honest...
> 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.
The WS-Trust spec says that the ValidateTarget Element is required for the
Validate operation...
/wst:RequestSecurityToken/wst:ValidateTarget
Colm.
On Wed, Apr 24, 2013 at 4:24 PM, David Mansfield <da...@cobite.com> wrote:
> 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
> instance.
>
> 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 <cx...@dm.cobite.com>
>> 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?
>>>
>>>
>>>
>>>
>>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: STSClient validateSecurityToken question
Posted by David Mansfield <da...@cobite.com>.
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
instance.
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 <cx...@dm.cobite.com> 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?
>>
>>
>>
>
Re: STSClient validateSecurityToken question
Posted by David Mansfield <cx...@dm.cobite.com>.
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
instance.
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 <cx...@dm.cobite.com> 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?
>>
>>
>>
>
Re: STSClient validateSecurityToken question
Posted by Colm O hEigeartaigh <co...@apache.org>.
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 <cx...@dm.cobite.com> 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?
>
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com