Identity Federation with ADFS - 31 Oct 2006

Your organization might be one of the many that would like to share data with authorized external users over the Web. You'd like to make it easy for these suppliers or customers to connect to your resources by using their existing user account and not requiring them to establish an account on your system, but you need to be sure that only authorized users get access. Several solutions exist that can help you meet at least some of these requirements—one of them is identity federation. Windows Server 2003 Release 2 (R2)—which Microsoft released late last year—includes an identity federation solution called Active Directory Federation Services (ADFS).

Identity federation is a complex technology with a set of components and terminology that might be unfamiliar to you. I'll provide a brief explanation of identity federation and how your organization might take advantage of it before introducing ADFS and describing a simple ADFS operation example. In a follow-up article, I'll provide more information about the ADFS components, how they operate, and how to set them up.

The Problem
The goal of identity federation is to make it easier for organizations to share data with authorized external users. These users might be in partner organizations, or they might be customers. For example, a manufacturing company might want to make its supply-tracking database accessible to supplier organizations or an industry analysis company might want to open its publication repository to customer organizations. The key requirement is that access to the data is secured and restricted to authorized users. Two commonly used solutions to provide these services are Web access management systems and identity brokers. Identity federation provides a third, and perhaps the best, alternative.

To build a Web access management system, organizations typically leverage commercial software packages. Popular examples are CA's eTrust SiteMinder and Oracle Access Manager. Classical Web access management systems control access to an organization's resources by defining individual accounts for external users. This approach doesn't scale very well, can become an administrative burden, and isn't easy for external users to use. This last point is certainly the case if users must deal with the Web access management systems of multiple organizations. Users are then forced to maintain a separate account and credentials for each organization and can quickly end up with a user account nightmare.

A better alternative is to give users a single-account they can use to access the resources in different organizations. This is the goal of another solution category for our problem: identity brokers. A famous Microsoft identity broker example is Windows Live ID (formerly known as Microsoft Passport). Identity brokers aren't a perfect solution either. A key problem with them is that few organizations trust the outsourcing of their account management to an external entity. The use of a central repository for storing accounts also makes that repository a central point of attack and single point of failure.

Identity federation is the third solution to our data access problem, and it doesn't have any of the problems of the previous solutions. Identity federation provides SSO for users and allows organizations to maintain control over their own accounts. Also, identity federation doesn't create central points of attack or single points of failure. On the other hand, current identity federation solutions lack some of the features that can be found in, for example, Web access management solutions, such as easy application integration and advanced auditing and reporting.

Making Sense of Identity Federation
Identity federation, aka federated identity management, is the linking of disparate identity and resource providers. In identity-federation-speak, an organization can be an identity provider, a resource provider, or both. An identity provider is an organization that issues and manages identities. A resource provider provides and controls access to resources such as databases or files. Most organizations are a combination of both: they provide resources to their partner organizations and issue and manage the accounts for their own employees.

In the context of identity federation, identity and resource providers are sometimes referred to as islands, a term which emphasizes their isolation from one another. These islands certainly exist between organizations but can also exist within an organization. A common misconception is that identity federation is about enabling and securing only interorganizational data exchanges. Organizations often e internal islands created for security or political reasons that can benefit from federation as well.

The linking of different organizational islands makes federation an interesting technological challenge. Organizational islands typically have their own habits and ways of doing things. They have their own account naming standards and their own mechanisms to verify identities (authentication) and control access to resources (authorization). Federation standards provide a lingua franca for expressing account, authentication, and authorization data in a format that can be understood by different identity and resource providers and for exchanging this information between federation partners.

Currently, there are three main sets of identity federation standards, called threads. Each thread has its champions; Microsoft, along with IBM and VeriSign, favors the set of specifications called the Web Services? Federation (WS-Federation) thread. The sidebar "Identity Federation Standards" briefly describes WS-Federation and its rival threads.

Organizations that want to set up a federation should preferably use the same federation standard. But this isn't a necessity: Some federation solutions (such as HP OpenView Select Access and IBM Tivoli Federated Identity Manager) can deal with different federation standards or translate one standard format to another.

The WS-Federation specification includes two federation support profiles: one to support federation for passive clients (aka the passive requestor profile) and one for active clients (aka the active requestor profile). Passive clients are browsers that simply support the HTTP protocol and Secure Sockets Layer (SSL) to secure the HTTP traffic. A passive client has no idea it's being used for federation.

An active client participates with knowledge of federation protocols and is more flexible, powerful, and secure than a passive client. Active clients natively support the Simple Object Access Protocol (SOAP).

At the time of writing, Microsoft ADFS builds Security Assertion Markup Language (SAML) 1.1?compliant tokens and supports WS-Federation passive clients but not active ones.

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.