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.