ComputerWorld.in

Review: Microsoft ADFS 2.0 and Forefront Identity Manager 2010

Managing user access in businesses today is something like playing traffic cop in an intersection of a thousand roads. From Web-based applications to homegrown programs, from desktop PCs to the latest crop of smartphones, IT has to be able to control access to every sort of resource while allowing users to access them from anywhere and any platform.

A bigger challenge is providing seamless access to applications and systems across corporate or network boundaries. It's no trouble for IT to define and manage user names and passwords on their own network, but it takes more work -- or is nearly impossible -- to extend access to internal systems to numerous external users or to manage local user access to a system outside of their control.

Microsoft has updated Forefront Identity Manager (FIM) 2010 and Active Directory Federation Services (ADFS) to aid IT in applying identity management across domains and business boundaries. Both of these tools are intended to extend user access control across the enterprise; FIM uses a common platform to tie user, certificate, group, and policy management together, while ADFS provides trust accounts between different networks or organizations. Together, they provide a powerful platform for extending user management beyond the company domain or network edge.

Active Directory Federation Services 2.0
Active Directory Federation Services, first available in Windows Server 2003, is now a server role in Windows Server 2008 R2. ADFS is a single-sign-on technology that uses claims-based authentication to validate a user's identity across domains. Normally when the user's account is in one domain and the resource is in another, the resource will prompt the user for local credentials. ADFS eliminates the secondary credential request; the user's identity is validated, and access provided, based on information in the user's home directory.

Through the use of ADFS, it is possible to facilitate a wide range of managed access. It makes it easy for users to access an Internet-accessible application on another company's network or to allow outside contractors access to internal resources for the duration of a specific project. The key advantage is that neither domain need contain any of the other domain's user information; no user information is shared, and each side remains responsible only for its own user management.

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.

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.