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 Valeri <dv...@apache.org> on 2010/07/22 17:25:35 UTC
WS-T / WS-SP sp:RequestSecurityTokenTemplate not using wst:SecondaryParameters
It would appear that the STS client is not properly copying the
sp:RequestSecurityTokenTemplate contents into the wst:RequestSecurityToken
element.
Per the WS-SP 1.2 spec, section 5.4.2, "This required element contains
elements which MUST be copied into the wst:SecondaryParameters of the RST
request sent to the specified issuer. Note: the initiator is not required to
understand the contents of this element."
The STS client copies these values directly into the body of the
wst:RequestSecurityToken element in the request to the STS.
So this policy:
<sp:IssuedToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/I
ncludeToken/Always">
<sp:RequestSecurityTokenTemplate>
<wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1
.1#SAMLV1.1</wst:TokenType>
<wst:AppliesTo>
<wsp:URI>service-1</wsp:URI>
</wst:AppliesTo>
<wst:Participants>
<wst:Participant>
<wsp:URI>service-1</wsp:URI>
</wst:Participant>
</wst:Participants>
<wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey</wst
:KeyType>
</sp:RequestSecurityTokenTemplate>
</sp:IssuedToken>
Becomes this request:
<wst:RequestSecurityToken>
...
<wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1
.1#SAMLV1.1</wst:TokenType>
<wst:AppliesTo>
<wsp:URI>service-1</wsp:URI>
</wst:AppliesTo>
<wst:Participants>
<wst:Participant>
<wsp:URI>service-1</wsp:URI>
</wst:Participant>
</wst:Participants>
<wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey</wst
:KeyType>
...
</wst:RequestSecurityToken>
Instead of:
<wst:RequestSecurityToken>
...
<wst:SecondaryParameters>
<wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1
.1#SAMLV1.1</wst:TokenType>
<wst:AppliesTo>
<wsp:URI>service-1</wsp:URI>
</wst:AppliesTo>
<wst:Participants>
<wst:Participant>
<wsp:URI>service-1</wsp:URI>
</wst:Participant>
</wst:Participants>
<wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey</wst
:KeyType>
</wst:SecondaryParameters>
...
</wst:RequestSecurityToken>
Before I create an issue report and patch, I wanted to know if there is
another usage of the code (Secure Conversation, specific STS implementation,
Specific spec version, etc.) that would dictate that this copying occur as
it does now. I don't see any unit or systests that cover this code.
Re: WS-T / WS-SP sp:RequestSecurityTokenTemplate not using wst:SecondaryParameters
Posted by Daniel Kulp <dk...@apache.org>.
On Monday 26 July 2010 1:12:52 pm David Valeri wrote:
> It looks like the WS-Trust 1.3 WSDLs moved to port 8080 on 131.107.153.205.
> I had to change the port to get the samples running using the 2.2.9
> binaries and the sample code from the trunk. Do you know any more info
> about the port number change or know of public info on the MS services?
Nope, but doesn't really surprise me. They tend to move things around
periodically and break things. :-(
Dan
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Friday, July 23, 2010 3:57 PM
> To: users@cxf.apache.org
> Cc: David Valeri
> Subject: Re: WS-T / WS-SP sp:RequestSecurityTokenTemplate not using
> wst:SecondaryParameters
>
>
> David,
>
> Check the WS-Trust interop-plugfest things.
> (samples/ws_security/interopfest)
>
> I think it's done the current way to interop with .NET as that's what it
> was
>
> expecting for the interop stuff. However, it MAY also work with sticking
> it
> in a SecondaryParameters thing.
>
> That said, it may also be a SP version thing. I cannot remember what
> version
> of the SP stuff the interop-plugfest scenarios are using.
>
> In anycase, I'm ok logging a bug and changing it, but definitely run those
> scenarios to make sure they don't break if you do so.
>
> Dan
>
> On Thursday 22 July 2010 11:25:35 am David Valeri wrote:
> > It would appear that the STS client is not properly copying the
> > sp:RequestSecurityTokenTemplate contents into the
> > wst:RequestSecurityToken element.
> >
> > Per the WS-SP 1.2 spec, section 5.4.2, "This required element contains
> > elements which MUST be copied into the wst:SecondaryParameters of the RST
> > request sent to the specified issuer. Note: the initiator is not required
> > to understand the contents of this element."
> >
> > The STS client copies these values directly into the body of the
> > wst:RequestSecurityToken element in the request to the STS.
> >
> > So this policy:
> > <sp:IssuedToken
>
> sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/
>
> > I ncludeToken/Always">
> >
> > <sp:RequestSecurityTokenTemplate>
>
> <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-
>
> > 1 .1#SAMLV1.1</wst:TokenType>
> >
> > <wst:AppliesTo>
> >
> > <wsp:URI>service-1</wsp:URI>
> >
> > </wst:AppliesTo>
> > <wst:Participants>
> >
> > <wst:Participant>
> >
> > <wsp:URI>service-1</wsp:URI>
> >
> > </wst:Participant>
> >
> > </wst:Participants>
>
> <wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey</ws
>
> > t
> >
> > :KeyType>
> > :
> > </sp:RequestSecurityTokenTemplate>
> >
> > </sp:IssuedToken>
> >
> > Becomes this request:
> >
> > <wst:RequestSecurityToken>
> >
> > ...
>
> <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-
>
> > 1 .1#SAMLV1.1</wst:TokenType>
> >
> > <wst:AppliesTo>
> >
> > <wsp:URI>service-1</wsp:URI>
> >
> > </wst:AppliesTo>
> > <wst:Participants>
> >
> > <wst:Participant>
> >
> > <wsp:URI>service-1</wsp:URI>
> >
> > </wst:Participant>
> >
> > </wst:Participants>
>
> <wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey</ws
>
> > t
> >
> > :KeyType>
> > :
> > ...
> >
> > </wst:RequestSecurityToken>
> >
> > Instead of:
> >
> > <wst:RequestSecurityToken>
> >
> > ...
> > <wst:SecondaryParameters>
>
> <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-
>
> > 1 .1#SAMLV1.1</wst:TokenType>
> >
> > <wst:AppliesTo>
> >
> > <wsp:URI>service-1</wsp:URI>
> >
> > </wst:AppliesTo>
> > <wst:Participants>
> >
> > <wst:Participant>
> >
> > <wsp:URI>service-1</wsp:URI>
> >
> > </wst:Participant>
> >
> > </wst:Participants>
>
> <wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey</ws
>
> > t
> >
> > :KeyType>
> > :
> > </wst:SecondaryParameters>
> > ...
> >
> > </wst:RequestSecurityToken>
> >
> > Before I create an issue report and patch, I wanted to know if there is
> > another usage of the code (Secure Conversation, specific STS
> > implementation, Specific spec version, etc.) that would dictate that this
> > copying occur as it does now. I don't see any unit or systests that
> > cover this code.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
RE: WS-T / WS-SP sp:RequestSecurityTokenTemplate not using wst:SecondaryParameters
Posted by David Valeri <dv...@apache.org>.
It looks like the WS-Trust 1.3 WSDLs moved to port 8080 on 131.107.153.205.
I had to change the port to get the samples running using the 2.2.9 binaries
and the sample code from the trunk. Do you know any more info about the
port number change or know of public info on the MS services?
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: Friday, July 23, 2010 3:57 PM
To: users@cxf.apache.org
Cc: David Valeri
Subject: Re: WS-T / WS-SP sp:RequestSecurityTokenTemplate not using
wst:SecondaryParameters
David,
Check the WS-Trust interop-plugfest things.
(samples/ws_security/interopfest)
I think it's done the current way to interop with .NET as that's what it was
expecting for the interop stuff. However, it MAY also work with sticking
it
in a SecondaryParameters thing.
That said, it may also be a SP version thing. I cannot remember what
version
of the SP stuff the interop-plugfest scenarios are using.
In anycase, I'm ok logging a bug and changing it, but definitely run those
scenarios to make sure they don't break if you do so.
Dan
On Thursday 22 July 2010 11:25:35 am David Valeri wrote:
> It would appear that the STS client is not properly copying the
> sp:RequestSecurityTokenTemplate contents into the wst:RequestSecurityToken
> element.
>
> Per the WS-SP 1.2 spec, section 5.4.2, "This required element contains
> elements which MUST be copied into the wst:SecondaryParameters of the RST
> request sent to the specified issuer. Note: the initiator is not required
> to understand the contents of this element."
>
> The STS client copies these values directly into the body of the
> wst:RequestSecurityToken element in the request to the STS.
>
> So this policy:
> <sp:IssuedToken
>
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/
> I ncludeToken/Always">
> <sp:RequestSecurityTokenTemplate>
>
>
<wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-
> 1 .1#SAMLV1.1</wst:TokenType>
> <wst:AppliesTo>
> <wsp:URI>service-1</wsp:URI>
> </wst:AppliesTo>
> <wst:Participants>
> <wst:Participant>
> <wsp:URI>service-1</wsp:URI>
> </wst:Participant>
> </wst:Participants>
>
>
<wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey</ws
> t
>
> :KeyType>
>
> </sp:RequestSecurityTokenTemplate>
> </sp:IssuedToken>
>
> Becomes this request:
>
> <wst:RequestSecurityToken>
> ...
>
>
<wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-
> 1 .1#SAMLV1.1</wst:TokenType>
> <wst:AppliesTo>
> <wsp:URI>service-1</wsp:URI>
> </wst:AppliesTo>
> <wst:Participants>
> <wst:Participant>
> <wsp:URI>service-1</wsp:URI>
> </wst:Participant>
> </wst:Participants>
>
>
<wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey</ws
> t
>
> :KeyType>
>
> ...
> </wst:RequestSecurityToken>
>
> Instead of:
>
> <wst:RequestSecurityToken>
> ...
> <wst:SecondaryParameters>
>
>
<wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-
> 1 .1#SAMLV1.1</wst:TokenType>
> <wst:AppliesTo>
> <wsp:URI>service-1</wsp:URI>
> </wst:AppliesTo>
> <wst:Participants>
> <wst:Participant>
> <wsp:URI>service-1</wsp:URI>
> </wst:Participant>
> </wst:Participants>
>
>
<wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey</ws
> t
>
> :KeyType>
>
> </wst:SecondaryParameters>
> ...
> </wst:RequestSecurityToken>
>
> Before I create an issue report and patch, I wanted to know if there is
> another usage of the code (Secure Conversation, specific STS
> implementation, Specific spec version, etc.) that would dictate that this
> copying occur as it does now. I don't see any unit or systests that cover
> this code.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: WS-T / WS-SP sp:RequestSecurityTokenTemplate not using wst:SecondaryParameters
Posted by Daniel Kulp <dk...@apache.org>.
David,
Check the WS-Trust interop-plugfest things.
(samples/ws_security/interopfest)
I think it's done the current way to interop with .NET as that's what it was
expecting for the interop stuff. However, it MAY also work with sticking it
in a SecondaryParameters thing.
That said, it may also be a SP version thing. I cannot remember what version
of the SP stuff the interop-plugfest scenarios are using.
In anycase, I'm ok logging a bug and changing it, but definitely run those
scenarios to make sure they don't break if you do so.
Dan
On Thursday 22 July 2010 11:25:35 am David Valeri wrote:
> It would appear that the STS client is not properly copying the
> sp:RequestSecurityTokenTemplate contents into the wst:RequestSecurityToken
> element.
>
> Per the WS-SP 1.2 spec, section 5.4.2, "This required element contains
> elements which MUST be copied into the wst:SecondaryParameters of the RST
> request sent to the specified issuer. Note: the initiator is not required
> to understand the contents of this element."
>
> The STS client copies these values directly into the body of the
> wst:RequestSecurityToken element in the request to the STS.
>
> So this policy:
> <sp:IssuedToken
> sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/
> I ncludeToken/Always">
> <sp:RequestSecurityTokenTemplate>
>
> <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-
> 1 .1#SAMLV1.1</wst:TokenType>
> <wst:AppliesTo>
> <wsp:URI>service-1</wsp:URI>
> </wst:AppliesTo>
> <wst:Participants>
> <wst:Participant>
> <wsp:URI>service-1</wsp:URI>
> </wst:Participant>
> </wst:Participants>
>
> <wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey</ws
> t
>
> :KeyType>
>
> </sp:RequestSecurityTokenTemplate>
> </sp:IssuedToken>
>
> Becomes this request:
>
> <wst:RequestSecurityToken>
> ...
>
> <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-
> 1 .1#SAMLV1.1</wst:TokenType>
> <wst:AppliesTo>
> <wsp:URI>service-1</wsp:URI>
> </wst:AppliesTo>
> <wst:Participants>
> <wst:Participant>
> <wsp:URI>service-1</wsp:URI>
> </wst:Participant>
> </wst:Participants>
>
> <wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey</ws
> t
>
> :KeyType>
>
> ...
> </wst:RequestSecurityToken>
>
> Instead of:
>
> <wst:RequestSecurityToken>
> ...
> <wst:SecondaryParameters>
>
> <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-
> 1 .1#SAMLV1.1</wst:TokenType>
> <wst:AppliesTo>
> <wsp:URI>service-1</wsp:URI>
> </wst:AppliesTo>
> <wst:Participants>
> <wst:Participant>
> <wsp:URI>service-1</wsp:URI>
> </wst:Participant>
> </wst:Participants>
>
> <wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey</ws
> t
>
> :KeyType>
>
> </wst:SecondaryParameters>
> ...
> </wst:RequestSecurityToken>
>
> Before I create an issue report and patch, I wanted to know if there is
> another usage of the code (Secure Conversation, specific STS
> implementation, Specific spec version, etc.) that would dictate that this
> copying occur as it does now. I don't see any unit or systests that cover
> this code.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog