When requesting a SAML token from an STS you can also request a proof token, which you can use to proof your ownership (by signing the primary signature with the proof token) of the token to the relying party when sending a SOAP message to it. In Identity terms, this is known as Holder-Of-Key subject confirmation method.

When using Holder-Of-Key confirmation method, there are three options for proof token:

  1. Symmetric key (based proof tokens)
  2. Asymmetric key
  3. Bearer key

See this post from Vittorio on the details of proof token.

Asymmetric key based proof tokens can come in following two forms:

  1. Requestor can generate an ephemeral RSA key pair and submit the public key to the IP/STS as part of the RST request. Requestor then signs the RST request with its private key to demonstrate the knowledge of the private key.
  2. Requestor can use an existing X509 public key cert as the proof token and use the corresponding private key cert to create the supporting signature.

wsFederationHttpBinding out of box (as in .NET 4.0) only supports an ephemeral RSA key pair while certain interop scenarios require X509 based asymmetric proof keys. For example, Apache Rampart 1.4 doesn’t seem to like ephemeral RSA key pair and forces you to use X509 based asymmetric proof keys. Unfortunately today this scenario is not possible out of box with wsFederationHttBinding. WSTrustChannelFactory API in WIF however supports both RSA key pair & X509 certs and you can choose your desired key type when requesting a token but WIF is not supported on XP.

So If you are on Windows XP or can’t use WIF for some other reason, you would have to extend wsFederationHttpBinding to enable X509 based proof keys. Probably a custom endpoint behaviour and inside it you would have to tweak IssuedSecurityTokenProvider to force it to use X509 key. See this post on how to work with IssuedSecurityTokenProvider directly. In the next post, I will talk more about extending wsFederationHttpBinding to support X509 based proof keys.