• Illustration: ADFS Federated Identity Scenario

Windows Server 2003 R2, a forthcoming interim release of Windows Server, includes a new technology called federated identity that will help organizations securely share Web applications and services with authorized external customers and partners. R2 will also include improvements for managing user identities with Active Directory Application Mode and UNIX Identity Management. Together, these improvements could help organizations secure which users have access to which resources. However, the first release of Microsoft's federated identity technology, called Active Directory Federation Services (originally code-named TrustBridge), supports access only to Web-based applications, and may require changes to some of those applications.

What Is Federated Identity?

Federated identity is designed to make it easier for an organization to share its internal resources with authorized users from other organizations, such as customers and partners. For example, a software company might want to allow its public relations firm to read technical specifications and marketing plans for an upcoming product, hosted on the software company's secured Web servers. However, the software company must somehow authenticate (verify the identity of) the PR firm's users to ensure they can be trusted. Ideally, users at the PR firm could access the information with a single sign-on (SSO), without having to log on first at the PR firm and then again at the software company.

One common solution is multiple user accounts: the software company creates a user account in its own directory for each employee of the PR firm and grants that account access to the appropriate documents. However, maintaining multiple accounts is costly and creates security risks. For example, an employee might be fired by the PR firm but still have access to the software company's files through an account there. In addition, a multiple-account solution usually does not provide SSO, as the user generally must log on to each account. These problems are compounded when a company is dealing with tens or hundreds of partners and wants to grant different levels of access to each one.

Centralized identity brokers, such as Microsoft's Passport, which provides an SSO service for MSN and other Microsoft Web sites, suggest an alternative to multiple accounts: organizations could store all their user accounts at a single trusted organization and let that organization authenticate all users, internal and external. Here, the problem is that the trusted organization becomes a fat target for attackers and a single point of failure, and some individuals and companies have privacy concerns about allowing a broker to hold their identity information.

In a federated identity system, each organization authenticates its own users and maintains their user accounts. When a user wants to access resources at a partner organization, the user's home organization forwards a security token that contains proof of the user's identity to the partner and the partner grants access based on the degree to which it trusts the user's home organization. So, in the example mentioned earlier, when a user from the PR firm tries to access the software company's files, the PR firm would authenticate that employee and forward the employee's authentication data in a security token to the software company.

A federated identity system can be more secure and maintainable than one that duplicates or centralizes accounts because a single copy of the user's account information and associated secrets (such as passwords) stay with the user's employer, ISP, or some other organization the user trusts. Federated identity can also support SSO: a user can authenticate once with her home organization, which authenticates the user to partner organizations without further action on the part of the user.

Active Directory Federation Services

Active Directory Federation Services (ADFS) is a new component of Windows Server 2003 R2 that will initially allow an organization to offer customers and partners federated identity for Web applications. ADFS builds on existing Windows Server identity management and authorization services, including Active Directory (AD), the Windows Server store for identity data required for authentication and authorization, and Kerberos, a public standard for authenticating users.

How ADFS Works

Key to ADFS are resource and account partners and the federated trust relationships that exist between them.

The resource partner is the organization that hosts the resources, which for Windows Server 2003 R2 will be Internet Information Services (IIS) Web applications. The account partner is the organization that maintains and manages the identity information (user accounts) for the users who need to access the resource partner's Web site.

In the previously cited example, the software company wanted to allow its PR firm to read technical specifications and marketing plans hosted on the software company's secured Web servers. The software firm is the resource partner, the documents are the resources, and the PR firm is the account partner. The resource partner (the software firm) trusts the account partner (the PR firm) to authenticate users: that is, the software firm has agreed to accept security tokens issued by the PR firm. As a result, the account partner's users can access resources owned by the resource partner, but the resource partner does not have to manage or duplicate user accounts in its directories for these users.

ADFS servers establish the federated trust relationships between the resource and account partners and transmit security tokens between them. In ADFS, a security token contains one or more claims about a user, digitally signed by the account partner that owns the user's account. Claims typically include the user's name, e-mail address, group memberships, and other data that will help a resource partner decide how much access to grant a user.

(See the illustration "ADFS Federated Identity Scenario".)

The account partner's ADFS builds security tokens using the user's AD account. The resource partner's ADFS verifies that any security token from an account partner is valid (has been digitally signed by the account partner and not subsequently tampered with). The resource partner's ADFS also extracts claims from security tokens and passes them to applications that need to make authorization decisions about the user.

So, in the example discussed above, the PR firm's ADFS builds a security token for the PR firm user, based on the user's AD account. The token includes the user's e-mail name and relevant group memberships (such as membership in the PR management group for the software firm). The software company's ADFS verifies that this token was signed by the PR firm and then passes the e-mail name and group membership information to the Web site. Finally, the Web site determines whether members of the PR user's group are allowed to access a particular document, and if so, authorizes the user.

To enable this scenario, administrators for the resource partner must set up a federated trust relationship with the account partner. These trust relationships establish the necessary digital certificates to secure communication between the partners, and the resource partner then uses these certificates to verify security tokens. Setting up a federated trust also enables the resource partner's ADFS to locate a user's associated account partner ADFS server from information supplied by the user (such as the user's e-mail name).

ADFS trusts are one-way—the resource partner trusts the account partner, but the account partner doesn't trust the resource partner—and are non-transitive. (In a transitive trust, if A trusts B and B trusts C, then A also trusts C.) If there is a requirement for both organizations to trust the other, then two one-way trusts can be created.

May Require Web Application Changes

The resource partner organization must install the ADFS Web Services Agent on any Web servers that it wants to expose to the account partner. This agent determines whether users accessing the Web application have a recognized security token—either from the resource partner or a trusted account partner.

Then there must be an authorization mechanism to process the claim information about the user that ADFS extracted from the security token, and to determine what the user is authorized to do at the Web application.

With ADFS there are several ways for an application to perform authorization, including the following:

Use Authorization Manager. Authorization Manager (AzMan) is a Windows Server 2003 component that supports role-based access control (RBAC)—that is, it grants access to applications based on the user's role within an organization. For example, a Web application for managing employee expenses could have two roles that employees are allowed to perform—submit expenses and approve expenses. Depending on an employee's role, he will be able to perform different operations or tasks with the expense application.

AzMan stores the information necessary to manage roles and associated authorizations in an Authorization Policy Store, which can either be stored in the AD or an XML file. This information may include the following:

• The operations and tasks that the application allows
• Business rules, such as the maximum expense amount a user in a particular role can submit
• Groups of users created from AD groups or LDAP queries.

AzMan may be the best way to manage authorization to applications (including internal applications that may never be federated) because it:

• Allows the organization to manage access to applications based on the user's role within the organization—for example, a Business Analyst role could be created and assigned access to application data based on business rules assigned to the role and stored in AD or an XML-based store
• Abstraction allows organizations to change the roles and their associated business rules, which manage authorization to the application, without having to change the application.

Employ an application-specific authorization mechanism. Developers can use a variety of class libraries and APIs to develop their own authorization system for their Web application, including the ASP.NET IsInRole, local identity mapping (or automated NT impersonation, which can allow applications such as SharePoint to work with ADFS with no changes to the application), or the ASP.NET raw claims API.

Web Standards Promise Federation Interoperability

In addition to using existing services in Windows server, such as AD, ADFS uses evolving Web Services Architecture (WS-*) standards, such as WS-Federation, which describes a standard way to create federations, and WS-Security, which defines a standard set of mechanisms to exchange secure, signed messages.

By using these standards, Microsoft has demonstrated interoperability between ADFS and solutions from vendors such as IBM, Netegrity, Oblix, OpenNetwork, Ping Identity, and RSA.

Active Directory Application Mode

With Windows Server 2003 R2, Active Directory Application Mode (ADAM), which was originally released as a free feature pack after Windows Server 2003 shipped, becomes a feature of the server.

ADAM is a Lightweight Directory Access Protocol (LDAP) directory service that provides data storage and retrieval for directory-enabled applications. It offers much of the same functionality as AD, but is not subject to certain AD limitations: for example, it does not require the deployment of domains or domain controllers, and multiple instances of ADAM can coexist concurrently on the same server, with an independently managed schema for each ADAM instance.

ADAM gains several new capabilities in Windows Server 2003 R2, including the following:

Use with ADFS. ADAM can be used as a directory store with the new ADFS component.

AD to ADAM Synchronizer. This tool synchronizes objects from AD to an ADAM instance.

User password chaining. ADAM can now chain user password requests in ADAM to the user object in AD so that if a password is changed, it is changed in both directory services. ADAM passwords are now treated the same as a user password in AD in that the new password must meet any password policies.

Improved LDAP tool. A new GUI-based tool for general administration of an LDAP directory service, which now supports digest authentication and an access control list (ACL) editor.

Unix Identity Management

Like ADAM, Services for Unix (SFU), which was a free feature pack for Windows Server 2003, become a Windows Server 2003 R2 feature. In general, SFU makes it easier for organizations to migrate from or interoperate with Unix. However two particular components—formerly part of SFU and now incorporated into Windows Server 2003 R2— relate to identity management in that they help provide improved user access and management of resources across Windows and Unix:

Server for Network Information Service (NIS). This component helps integrate Windows and Unix-based NIS servers by enabling an AD domain controller to act as a master NIS server for one or more NIS domains. NIS, which was developed by Sun Microsystems and originally called Yellow Pages, centralizes the administration of Unix and Linux and is fundamentally similar to AD. Identity Management for Unix includes a wizard that administrators can use to export NIS domain maps to Active Directory entries.

Password synchronization. Users do not need to maintain separate passwords for their Windows and Unix accounts or remember to change the password in multiple locations. Password synchronization automatically changes a user password on the Unix network when the user changes his Windows password and vice versa.

Although ADFS is built on industry-accepted standards, and the Unix Identity Management services in R2 support integration with Unix systems, neither of these technologies are part of the collaboration between Microsoft and Sun resulting from the settlement of litigation between the two companies.

Availability and Resources

Windows Server 2003 R2 is currently available as a release candidate. The product is expected to ship before the end of 2005.

Windows Server 2003 R2 requires Windows Server 2003 SP1.

The release candidate for Windows Server 2003 R2 can be downloaded at www.microsoft.com/windowsserver2003/R2/trial/default.mspx.

A reviewer's guide outlining the new and updated features of R2 is at www.microsoft.com/windowsserver2003/R2/overview/revguide.mspx.

Detailed information on the ADFS support in R2 is available at www.microsoft.com/WindowsServer2003/R2/Identity_Management/ADFSwhitepaper.mspx.

A step-by-step guide to deploying ADFS is at: www.microsoft.com/WindowsServer2003/R2/Identity_Management/ADFSdeployguide.mspx.

An overview of ADAM is available at www.microsoft.com/windowsserver2003/techinfo/overview/adam.mspx.

Services for Unix improvements are described at www.microsoft.com/windowsserver2003/R2/unixcomponents/default.mspx.

For additional background on Microsoft's federation plans, see "TrustBridge to Simplify Resource Sharing" on page 13 of the Aug. 2002 Update.