Identity Federation with ADFS - 26 Feb 2007

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. One solution that can help you meet at least some of these requirements is identity federation. Windows Server 2003 Release 2 (R2) 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.

The goal of identity federation is to make it easier for organizations to share data with authorized external users (e.g., partner organizations, customers). 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.

A better alternative is to give users a single account they can use to access the resources in different organizations. One solution category that addresses this challenge involves identity brokers (e.g., Microsoft’s Windows Live ID, formerly known as Microsoft Passport). However, few organizations trust the outsourcing of their account management to an external entity, and the use of a central repository for storing accounts makes that repository a central point of attack and single point of failure.

Identity federation, aka federated identity management, is the third solution to the data access problem. Identity federation provides SSO for users and lets organizations 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 access management solutions offer, such as easy application integration and advanced auditing and reporting.

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 three main threads are briefly introduced below.

- The Security Assertion Markup Language (SAML) thread is driven by the Organization for the Advancement of Structured Information Standards (OASIS). SAML provides an XML dialect for embedding identity data in an XML message. SAML versions 1.2 and 2.0 are currently used in federation deployments. SAML 2.0 can be looked at as the convergence of SAML 1.2 and the Liberty Identity Federation Framework (ID-FF) 1.1 specification. For more information, go to

- The Liberty ID-FF 1.2 and Liberty Identity Web Services Framework (ID-WSF) 1.1 threads are driven by the Liberty Alliance, an industry consortium of more than 150 companies and organizations that focuses on standardizing identity federation. For more information, go to

- The WS-Federation thread is driven by IBM, Microsoft, and VeriSign and is a portion of a larger set of specifications for Web services. WS-Federation has been a relatively independent thread that overlaps somewhat with the Liberty Alliance threads. In 2005, Sun Microsystems and Microsoft announced specifications that allow interoperability between the WS-Federation and Liberty ID-FF standards for Web SSO. For more information about WS-Federation, go to; for more about interoperability of WS-Federation and Liberty ID-FF, go to

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

To learn more about ADFS, see Microsoft’s ADFS overview white paper, at

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.