ADFS Implementation

From GFIPM Implementation Wiki
Revision as of 18:01, 9 December 2014 by Jeff.Krug (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Main Page

ADFS 2.0 is Microsoft's Windows Server component that enables Single Sign On. It includes sufficient support for the SAML standards so as to be compatible with GFIPM. The contents of this article are not comprehensive for deploying ADFS 2.0 as a GFIPM Identity Provider, but it does cover a few of the areas where conforming to the GFIPM Web Browser User-to-System Profile varies from ADFS 2.0's defaults.

Federation Terminology

The terminology used by Microsoft varies from the terminology used within GFIPM standards. You should become familiar with ADFS Terminology and GFIPM Terminology before you proceed. The two most important terminology conflicts are the following:

claims attributes
Relying Parties Service Providers

Attribute Names

One of the core things required to implement the GFIPM Web Browser User-to-System Profile is the proper usage of the GFIPM 2.0 Metadata Standard. This attribute set requires special ADFS configuration as the default attributes/claims that ADFS uses are all Microsoft specific. This ADFS Blog Article discusses how to configure ADFS to operate with Shibboleth, and the Common Issues noted at the bottom detail how to configure ADFS to use different Attribute Names and NameFormats (both must be correct to be GFIPM Compliant).

Assertion and Response Signing

By default ADFS 2.0 does not sign both the SAML Response and SAML Assertion as part of the SSO profile. This is required by the GFIPM Web Browser User-to-System Profile. To configure ADFS to sign both you will need to use a Powershell command:

 Set-ADFSRelyingPartyTrust -TargetIdentifier <url> -Identifier <url> -SamlResponseSignature 'MessageAndAssertion'

For more details on the full capabilities of configuring ADFS via Powershell you can review the Microsoft Article AD FS 2.0 Cmdlets in Windows PowerShell.

Trust Management

By default ADFS requires certificates that it trusts to have valid CRL (Certificate Revocation List) publication URLs. This is not a GFIPM requirement and in fact is counter-intuitive to the GFIPM Cryptographic Trust Model. GFIPM anchors trust on being within the trust fabric or not, and the equivalent of a certificate revocation is handled by removal from the trust fabric. In most cases it is not practical for certificates to include CRLs since the certificates are self-signed. There is another Powershell command available to change this ADFS requirement (first is when you are configuring it to trust an SP, the second when you are configuring it to trust an IDP):

 Set-ADFSRelyingPartyTrust -TargetIdentifier <url> -Identifier <url> -EncryptionCertificateRevocationCheck 'None'
 Set-ADFSClaimsProviderTrust -TargetIdentifier <url> -Identifier <url> -EncryptionCertificateRevocationCheck 'None'

To review the full details of this command review the Microsoft Documentation. If the ADFS IDP requires signed Authentication Requests (or ADFS is functioning as the SP), then you will need to execute the above command for the signing certificate as well:

 Set-ADFSRelyingPartyTrust -TargetIdentifier <url> -Identifier <url> -SigningCertificateRevocationCheck 'None'
 Set-ADFSClaimsProviderTrust -TargetIdentifier <url> -Identifier <url> -SigningCertificateRevocationCheck 'None'

If ADFS is returning a SAML status error like the following that may indicate that ADFS is still configured to require a certificate revocation verification:

   <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder" />

Name IDs

Requesting Name IDs

When initiating federated SSO, it is frequently necessary to request a specific Name ID type. GFIPM supports two Name ID types (case sensitive) within GFIPM Web Browser User-to-System Profile:

To specify a specific NameID type within ADFS you can use a PowerShell command:

 set-adfsClaimsProviderTrust –targetName “Claim Provider’s Name” –RequiredNameIdFormat “urn:oasis:names:tc:SAML:2.0:nameid-format:transient”

Honoring Name ID Requests

Within GFIPM it is appropriate for IDPs to honor the Name ID requests of SPs. This article provides details on configuring ADFS to support persistent and transient name identifiers:

While this allows ADFS 2.0 to be configured to support either transient or persistent for SPs on a relying-party basis, it does not afford a method for dynamically using transient or persistent based on the AuthnRequest. Given that most SPs will use either/or and not switch between them, this is likely sufficient as it simply makes this a configuration/trust time decision as opposed to a runtime decision.

Requested Protocol Binding

By default ADFS does not populate the protocol binding in SAML AuthnRequests. There is a pair of PowerShell commands to specify the Protocol Binding:

 set-adfsClaimsProviderTrust –targetName “providers-name” -SamlAuthenticationRequestProtocolBinding "POST"
 set-adfsClaimsProviderTrust –targetName “providers-name” –SamlAuthenticationRequestParameters “ProtocolBinding”

The first specifies what the protocol binding should be and the second specifies that the protocol binding should be sent.

Debugging Issues

ADFS will return a SAML Status error code to the Service Provider of urn:oasis:names:tc:SAML:2.0:status:Responder when it encounters some sort of internal error. If this error is arriving at a service provider, the detailed logfiles on ADFS IDP will need to be inspected to identify the detailed error as it could be a large variety of errors that occurred.

FIPS Compliance

ADFS itself has never undergone NIST FIPS validation, but this validation process is oriented towards cryptographic modules as opposed to enterprise products. ADFS should be configured to use Microsoft's cryptographically validated modules. Details on how to configure ADFS can be found in this technet article from Microsoft: FIPS 140 Evaluation

More Information

For high-level, broadly detailed information about configuring an IDP or an SP software instance, see the following articles:

Other Issues

This article provides some guidance on an error situation that may occur when ADFS is unable to properly authenticate the user (after a correct username/password were entered) do to a miscommunication between ADFS and AD. The specific behavior seen is Receiving 400 Error Message After Authentication.

Main Page