In today's business environment, you're likely discovering that your organization's partners and vendors need to work with equipment and resources that cross organizational boundaries. However, without a system of trust, there are a few headaches to contend with when implementing secure access.
Typically, you give users who need access to other domains accounts on those domains, which solves the immediate access problem but still represents some significant security problems. If two companies' IT departments could come to some sort of trust agreement, that would bring many benefits to the table. To create that scenario, one business would trust certain Active Directory accounts from another company to access its application with its own credentials -- without requiring a local account.
This trust, called federated identity management (FIM), is the core concept behind Windows Server 2003 R2's new Active Directory Federation Services (ADFS) component. ADFS integrates the concept of FIM into Windows using Active Directory as the base identity store. By using ADFS, you can eventually enable secure access to Web applications outside of a user's home domain or forest. ADFS uses all of the identity information in AD and makes that information available outside of the local AD forest into the realm of the extranet, if there are applications out there, or to other organizations for their use.
ADFS supports a couple of scenarios natively: Web single sign-on and the traditional identity federation model.
- Single sign-on. By using forms-based authentication and giving users a single-sign-on session cookie, users will log in once when they access the first Web application, and then this cookie will be used to answer any future credential challenges by other resources in the domain. You remove the need for repeatedly requesting user credentials.
- Identity federation. The difference here is fundamental: Identity federation separates authentication (verifying an identity) from the access control, or authorization decision, and places it squarely on the account side of the relationship rather than on the resource side. So, instead of a user authenticating to an extranet site by entering his credentials, the user's home Active Directory -- otherwise known as his "home realm" -- authenticates the user and then automatically generates a security token for the end user. The user then presents that token to a target application, and the application itself uses that token to grant access rights.
ADFS is basically made up of four components: Active Directory, where the identity information is stored; a federation server, a federation server proxy and an agent that runs on a Web server. The AD component is simple -- you simply have a repository of identity data that ADFS makes use of -- so let's move to the other parts of the architecture. The federation server is a service that handles and processes security tokens and contains the tools needed to manage federated trusts between business partners. The federation server proxy is a machine the client connects to when requesting the security token. It provides all of the UI that the browser would need to display for you. Finally, the agent that runs on the Web server makes sure the end user is authenticated and then creates a context for the user.
Let's step through the flow of a typical federation transaction:
- A client will access the Web server hosting the application.
- The Web server will look for the client's security token. If one isn't present, the user is redirected back to the federation server on the resource side.
- That resource federation server then determines where the client is from; a drop-down list, an e-mail address or a persistent cookie will identify the client's origin.
- The resource federation server, now knowing where the client is from, will redirect the client to the federation server on the account side.
- The client logs in, and subsequently authenticates to the account-side federation server.
- That server then creates a security token that will be sent back to the client.
- The client presents the security token to the resource federation server.
- The resource federation server validates the security token (ensuring it came from a trusted partner, was signed appropriately and hasn't been tampered with).
- The resource federation server can make modifications to the security token, if necessary, to translate different claims into data that the application can understand. (For example, if a social security number is being transmitted, the account-side federation server may term that data SocSecNum, while the resource side might need that data labeled SSN. More about this in a bit.) If no translation is necessary, then this doesn't occur.
- The server will sign a new security token and send it back to the client.
- The client then goes to the Web server, which allows him or her to access the application.
Using ADFS for business partner information and resource sharing presents security benefits. For the user, it's one less username and password to remember. For the administrator, it means less of a headache in terms of administration. For the helpdesk folks, it represents fewer forgotten password calls. It also means that user accounting calls can be passed, without cost, to the other company for it to handle. Perhaps most significantly, it means that accounts for employees who leave one company aren't left open indefinitely. This closes a significant security hole and increases the integrity of both the partner's and its own networks.
For more information on ADFS, check out this .NET Show episode about ADFS' inherent capabilities. There is also a white paper on Microsoft's Web site explaining scenarios, requirements and terminology in further detail than what I've covered here. And finally, for a step-by-step single sign-on lab setup, check out Step-by-Step Guide for Active Directory Federation Services.
About the Author:
Jonathan Hassell is author of Hardening Windows (Apress LP) and is a SearchWindowsSecurity.com site expert. Hassell is a systems administrator and IT consultant residing in Raleigh, N.C., who has extensive experience in networking technologies and Internet connectivity. He runs his own Web-hosting business, Enable Hosting. His previous book, RADIUS (O'Reilly & Associates), is a guide to implementing the RADIUS authentication protocol and overall network security.
This tip originally appeared on SearchWindowsSecurity.com
