Identity Federation with ADFS

ADFS Architecture
ADFS leverages other Microsoft identity management building blocks such as Active Directory (AD) and Active Directory Application Mode (ADAM) and integrates tightly with Microsoft IIS. Figure 1 shows the core components in a simple ADFS deployment: federation servers, which run the ADFS Federation Service component; an ADFS Web Agent; and an AD or ADAM repository. In Figure 1, the ADFS infrastructure enables browser users from the identity provider to access a Web application running on an IIS server located at the resource provider. The browser users leverage the AD account defined by their identity provider.

ADFS provides tools based on X.509 certificates to establish a trust relationship between the identity provider and resource provider and to securely exchange data between them. ADFS trust relationships are one-way. In Figure 1, the resource provider trusts the identity provider. The trust relationship is also nontransitive, meaning that just because A trusts B and B trusts C, A does not automatically trust C.

The most important components of an ADFS implementation are the federation servers on the identity provider and the resource provider:

• The federation server on the identity provider uses AD or ADAM to authenticate-users. When user authentication is successful, the identity provider federation server generates authentication cookies and security tokens. These security tokens contain claims about a user. Typical claim examples are a user's name, group memberships, and email address. The identity provider federation server signs the security tokens to protect them from tampering.
• The federation server on the resource provider verifies the authentication cookies and security tokens it receives from users that attempt to access its Web application. The federation server also translates the cookies and tokens into a format that the Web application can understand and forwards them to the Web application.

How authentication cookies and security tokens are exchanged between the identity and resource provider federation servers is explained in the next section.

ADFS Web Agents enable IIS-hosted Web applications to participate in an ADFS federation. ADFS Web Agents know how to interact with federation servers and how to deal with ADFS authentication cookies and security tokens.

An existing Web application might require code changes to become ADFSenabled, which basically means that the application can consume the claims in the ADFS security tokens (i.e., use them for user authorization decisions). To enable a Web application for ADFS, you can use the Authorization Manager engine (which you can configure from the Microsoft Management Console Authorization Manager snapin) or one of the ASP.NET APIs (IsInRole or raw claims). For an introduction to Authorization Manager, have a look at "Role-Based Access Control," June 2003, InstantDoc ID 38775. One application that works with ADFS without coding changes is Microsoft SharePoint Portal Server.

ADFS Operation
Figure 2 illustrates the ADFS messages exchanged between the key ADFS entities. Remember that in this example, ADFS enables a browser user defined at the identity provider to access a Web application on the resource provider. The following ADFS-related messages will be exchanged:

• Step 1: A browser user defined at the identity provider attempts to access a Web server application hosted at the resource provider.
• Step 2: The ADFS Web Agent detects that the user hasn't been authenticated by ADFS and refers him or her to the resource provider's federation server.
• Step 3: During this step, known as home realm discovery, the browser user provides his or her home domain information to the resource provider's federation server. The home domain is the place where the user's identity is defined and maintained—in other words, the user's identity provider. The first time the user connects to the Web application, the user provides information such as the name of his or her identity provider or email address. In subsequent requests, the resource provider's federation server finds this information in a cookie that's forwarded by the user.
• Step 4: Based on the information provided during home realm discovery, the resource provider federation server redirects the browser user to the user's identity provider federation server for authentication.
• Step 5: The browser user authenticates to his or her identity provider federation server by using his or her AD account and associated credentials.
• Step 6: The identity provider federation server validates the user credentials against AD. If authentication is successful, the identity provider federation server generates an authentication cookie and ADFS security token.
• Step 7: The identity provider federation server redirects the browser user together with the security token and authentication cookie to the resource provider federation server.
• Step 8: The resource provider federation server transforms the claims in the security token into a set of claims that can be understood by the Web application hosted at the resource provider and embeds them in a new security token. This process is known as claim transformation. The federation server also generates a new authentication cookie and then redirects the browser user (together with the new security token and authentication cookie) to the Web application's ADFS Web Agent. The ADFS Web Agent then validates the authentication cookie and extracts the claims from the security token and passes them to the Web application.
• Step 9: The Web application interprets the claims for authorization purposes and returns the appropriate Web content to the browser user.

ADFS for Web SSO
ADFS is a Web SSO solution that lets enterprises extend the reach of their AD and Web-based applications to other organizations. Windows 2003 users looking for a Web SSO solution should have a look at ADFS. Agreed, ADFS doesn't come with some of the advanced features of pure-play Web SSO solutions such as CA's eTrust SiteMinder or HP's OpenView Select Access, and it might require more development and integration time on the Web application side, but it comes for free with Windows 2003 R2 and integrates well with Microsoft's IIS Web server and SharePoint Portal Server.

To be successful, ADFS must enable AD and IIS Web applications to interoperate with non-Microsoft identity and resource providers. Several software vendors have already jumped on the ADFS bandwagon and brought out or promised to bring out ADFS-compliant solutions that extend the reach of ADFS to non-Microsoft-centric environments. Good examples are the solutions from Centrify and Quest Software that can be used to extend ADFS Web SSO to non-IIS-based Web servers such as Apache Tomcat and IBM WebSphere. Microsoft has also demonstrated ADFS interoperability with identity management products from IBM, CA, Oracle, BMC Software, Ping Identity, and RSA Security.

A good start for learning more about ADFS is Microsoft's ADFS overview white paper, which you can download at http://www.microsoft.com/windowsserver2003/r2/identity_management/adfswhitepaper.mspx.