Explainer: Active Directory Federation Services

Federated identity management, or FIM, is just one of the latest networking buzzwords to hit mainstream. FIM involves a set of agreements for trusting repositories of accounts located in two or more separate environments so that all of the members of the trust agreements allow access to their own applications and resources using accounts "sponsored" by another entity.

For example, let's say Company A stores its accounts in Active Directory, and Company B stores its accounts in another directory service. Both have Web resources that they'd like to allow access to for their partner company. Company A has an online purchasing tool, and Company B hosts the information exchange site for this particular venture.

By using FIM, Company A can set up a trust so that accounts from Company B can access their purchasing application using Company B credentials, without needing a local account for Company A. Likewise, Company B trusts Company A so that users needing access to the information exchange site can log on using their Company A account credentials.

Active Directory Federation Services (ADFS) takes FIM and integrates it into the core of Active Directory. ADFS uses Active Directory as the base identity information store and, out of the box, allows secure access to Web applications outside of the domain or forest where the user's Active Directory account resides.

ADFS uses all of the identity information in Active Directory and broadcasts that information out to the extranet, applications that are running on it or to other organizations for their use. ADFS includes four basic components:

  • Active Directory
  • A federation server: This manages trusts between business partners
  • A federation server proxy: This is a machine that pushes the user interface that the browser displays for the end user.
  • A Web server agent: This verifies that authentication has taken place and then casts a security context for the session. If you have a classic client/server application that requires an NT LAN Manager security context (one where you assign permissions based on access-control lists and such), the agent will actually create that context. Windows SharePoint Services, among other applications, works really well with this type of context.

ADFS supports a couple of scenarios natively: Web single sign-on and the traditional identity federation model. In the very basic single sign-on model, which uses forms-based authentication and a session cookie, users will log in once when they access the first Web application. The cookie is then delivered and is used to respond any future account challenges by other resources in the domain.

The identity federation model

More complex is the identity federation model. This model splits authentication from authorization (access control). The home domain performs authentication, but the resource domain performs authorization. The authenticating domain delivers a security token to the end user, and his client gives that token to target application on the resource side, which makes the authorization decisions on what the user can and can't access.

The key to this process is the federated trust that the two partners set up, which includes exchange of encryption keys and standardization on the types of information about users -- called claims -- the federated application will require.

The pieces of information being exchanged about a trusted partners' users go through a workflow. Organizational claims are made by the user's home realm; most commonly, these organizational claims are simply attributes in Active Directory that each user possesses. It's just a standard way for your organization to think about the information that it stores about its users -- what groups they belong to, their addresses, phone numbers, title and identity information.

The utility of ADFS is the capability to transform those claims into the label that the resource side of the trust is expecting. For example, Company A might expect a user's title to be Purchaser, but Company B uses the Purchasing Agent identifier internally. The same type of transformation can take place on the resource side.

Different applications need different types of claims, so the order application might take Purchasing Agent, the ERP application might use Buyer, and the tracking application might use Purchases. The resource federation server knows about these peculiarities and can further transform these claims into what these applications and systems need.

A key point here: This stuff doesn't matter to the account side. The account federation server only needs to know in what format the resource federation server expects the data; how the data is subsequently transformed is of no concern to the account side. And this entire process is seamless to the user.

Using ADFS for sharing account information and resources gives organizations significant benefits:

  • From the user's perspective, he needs not learn another set of credentials for access to another site or resource. He can use his own username and password to access federated sites.
  • For the administrator's perspective, it means less of a headache in terms of administration. He doesn't need to create local accounts for partners to access resources she controls.
  • From the help desk perspective, there of course are fewer password-recovery phone calls. Further, user accounting calls for a federated resource can simply be redirected to the other company for them to handle -- after all, they are their accounts.
  • From a security perspective, it means that accounts for employees who leave one company aren't left open indefinitely. This is perhaps the single biggest security benefit of the entire federation concept.

Learn more:

Jonathan Hassell is an author, consultant and speaker on a variety of IT topics. His published works include RADIUS, Hardening Windows, Using Windows Small Business Server 2003 and Learning Windows Server 2003. His work appears regularly in such periodicals as Windows IT Pro, PC Pro and TechNet Magazine. He also speaks worldwide on topics ranging from networking and security to Windows administration. He is currently an editor for Apress LLC, a publishing company specializing in books for programmers and IT professionals.

Copyright © 2006 IDG Communications, Inc.

8 highly useful Slack bots for teams
Shop Tech Products at Amazon