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 silo—it'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, and—if they're like any other
corporation—probably 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 password—the one they use each day—to 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.
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
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 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.
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
simple—you have a repository of identity data that ADFS will make 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. 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 you—it 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 application—that is, one that recognizes roles and claims
within its own processes—then you can use Authorization Manager for
role-based access control.
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 1.
3.1. Claims Transformation
The pieces of
information being exchanged about a trusted partners' users—recall that
these are called claims—have 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 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,
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.
You can see this process diagrammed in a flowchart in Figure 2.
4. Demo: Collaboration with Windows SharePoint Services
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.
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 users—the ones that
users will actually log in to in order to administer the SharePoint
site—or 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. 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.
