WIF Custom STS problem with Java RequestSecurityToken's TokenType and KeyType inside SecondaryParameters element

Question

Hi,

I implemented a .Net 3.5/WIF custom STS and when a Java (Metro) client sends a RST message with the TokenType (SAML2) and KeyType (Bearer) inside the RST's SecondaryParameters element. When WIF processes the RST it does not look inside the SecondaryParameters for the TokenType and it will assume that TokenType was not set and then create a Saml11SecurityTokenHandler because it is the default security token handler instead of creating the expected Saml2SecurityTokenHandler.

This is the body of the RST coming from the Java  Metro client:

<S:Body>
<trust:RequestSecurityToken xmlns:ns10="http://www.w3.org/2000/09/xmldsig#" 
   xmlns:ns13="http://www.w3.org/2001/10/xml-exc-c14n#" 
   xmlns:ns4="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" 
   xmlns:ns5="http://docs.oasis-open.org/ws-sx/ws-trust/200512/" 
   xmlns:ns9="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity" 
   xmlns:sc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" 
   xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512" 
   xmlns:wsa="http://www.w3.org/2005/08/addressing" 
   xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" 
   xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" 
   xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" 
   xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<trust:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</trust:RequestType>
<wsp:AppliesTo>
<wsa:EndpointReference>
<wsa:Address> - REMOVED - </wsa:Address>
</wsa:EndpointReference>
</wsp:AppliesTo>
<trust:SecondaryParameters>
<trust:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</trust:TokenType>
<trust:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer</trust:KeyType>
</trust:SecondaryParameters>
<trust:EncryptionAlgorithm>http://www.w3.org/2001/04/xmlenc#aes256-cbc</trust:EncryptionAlgorithm>
<trust:CanonicalizationAlgorithm>http://www.w3.org/2001/10/xml-exc-c14n#</trust:CanonicalizationAlgorithm>
</trust:RequestSecurityToken>
</S:Body>

And this is the RST from a .Net (WCF) client (this one works):

<s:Body>
<trust:RequestSecurityToken xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
<trust:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</trust:RequestType>
<wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
<Address> - REMOVED - </Address>
<Identity xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate> - REMOVED - </X509Certificate>
</X509Data>
</KeyInfo>
</Identity>
</EndpointReference>
</wsp:AppliesTo>
<trust:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</trust:TokenType>
<trust:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer</trust:KeyType>
<trust:CanonicalizationAlgorithm>http://www.w3.org/2001/10/xml-exc-c14n#</trust:CanonicalizationAlgorithm>
<trust:EncryptionAlgorithm>http://www.w3.org/2001/04/xmlenc#aes256-cbc</trust:EncryptionAlgorithm>
<trust:SecondaryParameters>
<trust:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</trust:TokenType>
<trust:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer</trust:KeyType>
<trust:KeySize>0</trust:KeySize>
</trust:SecondaryParameters>
</trust:RequestSecurityToken>
</s:Body>

As you can see, in the .Net case, the TokenType and KeyType elements are child elements of both the RST element and the SecondaryParameters element. 

Has anyone seen this issue before and know where the problem might be?

Thanks,

Robert

Answer 1

You have to check the secondary parameters yourself and set the appropriate properties yourself - the GetScope method in your STS is the right place for that.

---

Dominick Baier | thinktecture | http://www.leastprivilege.com

Answer 2

Thanks Dominick, I'll try that. Any reason why not overriding Issue or ValidateRequest instead of Scope? Do you know if this issue is documented anywhere? Thanks again.

Robert

Answer 3

GetScope is the right place in the Pipeline to set such Details for the current token request.

This is not an "issue" - just the way WS-Trust works (or not ;)

---

Dominick Baier | thinktecture | http://www.leastprivilege.com