Share via

AD FS 2.0: How to Request a Specific Name ID Format from a Claims Provider (CP) During SAML 2.0 Single-Sign-On (SSO)

  • Article

When AD FS 2.0 is the Service Provider Security Token Service (STS) and is involved in SAML 2.0 passive web SSO, there may be a requirement from the CP (also known as Identity Provider or IDP) to have AD FS 2.0 instruct the CP as to which Name ID Format is required.

SAML 2.0 protocol specifies an optional way to request a specific Name ID Format in the authentication request (AuthnRequest) from the SP to the CP called NameIDPolicy.

From SAML 2.0 Core:
<NameIDPolicy> [Optional]
Specifies constraints on the name identifier to be used to represent the requested subject. If omitted, then any type of identifier supported by the identity provider for the requested subject can be used, constrained by any relevant deployment-specific policies, with respect to privacy, for example.

3.4.1.1 Element <NameIDPolicy>
The <NameIDPolicy> element tailors the name identifier in the subjects of assertions resulting from an <AuthnRequest>. Its NameIDPolicyType complex type defines the following attributes:

Format [Optional]
Specifies the URI reference corresponding to a name identifier format defined in this or another specification (see Section 8.3 for examples). The additional value of
urn:oasis:names:tc:SAML:2.0:nameid-format:encrypted is defined specifically for use within this attribute to indicate a request that the resulting identifier be encrypted.

By default, AD FS 2.0 will send an AuthnRequest to the CP with a NameIDPolicy containing the Format URI:
*urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

*

SAML 2.0 Core provides a list of common NameIDPolicy Format URIs to choose from

8.3.1 Unspecified
URI: *urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
*
8.3.2 Email Address
URI: *urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
*
8.3.3 X.509 Subject Name
URI: *urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
*
8.3.4 Windows Domain Qualified Name
URI: *urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName
*
8.3.5 Kerberos Principal Name
URI: *urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos
*
8.3.6 Entity Identifier
URI: *urn:oasis:names:tc:SAML:2.0:nameid-format:entity
*
8.3.7 Persistent Identifier
URI: *urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
*
8.3.8 Transient Identifier
URI: *urn:oasis:names:tc:SAML:2.0:nameid-format:transient
*

Steps to configure AD FS 2.0 to send a specific NameIDPolicy Format URI to a CP during SAML 2.0 passive sign-in

  1. Determine the NameIDPolicy Format URI required
  2. Launch an administrative Powershell window on the AD FS 2.0 server
  3. Execute the following Powershell commands:
         a. *Add-PsSnapin Microsoft.Adfs.Powershell
    *     b. *Set-AdfsClaimsProviderTrust -TargetName "insert-name-of-CP-Trust-here" -RequiredNameIDFormat "insert-NameIDPolicy-Format-URI-here"

Example

*Add-PsSnapin Microsoft.Adfs.Powershell
Set-AdfsClaimsProviderTrust -TargetName "Contoso CP Trust" -RequiredNameIDFormat "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
*
At the next sign-in attempt, AD FS 2.0 will build a SAMLRequest containing an AuthNRequest which resembles the following:

 

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="id-16f33a7e-4381-4d40-9fdd-1949dd679e86" Version="2.0" IssueInstant="2011-06-16T21:28:37.000Z" Destination="https://sso.contoso.com/adfs/ls/" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified">
  <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://sso.adatum.com/adfs/services/trust</Issuer>
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" AllowCreate="true" />
  <samlp:RequestedAuthnContext>
    <samlp:AuthnContextClassRef xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:Password</samlp:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>