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:[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
