InfoWorld review: Microsoft ADFS 2.0 and Forefront Identity Manager 2010

A claims-based system, like many others, uses digital tokens that contain information about the user. But unlike a request made directly against Active Directory and generating a Kerberos token, the resource being accessed doesn't interact directly with the user data store. Instead, it talks to a Security Token Service, such as ADFS, which performs the check against the user information store and creates a claims token based on the result of the lookup. The claims token can contain as much -- or as little -- information as needed to access the particular service.

Using claims-based authentication between two different domains requires a Security Token Service in each domain. Each domain's Security Token Service must trust the other one, and based on this trust, a policy is defined that specifies if access is granted or denied to a specific resource. For example, when a user on Network A attempts to access a Web portal on Network B, an authentication request is made to the user's Security Token Service on Network A. After validating the claims for the user against the local user directory, Network A's Security Token Service provides a token to Network B's Security Token Service, which then issues its own token to the requesting user in order to access the Web portal. There is a lot of back and forth behind the scenes, but once the remote domain gets the all-clear from the user's Security Token Service, the user gets a new token as if they were a member of the remote domain.

[ From powerful productivity enhancers to important security safeguards, Microsoft Office 2010 has a number of features that businesses will love. See "Top 10 Office 2010 features for business," "More great Office 2010 features for business," and "PowerPivot for Excel 2010: Power to Excel people." ]

Within a single domain -- such as when you want to extend user access to a cloud service without implementing a direct authentication connection to Active Directory or another user database -- a single Security Token Service will do the job. In addition to supporting claims-aware ASP.Net applications and (through an IIS Web server agent) Windows NT token-based applications on the resource side, ADFS 2.0 can communicate with third-party federation services and cloud services using SAML 2.0.

The great advantage of claims-based authentication -- and ADFS 2.0 -- is that no changes are made to either domain's users and no confidential information is sent between domains. When a claims-based request is made from the resource, it simply performs an "is allowed?" request against the issuing claims server. The claim token returns a Yes or No response regarding the user and nothing more. This gets the application out of the user authentication business. It simply asks a trusted partner if it is OK to allow this person to access its resources. All the heavy lifting is done behind the scenes.

ADFS 2.0: Federation services and user claims
There are three role services that make up ADFS: the Federation Service, the Federation Service Proxy, and the Web server agent. The Federation Service is the core of ADFS; it's the part of the system that handles user authentication requests from other federation servers. The Federation Service Proxy runs on a server located in the network's DMZ and proxies an external user authentication request to an internal ADFS server. It collects user credentials from browser clients and sends them on to the ADFS server. The Web proxy agent works with claims-aware (ASP.Net) applications on a website and redirects user login requests to the ADFS server. The Federation Service Proxy and the Web agent are optional and may not be needed in all scenarios.