Ýet another riveting title Dispensing with WS-Federation, we’ll move onto looking at SAML 2.0 integration with AD FS, in particular IdP-Initiated sign-on. In the last few posts we’ve looked at how AD FS 2.0 admins can manipulate the use of the whr function to assist in the realm discovery process as part of sign-in to AD FS using WS-Federation. With AD FS 2.0 and SAML 2.0, a long-awaited feature has been support for SAML 2.0 RelayState. With Rollup 2, the AD FS team have come up with the goods. Like whr on the WS-Federation side, the use of RelayState allows us to support IdP-Initiated login from a SAML 2.0 identity provider (IdP).

Before we look at some examples, here’s a few useful tools to aid building and debugging the use of RelayState.

1. The excellent SAML Tracer plugin for Firefox (https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/)

2. A relay state generator for AD FS 2.0 to aid us in building the necessary call-back to AD FS. (https://adfsrelaystate.codeplex.com/)

3. A URL Encoder/Decoder to validate the syntax used for constructing the Relaystate query string. I used this one.. http://meyerweb.com/eric/tools/dencoder/

To get started, there’s a nice article on the Directory Services blog at Microsoft, as a backgrounder to understanding what’s going on via Rollup 2 and RelayState. http://blogs.technet.com/b/askds/archive/2012/09/27/ad-fs-2-0-relaystate.aspx.

Let’s have a look at how these scenarios may pan out. Putting my rudimentary skills in Visio 2013 to the test, here are three examples:

EXAMPLE 1: Remote SAML 2.0 Identity Provider

In the above example, our user needs to connect, via the Internet, to a remote web application that is configured as a SAML 2.0 Service Provider. This service provider is engaged in a federation trust with AD FS. AD FS as a Relying Party Security Token Service (RP-STS) has the SAML 2.0 Identity Provider (IdP), in the home realm of the user, configured as a claims provider (CP).

EXAMPLE 2 : Remote SAML 2.0 Identity Provider and Service Provider

In the above scenario, both the service provider (SP) and the identity provider (IdP) are remote to the organization. This could be a cloud / SaaS application that the RP-STS organization provides access to to both its users and the remote identity provider organization.

EXAMPLE 3 : Remote SAML 2.0 Service Provider

In the above example, the Identity Provider (IdP) and AD FS are part of the same organization.  The IdP could be an Access Management platform such as OpenAM, a remote access gateway such as a Juniper SA, or an Extranet ADFS instance with the AD FS RP-STS acting as a broker.

Access Scenario

Let’s look at some of the pre-requisites on the AD FS side:

1. Install AD FS 2.0 Rollup 2 on all instances where AD FS is involved: proxies, farm members and also third-party organizations if AD FS is installed there.

2. Add the following change to <microsoft.identityServer.web> section of the IIS web.config of all participating AD FS instances, under the /adfs/ls path.

<microsoft.identityServer.web>
   <useRelayStateForIdpInitiatedSignOn enabled=”true” />
</microsoft.identityServer.web>

In this example we’ll evaluate ADFS in a SAML 2.0 Identity Provider (IdP) role within a third party Organization, called Fie, and also as a Relying Party Security Token Service (RP-STS) within the resource organization (Foo).  Fie Users may click on a hyperlink or a bookmark that kicks off the logon process with their IdP, and through the use of RelayState, via the parameterized Relying Party Identifiers provided to the IdP and RP-STS ADFS instances, the user is sent to the service provider application.

For our web application and SAML 2.0 SP, I’m going to use cloud provider OneLogin. This will act as an application portal. Once logged on via the IdP, the user is sent to the OneLogin portal thru the RP-STS of Foo. Referring to the diagrams above, this access scenario probably best fits Figure 2. Since the web application belongs to Foo, we’re using an indirect trust involving the Foo ADFS instance as an RP-STS. Fie is a claims provider (CP) to the Foo organization ADFS and the web application is a SAML 2.0 Service Provider (SP) that trusts the ADFS instance as an Identity Provider (IdP).

Here are the service endpoints and relying party identifiers that we need to use to build the appropriate link.

• IdP (ADFS) = sts.fie.com
• RP-STS (ADFS) = sts.foo.com
• SAML 2.0 SP = app.onelogin.com
• Foo STS Relying Party Identifer (RPID) = http://sts.foo.com/adfs/services/trust
• SAML 2.0 Relying Party Identifier (RPID) = https://app.onelogin.com/sessions/saml 

Using the new notation provided in Rollup 2, two relying party identifiers (RPID) are required in order for the relay to the web application to work correctly. The RPID in ADFS terms is the identifier. For a SAML 2.0 SP, this is the Entity ID of the web application. In some scenarios the entity ID may not be sufficient and additional parameters required. Refer to the Microsoft article mentioned earlier on how this may be further encapsulated into the RelayState. I’ve included the URL encoded and decoded syntax below to give you an idea the syntax we’re forming.

Here’s the URL Decoded link, broken into three parts:

1. https://sts.fie.com/adfs/ls/idpinitiatedsignon.aspx
2. &RelayState=RPID=http://sts.foo.com/adfs/services/trust
3. &RelayState=RPID=https://app.onelogin.com/sessions/saml

Part 1 is the URL of the Identity Provider, Part 2 the query string and RelayState for the RP-STS, and Part 3 state for the SAML 2.0 SP.

Users logon on at Fie IdP, either through the AD FS proxy using forms-logon, when connecting externally or with their Windows logon ID thru the ADFS farm.  Once we’ve encoded the link, it looks like this:

https://sts.fie.com/adfs/ls/idpinitiatedsignon.aspx?RelayState=RPID%3Dhttp%3A%2F%2Fsts.foo.com%2Fadfs%2Fservices%2Ftrust%26RelayState%3DRPID%3Dhttps%3A%2F%2Fapp.onelogin.com%2Fsessions%2Fsaml

And we hit the OneLogin portal:

I began the post with a smiley, so I’ll end with one.. nice feature ..