In the previous post we covered WS-Federation whr changes in AD FS 2.0 Rollup 2.  With this fix in place and enablewhrpersistence set in our web.config,  let’s look at scenarios on how the configuration can be used to manipulate home realm discovery in greater detail. 

Our mythical ‘Foo’ organization consists of an existing AD FS 2.0 proxy/farm setup and two claims providers configured:

1. default AD provider
2. third-party claims provider providing strong/two-factor authentication (2FA) to Foo users

Foo has recently engaged in a number of collaboration projects with three other companies: Fee, Fie and Foe. Wishing to further cement these relationships, Foo has elected to setup federation trusts with each of them, and provide access to their local WS-Federation web applications.  The Foo Security Officer, however, has decided that other home realms should not be visible within AD FS in the drop-down box of the home realm discovery page.  All RP-initiated requests via the AD FS proxy must go to their third-party two-factor authentication (2FA) claims provider.  This requirement, however, conflicts with the need to service federated logon for other organizations.

Given the above constraint, we have a number of options:

• Use an additional farm;
• Customize the home-realm discovery pages and logon experience on the existing farm to support the desired user experience for third-parties;
• Customize the relying party(s) to route the whr request;
• Use out-of-the-box features.

Not being much of a code monkey, let’s look at options out-of-the-box. With the new configuration, there are now five claims providers Foo has to deal with.

1. Active Directory Claims Provider (0)
2. 2FA Claims Provider (1)
3. The Fee Organization Claims Provider (2)
4. The Fie Organization Claims Provider (3)
5. The Foe Organization Claims Provider (4)

Foo AD FS Proxy Customization

For external access, as per security requirements, only the 2FA claims provider should be visible directly from the proxy, making it the default selection for external access. This is arranged  on the AD FS Proxy side by modifying the homerealmdiscovery.aspx.cs file and then removing the claims providers, as eligible entries, from the Page_Init section of the file. We need to process their removal in reverse order, starting with the last claims provider in the list, then the next to last etc., until we have the desired CP . For example, with five claims providers, the following changes are made:

PassiveIdentityProvidersDropDownList.Items.RemoveAt(4);
PassiveIdentityProvidersDropDownList.Items.RemoveAt(3);
PassiveIdentityProvidersDropDownList.Items.RemoveAt(2);
PassiveIdentityProvidersDropDownList.Items.RemoveAt(0);

We’re left with claims provider (1) in this example, the 2FA provider. Note the order may vary according to order created.

Once this has been done, the following line also needs to be added :

SelectHomeRealm( PassiveIdentityProvidersDropDownList.SelectedItem.Value );

This will default logon to the 2FA provider claims provider at the AD FS proxy. 

Foo AD FS Farm Customization

For users with managed clients/corporate PCs in the Foo organization, we need to ensure that realm discovery is also handled in the right manner. 2FA is not a requirement internally, but SSO via the Windows logon token is desirable. While we covered this in a previous post, it’s worth repeating here. On the AD FS Farm, the Page_Init section of the homerealmdiscovery.aspx.cs file needs to be set so that it defaults realm selection to the Active Directory claims provider.

SelectHomeRealm ( PassiveIdentityProvidersDropDownList.SelectedItem.Value );

If this is not set, then all claims providers are visible on the home realm discovery page, something which we don’t want to trouble internal users with on the corporate network. 

With persistence enabled on the home realm discovery page (of the Proxy), a user may fall foul of cookie handling if he/she works from home, logs on and then returns to work, only to discover that the cookie has persisted and the browser points them to the 2FA provider.  We can temper the cookie behaviour of the AD FS proxy by disabling persistence within the web.config on the AD FS farm.

<persistIdentityProviderInformation enabled=”false”/>

Connecting Organizations

For users from other organizations connecting to Foo; e.g. Fee, Fie and Foe, we rely on smart links from AD FS instances in these organizations to route the request and for the home realm cookie to be written correctly via the whr parameter. Note that these claims providers could also use non-Microsoft identity providers/issuers, such as a Juniper SA (SAML) or a PointSharp WS-Federation Identity Provider, such as . 

While useful, smartlinks are not without limitations.  Firstly, we’re assuming the relying party is a WS-Federation based web application.  If the relying party is a SAML 2.0 web application then the WS-this approach is not applicable. The solution described here does not work and a different type of customization is required. More on this in a future post. The second limitation concerns users from claims provider realms bookmarking Foo (federated) web applications. Should the home realm cookie expire, accessing a bookmarked RP web application will fail as it routes them to the 2FA provider. While Rollup 2 made persistence via whr possible, we need to workaround this shortcoming. We could set the lifetimeInDays value of the cookie in the homerealmdiscovery.aspx.cs of the Foo Proxy to such a high value that this would not be an issue.  Sadly, this is not entirely foolproof either. Browser configuration for users in partner organizations, e.g. Delete browsing history on exit,  may influence whether the realm cookies are retained or not.  Whatever setting is opted for by the resource organization (Foo) is something that will need to be communicated with partner organizations.