CardSpace support for Oasis WS-SX standards
The OASIS Web Services Secure Exchange (WS-SX) technical committee has published specifications for WS-Security extensions and policies to enable the trusted exchange of SOAP messages. Their effort resulted in the WS-SX specifications that include WS-Trust, WS-Security policy and WS-Secure conversation. This standardization of WS-Trust is good news. Gartner says that:
OASIS's ratification of two key standards means that Web services security has finally reached a level of maturity acceptable to many enterprises. This is a positive development for vendors and customers alike.
The ratification happened in March 2007 and support for these standards was one of the main changes included in the .NET Framework 3.5 release of CardSpace.
Overview of new WS-Trust specification
The OASIS WS-Trust is very similar to the one people have been using. The main differences are:
1. Returning the security token: a RequestSecurityTokenCollection element is used to return a security token in the final response.
2. SecondaryParameters: When a requestor inserts parameters into an RST request that come from a third party, for example a relying party policy, there is a potential for an attack. In the contributed request, both requestor RST parameters and third party RST parameters are mixed together as direct children of the wst:RequestSecurityToken element. This prevents an STS from differentiating between the RST parameters based on their source. Therefore, the STS trusts both kinds of RST parameters in the same way. This can open a potential attack vector because the third party is given control over the content of the RST message that the requestor sends to the STS. For this purpose, a new element wst:RequestSecurityToken/wst:SecondaryParameters was introduced, that acts as a bag for RST parameters introduced by a third party. This allows an STS to mitigate the attack by differentiating parameters originated by the requestor and parameters not originated by the requestor. Note that same element can occur as direct child of <RequestSecurityToken> as well as child of SecondaryParameters.
3. Bearer tokens: This trust version supports bearer tokens.
4. Namespace changes: A new namespace https://docs.oasis-open.org/ws-sx/ws-trust/200512 was introduced. This affects the URI for KeyType, RequestType and SOAP Action on the STS endpoint. For e.g., the symmetric key type is https://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey in place of https://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey.
5. Batch requests possible: In scenarios where multiple RSTs need to be sent, it is now possible to send them all at once using a RequestSecurityTokenCollection. This helps avoid multiple network round-trips. (Not a CardSpace scenario)
How does this all affect CardSpace?
First I would like to clarify that the CardSpace changes for the new WS-Trust version implement an additional feature. CardSpace will continue to support the previous WS-Trust specification (https://specs.xmlsoap.org/ws/2005/02/trust/ws-trust.pdf) having the namespace https://schemas.xmlsoap.org/ws/2005/02/trust.
If you have developed an STS or rich applications using the previous trust version, those will continue to work.
Which scenarios can leverage the new trust specification?
1. Managed card scenarios: An Identity Provider can choose to use the new trust version
2. A web service: Rich web services based on WS-* protocols can choose to use the new trust version. E.g., a Calculator web service built using WCF that uses CardSpace to secure its service endpoint.
3. Resource-STS: A resource STS can choose to use the new trust version. The Resource STS can serve either a website or a web service (as in previous point).
Note that the scenario involving a website asking for a self-issued card cannot leverage the new trust version.
CardSpace behavior when the new trust version is involved
1. Identity Provider: The Identity provider issues managed cards and generates token on demand. The card issuance is not affected at all. For token generation, following is the new behavior:
a. Policy retrieval: CardSpace determines the trust version used by the IP STS based on the policy. The policy needs to be expressed using the WS-SX version of security policy and use the Trust13 assertion to specify its WS-Trust capabilities. When using WCF for building the STS, use bindings such as WS2007FederationHttpBinding or CustomBinding with a security version like WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12 for the appropriate policy to be generated. Sample policy snippet looks like:
<wsp:Policy wsu:Id="policy">
<wsp:ExactlyOne>
<wsp:All>
<ic:RequireFederatedIdentityProvisioning xmlns:ic="https://schemas.xmlsoap.org/ws/2005/05/identity"></ic:RequireFederatedIdentityProvisioning>
<sp:SymmetricBinding xmlns:sp="https://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
...
</sp:SymmetricBinding>
<sp:SignedEncryptedSupportingTokens xmlns:sp="https://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
...
</sp:SignedEncryptedSupportingTokens>
<sp:Wss11 xmlns:sp="https://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
...
</sp:Wss11>
<sp:Trust13 xmlns:sp="https://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:Policy>
<sp:MustSupportIssuedTokens></sp:MustSupportIssuedTokens>
<sp:RequireServerEntropy></sp:RequireServerEntropy>
</wsp:Policy>
</sp:Trust13>
<wsaw:UsingAddressing></wsaw:UsingAddressing>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
b. STS Contract: Due to the change in namespace, the contract will have to be modified accordingly. For e.g., when using WCF, the operation will be as below:
[OperationContract(
Name = "Issue",
Action = "https://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue",
ReplyAction = "https://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal" )]
Message Issue(Message request);
c. RST parsing:
i. KeyType: Due to the change in namespace, the parsing of the KeyType will have to be modified to support the new URIs for symmetric, public, and bearer (no-proof) keys
ii. RequestType: Due to the change in namespace, the parsing of the RequestType in RST will have to be modified.
iii. Claims: The claims are always sent in the top-level RST body.
iv. SecondaryParameters: CardSpace will send the parameters it receives from resource (or Relying Party) as an xml blob within the SecondaryParameters. The secondary parameters are skipped in the following cases:
· The user chooses not to send optional claims. In this scenario, secondary parameters are omitted to hide this user decision
· The situation is such that no wsp:AppliesTo is being sent in the RST. In this scenario, secondary parameters are omitted so that IP does not get any identifying information about resource/RP.
Sample RST looks like:
<wst:RequestSecurityToken Context="ProcessRequestSecurityToken" xmlns:wst="https://docs.oasis-open.org/ws-sx/ws-trust/200512">
<wst:RequestType>https://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>
<wsid:InformationCardReference xmlns:wsid="https://schemas.xmlsoap.org/ws/2005/05/identity">
</wsid:InformationCardReference>
<wst:Claims Dialect="https://schemas.xmlsoap.org/ws/2005/05/identity">
...
</wst:Claims>
<wst:KeyType>https://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</wst:KeyType>
<wst:SecondaryParameters>
<wst:RequestType>https://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>
<wst:TokenType>urn:oasis:names:tc:SAML:1.0:assertion</wst:TokenType>
<wst:KeyType>https://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</wst:KeyType>
<wst:KeyWrapAlgorithm>https://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p</wst:KeyWrapAlgorithm>
...
</wst:SecondaryParameters>
</wst:RequestSecurityToken>
d. RSTR construction: The issue response has to be wst:RequestSecurityTokenResponseCollection (RSTRC). Within this RSTRC, a single RSTR is expected. In case the STS emits a RequestType in the RSTR, the URI to be sent needs to be changed as per the new namespace. A sample RSTR snippet looks like:
<wst:RequestSecurityTokenResponseCollection xmlns:wst="https://docs.oasis-open.org/ws-sx/ws-trust/200512">
<wst:RequestSecurityTokenResponse>
<wst:TokenType>urn:oasis:names:tc:SAML:1.0:assertion</wst:TokenType>
<wst:RequestedSecurityToken> ... </wst:RequestedSecurityToken>
...
</wst:RequestSecurityTokenResponse>
</wst:RequestSecurityTokenResponseCollection>
2. Resource STS: A web service resource or a website can delegate the task of authentication/authorization to a resource STS. In such a scenario, the Resource STS will have to set up an endpoint to process the RST/RSTR similar to an IP STS. All the points mentioned for Identity providers are applicable in this case. The changes are in the RST parsing.
It is no longer assured that the typical properties like claims and keytype will always be a direct child of the top level wst:RequestSecurityToken element. The RST parsing code will have to look into wst:RequestSecurityToken/wst:SecondaryParameters in case it finds information missing from the top-level elements.
3. Web service: A web service can act as a resource in rich client scenarios. When such a web service uses CardSpace for authentication, it can potentially use the WS-SX trust version. The resource will have to express its policy using WS-SX version of security policy and use the Trust13 assertion to specify its WS-Trust capabilities. In case of WCF resource, you can use Ws2007HttpBinding, Ws2007FederationBinding or a CustomBinding with an appropriate security version like WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12 to accomplish this.
4. Token generated by self issued card: CardSpace in .NET Framework 3.5 understands the WS-SX standards. So when a self issued card is requested using a WS-SX based policy, the token generated will process and comply with the parameters like KeyType, KeySize, etc. expressed in the policy. A sample scenario where this is possible is a Web service or a Resource STS asking for a self-issued card.
5. Bearer tokens: Consider scenario of website asking for a managed card. Since browser is a passive client, it cannot do proof of possession. Hence, CardSpace v3.0 used the concept of KeyType=NoProofKey in scenarios like this. The WS-SX version of WS-Trust introduced concept of requesting bearer tokens to address such scenarios. A new KeyType value https://docs.oasis-open.org/ws-sx/wstrust/200512/Bearer is added. CardSpace in .NET Framework 3.5 will use this new URI value for the KeyType element in the RST when the IP STS is using the new trust version. Note that rich client support for bearer tokens is not implemented in CardSpace.
Mixed trust versions
Things can get confusing when different legs of the scenario use different trust versions. For example, consider the following scenario:
A web service or a website is requesting a token from Resource STS. This Resource STS is asking for a managed card. The IP STS uses WS-SX version of WS-Trust (Trust13). And the Resource STS uses older WS-Trust (Trust10). The RST that is received by the IP STS will have the policy of the Resource STS in its SecondaryParameters. But since these parameters will be in Trust10, the contents of the SecondaryParameters element will also be in Trust10.
<wst13:RequestSecurityToken Context="ProcessRequestSecurityToken" xmlns:wst13="https://docs.oasis-open.org/ws-sx/ws-trust/200512">
...
<wst13:KeyType>https://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</wst13:KeyType>
<wst13:SecondaryParameters>
<wst10:KeyType xmlns:wst10="https://schemas.xmlsoap.org/ws/2005/02/trust">https://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey</wst10:KeyType>
...
</wst13:SecondaryParameters>
</wst13:RequestSecurityToken>
This can complicate the parsing of RST. The Identity Provider will have to decide on an approach for such scenarios like not supporting it, or ignoring SecondaryParameters or parsing of parameters in Trust10 namespace.
Thanks!
Rakesh Bilaney
SDET, Windows CardSpace