Carrying on from where we left off in the last post, let’s look at some sample scenarios for implementing mixed authentication scenarios using a combination of AD FS and third-party identity providers. As usual, the assumption is that some sort of split-DNS in the federation service namespace is available.

In this example, AD FS will act as a hybrid Security Token Service (STS).  In addition to the out-of-the-box AD FS claims provider (IP-STS) role,  AD FS must act as a Relying Party Security Token Service (RP-STS) for two claims providers; the first where it trusts a SAML capable  two-factor authentication claims provider,  the second where it trusts a gateway portal that provides IdP-initiated sign-on.

In the above diagram, note the use of split DNS to differentiate between user experience inside and outside of the organization; namely, internal resolution of  the AD FS federation services endpoint points to the AD FS farm, whilst externally resolving to the AD FS Proxy(s).

Here are the sign-on use cases:

External SP-initiated Sign-On

• Authentication: Two-Factor Authentication (OTP)
• Customization: AD FS Proxy Configuration

A1  – Client accesses Web Application
A2  – Client is redirected to AD FS RP-STS for processing (A2-1)
A3  – Client is redirected to 2FA Provider for logon.
A4  – Following successful authentication at 2FA, client SAML assertion is passed to AD DS RP-STS for claims processing.
A5  – Client is redirected to Web Application (RP)

External IdP-initiated Sign-On

• Authentication: (a) X509 Certificate + Username/Password (b) Grid Authentication
• Customization: None (use of Smartlinks)

B1  – Client accesses IdP-capable Portal
B2  – From the portal,  client selects bookmarked Web Application (Smart Link)
B3  – Client is redirected to IdP to determine whether user has valid logon token for SSO
B4  – Client is redirected to AD FS RP-STS for claims processing
B5  – Client is redirected to web application (RP)

Internal RP/SP-initiated Sign-On

• Authentication : Integrated Windows Authentication (Kerberos/NTLM)
• Customization : AD FS Farm Configuration

C1  – Client accesses web application
C2  – Client is redirected to local AD FS IP-STS for processing. AD is set as default realm via customization (no realm selection allowed)
C3  – Integrated Windows Authentication (IWA) is performed at STS and claims are processed.
C4  – Client is redirected to web application (RP)

 

To make the above scenarios work, some minor customization is needed. The first barrier that we hit is home-realm discovery. If AD FS trusts two additional claims providers, besides Active Directory, how can authentication requests be routed correctly?

The answer rests partly with tweaking the AD FS proxy and farm configuration, the other in the way the Portal IdP calls AD FS. The customization on the AD FS side is relatively straightforward.

Let’s look  at each access scenario:

1. External SP-initated sign-on

In external scenarios that are initiated at the relying party or service provider, we want to use the strongest authentication possible, our 2FA provider. This is accomplished by editing the homerealmdiscovery.aspx.cs on farm members and inserting the following line on the Page_Init section.

SelectHomeRealm(https://idp.mydomain.com)

2. External IdP-initiated sign-on

IdP-initiated sign-on envisages the use of access gateway solutions such as Juniper SA / Citrix CloudGateway. In these scenarios the user authenticates  to the gateway using the authentication mechanism required by the organization. Access to back-end applications is then performed using service provider initiated sign-on. Having already authenticated at the gateway, with the gateway configured as a claims provider on the AD FS side, the user is not prompted for credentials again and SSO to the application is  provided.

This scenario has some  interesting use cases. It allows the organization to use a different authentication method for accessing the gateway IdP than via the service provider initiated sign-on route (2fa). If the gateway employs some form of endpoint component checking and machine validation, then the organization may wish to adopt a more lenient access and user friendly authentication mechanism for managed/trusted devices (e.g. username/password).

Integration with AD FS is accomplished through using smart-links and selecting both the claims provider, via the home realm parameter (whr), and the relying party (wtrealm), in the query string, e.g.

https://sts.mydomain.com/adfs/ls/?wa=wsignin1.0&wtrealm=https://contoso.mydomain.com/sts/&whr=https://gateway.mydomain.com/dana-na/auth/saml-endpoint.cgi

NB: I’ve omitted Forefront UAG in this list as its relationship with AD FS is that of a relying party rather than an identity provider. Redirects using the whr= parameter to a stronger authentication provider than AD FS are possible.

3. Internal SP-initated sign-on

In this scenario, we want the relying party of SAML 2.0 service provider  to select the Active Directory authentication provider, rather than the other two trusted claims providers. This is accomplished by editing the homerealmdiscovery.aspx.cs on farm members and inserting  the following line on the Page_Init section.

SelectHomeRealm( PassiveIdentityProvidersDropDownList.SelectedItem.Value );

This will automatically select the highlighted item, the native provider always the first chosen.

Summary

In this post we’ve looked at supporting multiple claims providers for AD FS with the minimum of customization.  Changing the homerealmdiscovery.aspx.cs file on the  AD  FS farm ensured all internal authentication requests are  passed to Active Directory.  Similarly, externally, we specified the realm the AD FS proxy should use to select the 2FA provider. With home realm discovery now set both front and back-end servers, additional claims providers that support IdP-initiated sign-on may be used and invoked through smart links.