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 [email protected] http://dankulp.com/blog
