How ADFS "Does" Identity Federation

Maybe your organization, like many, is looking at how to easily and securely share data and access to its network with designated external users. An identity federation solution in Windows Server 2003 Release 2 (R2), called Active Directory Federation Services (ADFS) can help. In "Identity Federation with ADFS," November 2006, InstantDoc ID 93453, I introduced ADFS and defined identity federation, which links disparate identity and resource providers to make it easier for organizations to share data. I also discussed how an organization can take advantage of ADFS and showed a simple ADFS operation example. Now let's dig deeper into the ADFS components to examine how they work together and look at what's involved in planning for and setting up ADFS in your environment.

Federation Service
Before we get into the Federation Service, which is the most important component of ADFS, let's review some identity federation terminology. An organization can be an identity provider, a resource provider, or a combination of both. An identity provider is an organization that issues and manages accounts. A resource provider provides and controls access to resources. Identity and resource providers are sometimes referred to as islands, a term which emphasizes their isolation from one another. Islands can be in separate organizations or they can exist within the same organization. It's the job of identity federation solutions such as ADFS to link these islands.

The Federation Service is an ASP.NET Web service that must be installed on a Windows 2003 R2 Enterprise Edition or Datacenter Edition platform. ADFS requires a Federation Service installation for each identity or resource provider that's participating in the federation. Windows 2003 R2 Federation Service servers also must have the following software installed: Microsoft IIS 6.0, Microsoft .NET Framework 2.0, and ASP.NET. On a Windows 2003 R2 system, you can install Federation Service and all other ADFS components explained in this article from the Add or Remove Programs Control Panel applet's Windows Components wizard. R2 systems include a new Windows Components option called Active Directory Services that includes ADFS, Active Directory Application Mode (ADAM), and Identity Management for UNIX, or Services for UNIX (SFU).

Within ADFS, the Federation Service component hosts the service that generates ADFS authentication cookies and security tokens. This host role makes Federation Service a security authority that must be secured accordingly. Federation Service has the following roles and tasks:

The Federation Service validates user credentials and generates ADFS authentication cookies. The Federation Service can validate user credentials against either Active Directory (AD) or ADAM. Authentication cookies are used for Web single sign-on (SSO). An authentication cookie proves that users have been authenticated by the Federation Service and ensures that they don't have to re-enter credentials each time they access a resource hosted by a federation partner. The AD or ADAM directory used in an ADFS setup must be running on either a Windows 2003 Service Pack 1 (SP1) or SP2, Windows 2003 R2, or Windows 2000 SP4 system.

The Federation Service generates and transforms ADFS security tokens. An ADFS security token contains a user's attributes. In ADFS, these properties are also referred to as claims. As I explain later in this article, security tokens and their claims are primarily used for authorization purposes. The Federation Service can generate brand new security tokens or transform them from one format to another. To generate and populate security tokens, the Federation Service retrieves user claims from AD or ADAM.

During token transformation, the Federation Service translates the claims in a security token to a new set of claims that are then stored in a new token. Claim transformation ensures that a claim defined in one organization is transformed to an equivalent claim as defined in another organization. For example, "gold membership" in the frequent flyer application of one organization might translate to "privileged customer" in a similar application of another organization. I'll go into more detail about the Federation Service token transformation function later in this article.

The Federation Service manages the federation trust policy that's established between the Federation Service and other federation partners. The federation trust policy defines which user claims are exchanged between federation partners. Claims can include user identifiers such as an email address or User Principal Name (UPN); user authorization data such as group memberships; and other user identity attributes (e.g., phone number, mailing address). The Federation Service federation trust policy is managed from the ADFS Microsoft Management Console (MMC) snap-in, which Figure 1 shows. This snap-in is installed automatically when you install the Federation Service.

Federation Service Proxy
The Federation Service Proxy (FSP) component in ADFS acts as a user front end for the Federation Service. The FSP can be installed separately by using the Add or Remove Programs Control Panel applet's Windows Components wizard but is also automatically installed when you install the Federation Service. The FSP acts as a proxy between browsers and the Federation Service, giving the dumb browser clients something to talk to. The FSP has the same software installation requirements as the Federation Service.

The Federation Service is a security authority that shouldn't be directly exposed to your extranet or the Internet. If your federated users or partners connect to your resources from your extranet or the Internet, you should install an additional FSP in your organization's demilitarized zone (DMZ).

The FSP performs the following tasks:

• It provides the interface for user home domain discovery. In ADFS, a user's home domain is the account provider in which the user's account is defined. An ADFS resource provider must know a user's home domain to be able to redirect the user to the correct account provider for authentication. The FSP includes a special Web page that lets a user manually select the user's home domain. You can also automate the process of home domain discovery, which the ADFS documentation explains.
• It collects credential information from browser clients and forwards it to Federation Service for validation.
• It forwards security tokens and authentication cookies generated by an identity provider Federation Service to a resource provider Federation Service.
• It returns security tokens and authentication cookies generated by Federation Service to browser clients.

ADFS Web Agent
The ADFS Web agent is an ADFS user's first point of contact with ADFS. The Web agent provides the interface logic between the ADFS infrastructure and a Web-based application. The agent leverages the information in the security tokens and authentication cookies and forwards ADFS claims to Web-based applications. The applications can then use the claims to make authorization decisions or provide user personalization services. The agent includes an Internet Server API (ISAPI) filter that redirects unauthenticated users to the FSP and Federation Service for authentication.

The ADFS Web agent must be installed on each IIS system that hosts ADFS-enabled applications. Unlike the Federation Service and FSP, the agent can also be installed on a Windows 2003 R2 Standard Edition server. During ADFS Web agent installation, you have the option to install support for claims-aware applications, Windows NT token-based applications, or both. Let's look at how these applications differ.

ADFS Application Integration
ADFS Windows NT token-based applications support the traditional Windows authorization model, which is based on security identifiers, access tokens, ACLs, and the process of impersonation. A good example of an application that can be integrated with ADFS as a Windows NT token-based application is Microsoft SharePoint Portal Server. NT token-based applications require only minimal configuration changes to enable them for ADFS. However, ADFS claims-aware applications require custom coding.

For NT token-based applications, the ADFS Web Agent extracts the identity and/or group claim information from the ADFS security token, maps the extracted information to a local AD account, and requests a Windows access token. The Web application then uses the access token for authorization. The impersonation process used by the ADFS Web agent and the associated creation of an access token do require a special local AD account on the Web server side (which is the resource provider).

ADFS claims-aware applications are applications that directly leverage the claims in ADFS security tokens. As opposed to NTtoken based applications, claims-aware applications don't require a local AD account on the resource provider side. To build claims-aware applications, you can use the Windows 2003 SP1 or SP2 Authorization Manager, the ASP. NET 2.0 IsInRole class, or the ASP.NET 2.0 raw claims API. Microsoft introduced Authorization Manager in Windows 2003 and included changes that let applications that use Authorization Manager leverage the claims contained in ADFS security tokens. Thanks to these changes, ADFS claims can be directly mapped to Authorization Manager roles.

Claims-Based Security
The mechanism ADFS uses to securely transfer information between identity and resource providers and to make authorization decisions on the resource provider side is referred to as the claims-based security model.

As I mentioned earlier, claims are security principal attributes, such as a principal's name, group memberships, privileges, or capabilities. The security tokens that the Federation Service Security Token Service (STS) generates contain claims. To protect the integrity of the claims in a security token, the STS signs the security tokens. ADFS supports the following claim types:

• Identity claims: An ADFS security token must always contain an identity claim. An identity claim can contain a UPN, a Request for Comments (RFC) 822–formatted email address, or a common name (CN).
• Group claims: These indicate user membership in a group or role.
• Custom claims: These can contain any other type of user authorization or profile information that's not identity- or group-claim information. Some examples of custom claims are employee ID number, Social Security number, and employee age.

Claim Transformation
In "Identity Federation with ADFS," I showed the importance of providing a common language for different identity and resource providers. ADFS provides this common language by using a process known as claim transformation, which Figure 2 shows.

During claim transformation, ADFS identity providers transform their internal organizational claims to outgoing claims in a format that's available and visible to resource providers. Resource providers in turn transform the incoming claims they get from identity providers into a format that can be consumed by their proper applications.

An organization's internal claims, that is, the claims that are populated from an identity repository (AD or ADAM) on the identity provider side and the claims that are consumed by applications on the resource provider side, are referred to as organization claims. The claims resulting from the claim transformation process on the identity provider side are called outgoing claims. The claims that the resource providers receive are called incoming claims.

The following steps detail the process of how ADFS creates, exchanges, and uses claims when a user requests access to a resource such as a Web application:

1. The Federation Service of the user's ADFS identity provider generates organization claims by populating the claims with the user's AD object attributes.
2. The identity provider's Federation Service transforms the organization claims to a set of outgoing claims.
3. The outgoing claims are sent to the Federation Service of the resource provider.
4. The resource provider's Federation Service transforms the incoming claims to a set of organization claims.
5. The ADFS-enabled Web application consumes the organization claims and uses them to authorize the user or to personalize the application for the user.

Claim transformation gives organizations complete control over what user data they make available to external federation partners. Claim transformation also allows organizations to use different naming conventions between organizational and outgoing or incoming claims. More importantly, claim transformation lets organizations change their internal naming conventions without affecting the applications of federated partners. The claim transformation process is what makes an ADFS trust relationship different from a traditional Windows trust relationship, which doesn't provide any means to control the user data that's made available to a trusted partner.

You can define claims in the Claim Definitions container in the ADFS MMC snap-in (Active Directory Federation Services\Federation Service\Trust Policy\My Organization). To define claim transformations, go to Active Directory Federation Services\Federation Service\Trust Policy\Partner Organizations. Figure 3 shows claim transformations on the identity provider side (upper panel) and on the resource provider side (lower panel). In this example, the internal group called Purchasing Agent is transformed to Purchaser, which is understood as an incoming claim at the resource provider side.

The ADFS claim transformation model is extensible: Organizations can develop their own claim transformation module that, for example, links up to a Microsoft SQL Server database to populate claims or that includes a workflow process to transform claims. To learn more about how to develop a claim transformation module, see the Windows 2003 R2 update of the Windows platform software development kit (SDK) at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sdkintro/sdkintro/windows_server_2003_r2.asp.

ADFS X.509 Certificate Requirements
ADFS uses X.509 certificates to secure the communications between ADFS components and to sign ADFS security tokens. The signing certificates are Secure MIME (S/MIME) signing certificates. The certificates used for secure communication are Secure Sockets Layer (SSL) client and server certificates. The following ADFS communications must be secured by using SSL:

• Communications between FSP and Federation Service require an SSL client certificate on FSP and an SSL server certificate on Federation Service.
• Communications between the browser client and FSP require an SSL server certificate on the FSP. You can put an optional SSL certificate on the browser client if you want strong certificate-based client authentication instead of one of the other IIS client authentication methods (basic, digest, or integrated Windows authentication).
• Communications between the browser client and an ADFS-enabled Web application require an SSL server certificate on the IIS Web server hosting the ADFS-enabled application. You can also put an optional SSL client certificate on the browser client.

ADFS doesn't automatically generate these certificates as part of the ADFS installation process. You must request the certificates manually prior to installing ADFS. You can either request certificates from a commercial Certification Authority (CA) such as VeriSign, or you can use an internal CA such as an internal Windows 2003 or Windows 2000 CA. You can also generate self-signed certificates by using the selfssl tool in the Microsoft Internet Information Services (IIS) 6.0 Resource Kit at http://www.microsoft.com/downloads/details.aspx?familyid=56fc92ee-a71a-4c73b628-ade629c89499&displaylang=en.

These three methods for obtaining certificates all have advantages and disadvantages. Your external federation partners will automatically trust the commercial CA certificates. This default trust isn't the case for certificates you generate from an internal CA or by using the selfssl tool: Browser users must explicitly trust your internal CA or the self-signed certificate. Using an internal CA gives you the most control and flexibility for the issuance of certificates. However, use of the internal CA also brings additional management and maintenance costs.

You can point ADFS to the token signing certificate as part of the ADFS installation process. The SSL client and server certificates must be configured manually. (For more information about configuration, refer to the ADFS and IIS 6.0 documentation and see the Microsoft article "Certificate requirements for federation servers" at http://technet2.microsoft.com/WindowsServer/en/library/ bfe5d887-e93b-42b6-8f4d-9a6f0bc14f9d1033.mspx?mfr=true.)

What ADFS Requires of You
Take the time to thoroughly plan and design your ADFS-based federation infrastructure, including the choice of the appropriate certificate provider, the selection of the proper account stores (AD or ADAM), and the definition of claims and claim transformations. Depending on the application you want to enable for ADFS, you might require application coding changes. The care you take now in planning and designing your ADFS infrastructure will pay off in future benefits to your organization and its federation partners.