Section 5.6. Active Directory Federation Services

5.6. Active Directory Federation Services

In today's business environment, you're likely finding that your organization's partners and vendors need to work with equipment and resources that cross organizational boundaries. For instance, your business partner may need access to your ordering system, your vendor has to have a way to submit invoices to your accounting department, and your alliance's R&D teams need to collaborate with documents and presentations across different platforms and different security boundaries. Today, it's not about being an information siloit's about securely managing access to information, both internally and externally.

But with this new model of sharing information comes an interesting problem that's one of trust, particularly across security boundaries. Here, I'm digging at a core problem that's facing IT in larger organizations today. Let's look at this in terms of an example.

Let's say that TrinketBuild, Inc. sells trinkets, and TreasureBuild, Inc. sells treasures. To build a trinket, one needs to include a treasure, which is a core component of the trinket. TrinketBuild has come to an agreement with TreasureBuild to get treasures at a lower price in a large quantity. TreasureBuild uses an externally facing application to take orders and process payment for their orders, and their customers' employees (in this case, TrinketBuild's employees) have traditionally had accounts to be able to access this application.

When we introduce the concept of accounts into this example, we introduce an issue known as identity management. In a nutshell, how does one manage all of the accounts that one person has to his name? For example, TrinketBuild's employees probably have several accounts: one to log in to the network each day, perhaps a separate email account, accounts to access mainframe business applications, andif they're like any other corporationprobably ten more accounts for various resources. Now upon the signing of this agreement with TreasureBuild, some TrinketBuild employees will have still one more account added to their load of usernames and passwords: the one used to access TreasureBuild's ordering and billing application.

But wouldn't it be great, from a lot of angles, if TrinketBuild employees could use their own Active Directory username and passwordthe one they use each dayto access TreasureBuild's extranet application? What if the two companies' IT departments could come to some sort of trust agreement, wherein the TreasureBuild department trusts certain Active Directory accounts (and more specifically, some attributes from those accounts) from TrinketBuild to access their application with their own credentials, without requiring a local TreasureBuild account? What benefits would this bring?

Here are just a few:

For the user, it's one less additional username and password to remember. The TrinketBuild employee could log in as john@trinketbuild.com and receive all the access he was entitled to. If nothing else, it's a lot less confusing.
For TreasureBuild, it means less of a headache in terms of administration. Authorized TrinketBuild employees won't need to have a local account created just so that they can access the extranet application.
For TrinketBuild, it means their internal IT department will be getting fewer forgotten password calls. It also means that all of the user accounting calls can be passed, without cost, to TreasureBuild for them to handle.
For the security team at TreasureBuild, it means that accounts for TrinketBuild employees who leave aren't left open indefinitely. Why? Since the TrinketBuild employees are using their AD accounts to log in, as soon as those accounts are disabled by TrinketBuild, those credentials are inherently invalid to log in anywhere else. This closes a significant security hole.

By integrating this sort of trust in their accounting and transactions, TrinketBuild and TreasureBuild are participating in federated identity management (FIM). FIM is a standards-based technology and process that enables identification, authentication, and authorization information to transcend traditional security boundaries. The idea of federation is one of heterogeneity: different companies use different technologies, identity storage and security approaches, and programming models, but they still need to interact with other companies with still different technologies, identity storage and security approaches, and programming models. Among these differences, there should be a standardized way of advertising the types of services one offers externally, but also of accepting trusts, credentials, and policy information from other organizations.

In Windows Server 2003 R2, Microsoft has included Active Directory Federation Services, a new component, which 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 "projects" that information 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. Doing so, of course, improves security, enables auditing and tracking (which is an important capability to have in today's regulatory environment), and increases end-user productivity.

5.6.1. Scenarios

ADFS supports a couple of scenarios natively: web single sign-on, and the traditional identity federation model.

Let's look at the single sign-on model first. If you use Windows Server 2003 R2 and IIS 6 for an externally accessible web application, you can use forms-based authentication and give users a single-sign on session cookie, which removes the need for them to log on to access any other resources in a trusted domain. In this way, 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. Since one web "application" is usually actually a collection of multiple applications, you remove the need for repeatedly requesting user credentials.

The second scenario involves regular 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 Directoryotherwise 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 target application, and the application itself uses that token to grant access rights. The key to this process is the federated trust that the two partners set up, which includes exchange of keys and standardization on the types of information about users the application will require. (These pieces of information are called claims .) Thus, through the process of federation, the end user signs on once to all of their internal network applications through the regular Windows authentication process, but he also gets seamless access to partner applications without having to sign on again.

5.6.2. Architecture

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 simpleyou have a repository of identity data that ADFS will make use ofso let's move to the other parts of the architecture .

The federation server is a service that handles and processes security tokens. The federation server also contains the tools needed to manage federated trusts between business partners. The server takes user information and claims and populates these security tokens with the claims. Common claims might include a user's job title, department, level of access to a particular function, a credit or purchasing limit, and approval requirements.

The federation server proxy is a machine to which the client will connect to request the security token. It also provides all the UI that the browser would potentially need to display for youit basically acts as a front end for clients to all of the magic of ADFS.

The last component is an agent that runs on the web server that makes sure the end user is authenticated. Once this is done, the agent creates a context for the user. If you have a classic client-server application that requires an NTLM security context (one where you assign permissions based on ACLs and such), the agent will actually create that context after it decides the security token was valid. Windows SharePoint Services, among other applications, works really well with this type of context. If you have a claims-aware applicationthat is, one that recognizes roles and claims within its own processesthen you can use Authorization Manager for role-based access control.

5.6.3. The Flow of Applications and Claims

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 will be redirected back to the federation server on the resource side.
That resource federation server will then determine where the client is from; a drop-down list, an email 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 clients logs in, and subsequently authenticates to the account side federation server.
That server will then create 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 will validate 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 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 will then go to the web server, which will allow him or her to access the application.

You can see this process depicted graphically in Figure 5-55.

5.6.3.1. Claims Transformation

The pieces of information being exchanged about a trusted partners' usersrecall that these are called claimshave a flow all their own. 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 userswhat 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, TreasureBuild might expect a user's title to be Purchaser, but TrinketBuild uses the Purchasing Agent identifier internally. This is really the only point in which you need to fully understand and expect the format in which the resource side needs its claim information.

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 needed to know in what format the resource federation server expected the data; how the data is subsequently transformed is of no concern to the account side.

Figure 5-55. The ADFS application flow

You can see this process diagrammed in a flowchart in Figure 5-56.

Figure 5-56. The ADFS claims flow

5.6.4. Demo: Collaboration with Windows SharePoint Services

So let's put all of this to use. It's difficult to put together an in-depth demo about ADFS within this book because where ADFS really shines is when claims-aware applications are used. Since there isn't a standard claims-aware application available to use for this demo (at least at the time of this printing), we'll demonstrate the concepts of federation using Windows SharePoint Services by setting up a trust between two distinct business units so that they can each access WSS and bring in new users.

To get started, you will need to install Windows Server 2003 R2 on three machines: one that will act as the SharePoint server; one as a federation server for the account side, and the third as the federation server on the resource side.

Once you have all three machines running, install ADFS and the Federation Server components on two of them. You can do this from the Windows Components section of Add/Remove Programs within Control Panel. On the third, install Windows SharePoint Services 2.0 and also select the ADFS Web Agent software, which is under the Active Directory Federation Services option. (Choose the traditional application option.) Then, to the third machine, add an administrator account which will be used to manage SharePoint.

The SharePoint machine needs some additional configuration. Step through the following process to get it ready:

Open the IIS Manager from the Administrative Tools menu.
In the left pane, navigate through Local Computer and Web Sites.
Right-click on Default Web Site and select Properties from the pop-up context menu.
The Add/Edit Filter Properties box appears. On the ISAPI Filters tab, click the Add button.
In the Filter Name text box, enter ADFS Filter and then click the Browse button.
Navigate to C:\Windows\system32, select ifsfilt.dll, and then click Open.
Click OK, and then make sure that the new ADFS Filter is the first filter listed.
Click the Home Directory tab, and under Application Settings, click the Configuration button.
In the Wildcard application maps tab, click the Insert button.
Next, click the Browse Button and navigate to C:\Windows\system32 directory. Select ifsext.dll, and make sure that the Verify that file exists option is not checked. Click OK.
In the left pane, right click on Web Sites and select Properties from the context menu.
Click on the ADFS Web Service Agent tab.
In the Federation Service URL text box, type in the URL for the FederationSer-verService.asmx location for the local Resource Federation Service, and then click OK.
Right-click on the Default Web Site and select Properties.
Click on the ADFS Web Service Agent tab.
Check the Enable Active Directory Federation Service Web service agent box.
Set the Cookie path value to be "/".
Set Return Uniform Resource Locator (URL) to be https://currentmachinename.
Click OK.

On each of the federation servers, do the following:

Create an application in the ADFS management tool. Open the tool from the Administrative Tools menu, and then in the left pane, expand Federation Service, Trust Policy, My Organization, and then right-click on Applications and select Application from the New menu. Create a traditional application, in which claims don't need to be sent. Note that the URL in the wizard should be the same as the URL that was entered as the Return URL in step 18 of the previous instructions.
Choose to either set up your resource federation server as a local account federation server for your local administrative usersthe ones that users will actually log in to in order to administer the SharePoint siteor set up a new federation between your resource federation server and your account federation server. Either option will work.

In terms of accounts, you also have a couple of options. You can, for example, create a local account for each user accessing the site. These local accounts will never actually be logged into a directory and the user will never need to know the password. As a matter of fact, the user will never even need to know the account exists. The advantage of this option is that you can control the access to each SharePoint site on a per-user basis, and you can go through the SharePoint invite process that's built into the product. The disadvantage is the Active Directory administrator will need to create a local AD accounts for each incoming user.

If that option doesn't appeal to you, your second option involves using a feature in ADFS called Group-to-UPN mapping. With this feature, the administrator creates one or more accounts locally that will have certain privileges in SharePoint. The user will also have a group claim that will be mapped to his or her local user account. The benefits for this method: you reduce the number of local accounts that a site will need to have; the account/ADFS administrator can now choose who has access to the SharePoint site, and the resource-side administrator can manage what groups have access. However, you lose the granular access control provided in the first option, and can't send standard SharePoint invitation messages.

If you choose option one, you should create local accounts for each user that will need to access the SharePoint Site. The UPN of the local account will need to be the same as the UPN coming across in the security token from the account federation server. Launch the Active Directory Domains and Trusts administrative tool to set up new UPN suffices. On the Active Directory Domains and Trusts node in the left pane, right-click and select Properties. In the Alternative UPN Suffixes text box, enter the UPN suffix of a federation-aware domain, then click the Add button. After all suffixes are entered, click the OK box and close the application. Then, to create new user accounts for accessing SharePoint, you can create a new OU to house the partner accounts, or they can be put anywhere else in your AD structure. Within ADUC, right-click the container you want to create the local account in, select New, and then select User. Proceed through the wizard as previously outlined in this chapter; however, in the User logon name box, enter the first part of the users UPN, then in the drop-down box on the left, select the user's UPN suffix. In the User logon name (pre-Windows 2000) box, make sure the name is unique. This unique name is not actually used, so you can enter whatever you want. Click the Next key after all the fields have been populated, And then enter a dummy password and finish the wizard. After all of these steps are accomplished, the standard SharePoint invitation messages will work.

If you choose option two, open the ADFS Management tool on the SharePoint server, and do the following:

Expand Federation Service, Trust Policy, Trusted Accounts, and click on Account Partners.
Click on the Account Partner that you will be using.
In the right pane, right-click on User Principal Name and select Properties.
Navigate to the Groups tab and type in the incoming claim from the account partner in the Group Field.
Click on the "..." button to the right of the UPN field.
Enter the username you want this group to map to, then click the Check Name button. If the name resolves correctly, click OK.
In the Incoming UPN Claim Transformation properties dialog box, click the Add button to add this mapping, and then click OK.
Finally, right-click on Trust Policy in the left pane and select Apply changes.

After that's complete, you're all set. Users from both the account and resource sides can use the WSS site, and if you chose option one, you can bring new people into the site by simply issuing a SharePoint invitation.

5.6.5. More Information

There are quite a few resources that Microsoft has made available for users interested in learning more about ADFS. For a more visual introduction to the concepts here, check out the .NET Show episode with David McPherson and Don Schmidt, where the two talk about ADFS' inherent capabilities. You can find that episode at:

http://www.microsoft.com/downloads/details.aspx?FamilyID=c82d1449-3239-40d7-954b-4cf8e763d785&displaylang=en

There is also a whitepaper on Microsoft's web site explaining scenarios, requirements, and terminology in further detail than what I've covered here. This paper is located at:

http://www.microsoft.com/WindowsServer2003/R2/Identity_Management/ADFSwhitepaper.mspx

And finally, for a step-by-step single sign-on lab setup, you can check out the document located at:

http://www.microsoft.com/downloads/details.aspx?FamilyID=062f7382-a82f-4428-9bbd-a103b9f27654&displaylang=en