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:[email protected]] Sent: Friday, July 23, 2010 3:57 PM To: [email protected] 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 [email protected] http://dankulp.com/blog
