Alik Levin's

Clarity, Technology, and Solving Problems | PracticeThis.com

Windows Identity Foundation (WIF) Configuration – Part V (<securityTokenHandlers>)

Windows Identity Foundation (WIF) Configuration – Part V (<securityTokenHandlers>)

  • Comments 0

he information in this post is based on Windows Identity Foundation Config.xml file that ships with WIF SDK.

<securityTokenHandlers> contains the set of SecurityTokenHandlers that are registered with the endpoint. The securityTokenHandlers collection by default is populated with the following:

  • Saml11SecurityTokenHandler
  • Saml2SecurityTokenHandler
  • KerberosSecurityTokenHandler
  • WindowsUserNameSecurityTokenHandler
  • RsaSecurityTokenHandler
  • X509SecurityTokenHandler
  • EncryptedSecurityTokenHandler

Each of the TokenHandler setting can have custom configuration as a child element to the TokenHandler element entry. Saml11SecurityTokenHandlerSaml2SecurityTokenHandler, X509SecurityTokenHandler and MembershipUserNameSecurityTokenHandler have a pre-defined custom configuration section. SecurityTokenHandler collections can also be named, to be used in certain circumstances. The only names that the framework handles are "ActAs" and "OnBehalfOf". If handlers exist in these collections, they will be used lieu of the default handlers for processing ActAs and OnBehalfOf tokens.

Example:

<securityTokenHandlers name="ActAs">
     <securityTokenHandlerConfiguration>

<audienceUris> specifies the set of URIs which are acceptable as identifying this relying party. Tokens will not be accepted unless they are scoped for one of the allowed audience URIs. By default, no URIs will be added to the collection. The SecurityTokenHandler for the SAML 1.1 and SAML 2.0 token types  use the values in this collection to configure any allowed audience uri restrictions in SamlSecurityTokenRequirement objects.

Example:

<audienceUris>
  <clear/>
  <add value="http://www.example.com/myapp/" />
  <remove value="http://www.example.com/myapp/" />
</audienceUris>

<issuerNameRegistry> - All issuer tokens are validated using the IssuerNameRegistry. The purpose of the IssuerNameRegistry is to map the issuer token to a string name.  Any custom type can be registered using the 'type' attribute of the <issuerNameRegistry> element. The <issuerNameRegistry> can have one child element that will serve as custom configuration to the IssuerNameRegistry.  One IssuerNameRegistry type is provided out of the box – ConfigurationBasedIssuerNameRegistry - that can be used to configure a set trusted issuer certificates in configuration. This type requires a child configuration element <trustedIssuers> where trusted issuer certificates configured.

<trustedIssuers> configuration adds trusted certs using the ASN.1 encoded form of the certificate thumbprint.

Example:

<issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, Microsoft.IdentityModel">
  <trustedIssuers>
    <add thumbprint="97249e1a5fa6bee5e515b82111ef524a4c9158de" name="contoso.com" />
    <remove thumbprint="97249e1a5fa6bee5e515b82111ef524a4c9158de" />
    <clear/>
  </trustedIssuers>
</issuerNameRegistry>


<issuerTokenResolver> registers an issuer token resolver. This can be used to resolve Issuer KeyIdentifierClauser while
deserializing a SAML token.

Example:

<issuerTokenResolver type="MyNamespace.CustomTokenResolver, MyAssembly" />


<serviceTokenResolver> registers a service token resolver. This can be used to resolve Issuer KeyIdentifierClauser while
deserializing a SAML token.

Example:

<serviceTokenResolver type="MyNamespace.CustomTokenResolver, MyAssembly" />

Related Books

Related Info