Handling Mismatched Trust Versions on the Client

  • Article

Federation Clients might have scenarios where it is talking to a Service and STS that don't have the same trust version. The Service WSDL can contain a RequestSecurityTokenTemplate with Trust elements that are in different version than the STS. In these cases a WCF client will convert the Trust elements received from the Service's RequestSecurityTokenTemplate to match the STS Trust version. WCF will handle mismatched Trust version only for Standard Binding. All algorithm parameters that we recognize as standard are part of the Standard Binding. Below is our behavior under various Trust settings between the Service and the STS.

 

In the below description RP refers to "Relying Party" or the "Service" and STS refers to "Security Token Service".

RP Feb 2005 & STS Feb 2005

 

RP's WSDL contains the following elements in the RequestSecurityTokenTemplate.

  • 1. CanonicalizationAlgorithm
  • 2. EncryptionAlgorithm
  • 3. EncryptWith
  • 4. SignWith
  • 5. KeySize
  • 6. KeyType

Client Config contains a list of parameters.

 

WCF cannot differentiate between client and service parameters. We just add all the parameters and send them over the RST.

RP Trust 1.3 & STS Trust 1.3

 

RP's WSDL contains the following elements in the RequestSecurityTokenTemplate.

  • 1. CanonicalizationAlgorithm
  • 2. EncryptionAlgorithm
  • 3. EncryptWith
  • 4. SignWith
  • 5. KeySize
  • 6. KeyType
  • 7. KeyWrapAlgorithm

Client config contains a "secondaryParamters" element that wraps the RP specified parameters.

 

WCF removes the EncryptionAlgorithm, CanonicalizationAlgorithm and KeyWrapAlgorithm from the top-level element under the RST if these are present inside the SecondaryParameters. We append the SecondaryParamters element as is to the outgoing RST.

 

RP Trust Feb 2005 & STS Trust 1.3

 

RP's WSDL contains the following elements in the RequestSecurityTokenTemplate.

  • 1. CanonicalizationAlgorithm
  • 2. EncryptionAlgorithm
  • 3. EncryptWith
  • 4. SignWith
  • 5. KeySize
  • 6. KeyType

Client Config contains a list of parameters.

 

WCF cannot differentiate between the Service and Client parameters in this case from config on the client side. So we convert all the parameters to Trust 1.3 namespace.

 

Our handling of KeyType, KeySize and TokenType elements in this case is as follows,

 

  • We download WSDL and create the binding and assign KeyType, KeySize and TokenType from RP's parameters and the client config is generated.
  • Client can now change any parameter in the config.
  • During Runtime WCF will copy all parameters specified inside the AdditionalTokenParameters section of the client config except KeyType, KeySize and TokenType as they were accounted for during config generation.

RP Trust 1.3 & STS Trust Feb 2005

 

RP's WSDL contains the following elements in the RequestSecurityTokenTemplate.

  • 1. CanonicalizationAlgorithm
  • 2. EncryptionAlgorithm
  • 3. EncryptWith
  • 4. SignWith
  • 5. KeySize
  • 6. KeyType
  • 7. KeyWrapAlgorithm

Client config contains a "secondaryParamters" element that wraps the RP specified parameters.

 

WCF converts only EncryptionAlgorithm and CanonicalizationAlgorithm specified inside the "SecondaryParameters" and move them as top-level under the RST and replace the client specified values.  The "SecondaryParameters" element is dropped from the AdditionalRequestParameters.