Frederick Chong (Microsoft) and Dwayne Taylor (RDA Corporation)

June 2006

Applies to:
   Application Architecture

Summary: This article provides an in-depth look at the challenges and requirements of securing the exchange of information and services between independent organizations. It also explores a solution to solve the challenges and requirements associated with using technology to securely interact between organizations. (25 printed pages)

Click here to download the code sample for this article.

Thanks to Pablo Cibraro (previously Lagash Systems SA) for implementing the federation sample code described in this paper.

Contents

Introduction
Challenges in Sharing Business Information
Key Concepts
Scenarios
Federation Scenario Patterns
Common Existing Practices
Technology Requirements
Federation: Conceptual Architecture
Federation Patterns
Existing Federation Technologies
Solution Scenario and Requirements
Conclusion

Introduction

As technology becomes a more integral part of doing business, it has become the key to sharing information and services between organizations. However, with the ability to share information comes the responsibility of protecting it. Business losses, civil liability, and government regulation are all motivation to keeping information from falling into the wrong hands and preventing unauthorized parties from using services. Now, more than ever, organizations need a means to establish trust with each other through technology.

The first step to establishing trust is the ability to recognize and verify the identity of parties accessing information or services. The next step is to make decisions about what the verified party can and cannot access, and the manner in which the resources and services can be accessed.

This paper provides an in-depth look at the challenges and requirements of securing the exchange of information and services between independent organizations. In addition, it will explore a solution to solve the challenges and requirements associated with using technology to securely interact between organizations.

Challenges in Sharing Business Information

Today's businesses are constantly challenged by the corporate trend for more transparency versus the need to share.

Even when there is the business need to share information with other organizations, an organization must still determine the right amount of information to share in order to accomplish the business goal. From a business or legal standpoint, an organization can encounter the following challenges that may complicate their ability to use technology to share information and services:

• Businesses are not prepared to deal with the consequences when sensitive information is disclosed or when access to services is unlawfully gained. Businesses may be aware of the consequences when information or services are compromised, but do not know how to protect themselves. Laws have begun to emerge in various countries around the protection of personal and financial information, but little has been defined around the protection of information between businesses.
• To complicate matters, an organization must share information with another organization in some situations where only a nominal amount of trust exists between the two. This requires an organization to carefully control access to its information based on its level of sensitivity.
• Due to a combination of these factors, an organization may have difficulty in justifying risking exposure of sensitive information or services to other organizations because of liability or loss.

Technology alone cannot address these real-world issues. Proper business policies and risk mitigation mechanisms must be in place to govern information sharing, and trust behavior and processes.

Key Concepts

Once these policies are in place, identity federation technology can then be applied to enforce trust and security policies that comply with corporate governance.

There are several key concepts that the reader should be familiar with before discussing how to secure information and services using technology:

• Authentication—The ability to positively identify a party presenting proof of their identity. Authentication is typically achieved by proving possession of a secret to the party performing the authentication.
• Credentials—Information about a party that is used to prove their identity.
• Authorization—Authorization is normally thought of as the process of making decisions about whether or not a resource can be accessed, based on known information about the party attempting to access the resource. A resource may make decisions about an authenticated party that determine whether or not it will allow something to happen; or the information about the authenticated party may represent decisions already made about what the authenticated party can or cannot do that a resource must abide by.
• Accounting (Auditing)—The process of attributing the activities within a system to the party responsible for them. The primary goal of accounting is keeping track of who's doing what at any given time. Accounting can take the form of an audit trail to track the activities of an authenticated party within a system, or it may be a mechanism to attribute a business transaction to a particular party.
• Security Domain—The logical or physical boundaries of an organization that define an area of trusted access and security administration.

Scenarios

Scenarios are an effective way of generalizing commonly encountered environments in which an identity federation may be required or implemented. The scenarios described here will be based on three fictitious companies, each representing a commonly encountered scenario that uses federated identity management.

Scenario 1: Merger and Acquisition: Litware Auto Parts

Litware Auto Parts controls a large chain of retail stores that sell auto parts. Litware has grown significantly over the past 12 months by acquiring smaller competitors. The acquired companies must be integrated with Litware's central point of sale reporting system, but they must operate independently using their own identity management infrastructures. Figure 1 depicts Litware's environment.

Figure 1. Litware Auto Parts environment (Click on the image for a larger picture)

Litware may face the following integration issues in their environment:

• Enabling single sign-on between the retail store and Litware's POS server.
• Some of the acquired companies have outdated identity management infrastructures compared to Litware's, and cannot be directly integrated. Others use a completely different identity management infrastructure that is not compatible with Litware's. The acquired companies could eventually be migrated to Litware's identity management infrastructure, but they must be able to authenticate to the point-of-sale server as soon as possible, in order not to disrupt operations. Litware must provide a solution to authenticate sales representatives from any of their stores to the central point of sale reporting system.
• The Internet connection between the retail stores and the corporate IT facility is not secure. Point-of-sale information must be protected from eavesdropping and tampering.
• The corporate point-of-sale system uses role-based security to enforce access and understands different role names than those that acquired companies have defined for their users. The role membership of the acquired company's users must be understandable to Litware's security domain, so that control can be maintained consistently across security domains over which users are allowed to do what.

Scenario 2: Business-to-Business: Trey Research

Trey Research is a research firm that provides research data to customers in a B2B environment. Customers send a research request to Trey Research, which processes the request and sends a response. Trey invoices its business partners monthly for the number of research responses it processes for that business. Trey Research must be able to track the identity of the individual user who was responsible for a transaction, for reporting purposes, but primarily it is concerned with the business to which that individual user belongs, in order to invoice transactions accurately. Also, different business partners have different limitations on the number of reports that they are able to submit, based on their service agreement with Trey research. Within each partner business, individual users have rights assigned that determine which types of research requests they are able to submit. Trey's research service application must be able to determine the monthly limit of each partner, in order to compare it with the number of requests it has already processed and notify the business partner when they have exceeded their monthly limit. Figure 2 depicts the environment in which Trey Research operates.

Figure 2. Trey Research environment (Click on the image for a larger picture)

Trey research faces several challenges in their environment:

• Trey Research must be able to attribute a request to the business partner that sent it, and maintain a record of the transaction.
• Trey Research must allow users to sign on using existing accounts from their own organization.
• The Internet connection between Trey Research and their business partners is not secure. Research requests and responses must be protected from eavesdropping and tampering.
• The Trey research service must be able to reliably determine the monthly transaction limit for a user, based on the business partner. The Trey research service depends on the partner business to provide information about the limitations on their respective users, in order to regulate how many and what kinds of requests they are allowed to make over a given period of time.

Scenario 3: Service Provider/Marketplace: Northwind Traders

Northwind Traders is a retail broker that facilitates collaboration between various organizations by providing integration between the applications used by retail partners, suppliers, and distributors. Northwind Traders handles message transformation, routing, and security between the various systems. Northwind Traders' client base is quite expansive, and competing organizations within each role of the origination process (suppliers, distributors, and retail partners) use Northwind Traders' services. Figure 3 depicts the environment in which Northwind Traders operates.

Figure 3. Northwind Traders environment (Click on the image for a larger picture)

Northwind Traders faces several challenges in their environment:

• Northwind Traders must be able to attribute a message to the organization that sent it, and maintain a record of the transaction, so that the appropriate organization can be billed.
• Role memberships defined for users in the various organizations must be understood by the Northwind Traders' service, in order to consistently enforce which users are allowed to do what.
• The Internet connection between Northwind Traders and retail partners is not secure. Customer financial information, such as a credit card number, is sensitive in nature, and requests and responses must be protected from eavesdropping and tampering.
• Northwind Traders must be able to communicate user and organization profile information, while retaining confidentiality of profile information that may be considered sensitive in nature to the organization's competitors—for example, the identity of the client, or capabilities of a specific user or organization.

Federation Scenario Patterns

The scenarios described above represent three distinct patterns of business environment where identity federation technology can help address the challenges and requirements:

• Internal Integration. This pattern is illustrated by the scenario for Litware Auto Parts, which acquired several smaller companies using disparate technologies that must interoperate with the corporate technology infrastructure.
• Business Peer-to-Peer. This pattern is illustrated by the Trey Research scenario, where one or more partner businesses consume services provided by a service organization. Partner businesses are not aware of one other in their interactions with Trey Research.
• Business Hub and Spoke. This pattern is illustrated by the Northwind Traders scenario, where several partner businesses collaborate through a central service provider.

Internal Integration

Figure 4. Internal integration pattern

As described above, this pattern represents the interaction of several autonomous units within a larger business, with a need for interoperability between the larger and smaller organizations in order to support day-to-day operations. In this case, the infrastructure of the smaller organizations may eventually be migrated to the parent's, or it may not—in either case, there is a need to interoperate across technologically disparate infrastructures within the same larger organization, and neither party can afford to wait until their infrastructures might or might not become integrated.

In a scenario where a smaller organization must federate with its larger parent organization, both parties face may face one or more the following challenges:

• Outdated/incompatible identity management infrastructures, requiring an adaptor layer between the two to establish a standard mechanism for authentication, authorization, and access control.
• The IT infrastructures of the larger and smaller companies may not enjoy the benefit of a secure connection, requiring sensitive data to be encrypted when in transit between the two.
• User roles may have different names within the larger and smaller organizations, requiring a means to translate or transform them so that they are understood from one organization to the other.
• Single sign-on when users in the smaller companies are accessing resources in the parent company.

Business Peer-to-Peer

Figure 5. Business peer-to-peer pattern

This pattern represents a direct relationship between two independent organizations. One of the organizations in the relationship typically represents a publisher of some sort of resource, such as a Web service. The resource publisher may have several partner organizations to which it provides access to the published resource, maintaining a discreet relationship with each partner. In a scenario where two organizations must federate in a peer-to-peer relationship, both parties may face one or more the following challenges:

• Often, the resource provider must be able to attribute a transaction, or access of a resource, to a specific partner organization, in such a way that if a dispute about a transaction arises, the resource provider must be able to prove that only the partner organization in question was capable of sending the message that caused the transaction to be attributed to them.
• The network connection between two peers is typically not secure. Information transmitted between the two may be sensitive in nature and require encryption to protect it from eavesdropping.
• The resource provider may need to recognize limits or restrictions set by partner organizations on their own users to access a resource. This provides internal controls to the partner organization, to prevent their users from exceeding any limits established through a service agreement between them and the resource provider to access a resource.
• Users from the business partner may want to log in using their home organization credentials, thus relieving them from having to manage multiple sets of login credentials.

Business Hub and Spoke

Figure 6. Business hub-and-spoke pattern

This pattern represents a complex relationship between two or more independent organizations, facilitated by a central service provider. Each of the organizations in the relationship may publish or consume a resource, such as a Web service, making it available to others within the relationship. The service provider may be recognized as a central authority for authenticating, routing, and orchestrating activity between the organizations. In a scenario where several organizations must federate in a hub-and-spoke relationship, each party may face one or more the following challenges:

• The central service provider may need to attribute activity to the party or parties responsible for it, for cost or regulation compliance purposes.
• Information about users, such as their role memberships, must be consistently understood by all parties involved in a transaction.
• The network connection between the participants of a hub-and-spoke federation is typically not secure. Information transmitted between parties may be sensitive in nature and require encryption to protect it from eavesdropping or disclosure from other members of the hub and spoke that are not part of the transaction.
• The central service provider may need to recognize limits or restrictions set by partner organizations on their own users to participate in a transaction for legal reasons, such as a license to operate within a certain geographical region, or to provision transaction limits against a service-level agreement with the central service provider. The limitations or restrictions are often communicated as profile information about the partner organization or specific user within the partner organization. Profile information may be sensitive in nature and require protection from disclosure, both during transmission across the network, and from other participants in the hub-and-spoke federation who may be competitors or who could use the information to unduly influence business with the partner organization.

Common Existing Practices

Several approaches have been devised to authenticate and authorize users across multiple organizations—many involve techniques such as delegated administration, directory synchronization across organizations, and proprietary schemes in vendor products. Historically, each of these approaches has been successful to some extent, with their own capabilities and limitations.

Delegated Administration

Delegated administration is where each organization receives its own allocated resources and space within a centralized identity management infrastructure. Users from each organization are provisioned within the centralized infrastructure by their respective organizations. While delegated administration may provide an effective identity management solution in some cases, there is still a dependency on the centralized infrastructure, and the organizations are not truly autonomous in managing their own users. Also, there may be legal implications of hosting sensitive identity data with other organizations within the same infrastructure. Figure 7 illustrates delegated administration of multiple organizations within a centralized security infrastructure:

Figure 7. Delegated administration (Click on the image for a larger picture)

As illustrated in the diagram above, each organization maintains its own users and groups under its own space in the security domain.

Directory Synchronization

Directory synchronization across organizations involves the periodic exchange of updates to identity data between two or more directory services. Directory synchronization can provide an effective solution for managing identities in many cases, and does support a scenario in which the participating members are completely autonomous from one another and not dependent on a centralized infrastructure. However, directory synchronization presents a set of its own challenges:

• Ownership of synchronized data. Parties synchronizing their directory information have to thoroughly define and carefully manage which party is the authoritative source for updates to synchronized data. If this process is not managed carefully, the wrong organization may be allowed to update data that they do not own during synchronization, or data may become out of sync between the directories.
• Exposure of sensitive directory information to other parties. Directory services may contain sensitive profile information about an organization's users that cannot be disclosed to parties participating in directory synchronization. This means that the data to be synchronized must be chosen carefully as not to unintentionally disclose the sensitive data to other parties.
• The amount of duplicated data across the domains of each organization increases significantly when more than two organizations are involved. This creates a significant overhead on the identity management infrastructure of each organization to redundantly maintain data owned by several other organizations.

Figure 8 illustrates simple directory synchronization:

Figure 8. Directory Synchronization (Click on the image for a larger picture)

As illustrated in figure 8, user information is exchanged and replicated between each organization that participates in synchronization.

The resulting disadvantages of delegated administration and directory synchronization are because in each case, the security domain of each organization is tightly coupled. For example, if the schema that defines what kind of information is stored about users ever changes in either organization, the other organization must compensate by making schema updates to match where the data received from synchronizing with the other organization is stored. As a result, changes to the shared infrastructure impact the infrastructure of each party, which is undesirable in most cases. Additionally, if more that two organizations participate in directory synchronization, the amount of directory data redundantly stored by each organization increases significantly. For example, if five organizations participate in directory synchronization with each other, each organization stores directory data for its own organization, plus synchronized data from the other four organizations.

Technology Requirements

In order to address the limitations of the previously described approaches, a solution that is implemented to securely exchange information and services between different organizations may have to satisfy one or more of the following requirements, based on the environment and circumstances of the organizations:

Interoperability between Heterogeneous Identity Infrastructures

Different organizations may leverage incompatible security technologies in their respective infrastructures, making the establishing of trust impossible without some sort of adaptor layer between the two. For example, one organization may host applications that use a proprietary authentication scheme that must communicate with services that require Windows authentication.

Minimize Technology Coupling Between Federated Domains

As described earlier in the disadvantages of delegated administration and directory synchronization, tight coupling of security domain infrastructures can undesirably impact the infrastructure of each organization. A solution for security across autonomous organizations must minimize the impact of changes to security infrastructure across all of the organizations involved.

Facilitate Reconciliation of Identity Namespaces Across Different Domains

Even when both organizations leverage the same technology to authenticate users within their respective infrastructures, the meaning of security roles that are defined for each organization may not be commonly defined. For example, one organization may identify one of its users as belonging to an administrative role, called "Administrators" within its domain. In another organization's security domain, the same role may be named "Admins." This presents a challenge when one organization attempts to identify the role memberships of a user from another security domain when performing authorization.

Facilitate Security Policy Discovery

Often times, a client application hosted by one organization must access a resource, such as Web service belonging to another organization, without prior knowledge of how that service expects clients to communicate securely with it.

Protect Sensitive User Profile Information

When several organizations are involved in a transaction, potentially sensitive information contained in user profiles may be shared across the organizations. User profiles either contain sensitive information that may be at risk of disclosure to eavesdroppers when being sent across the wire, or they would reveal information to the client about their capabilities and limitations when interacting with a resource. Since user profile information may pass through unsecured network environments, it must be protected from disclosure so that only the intended recipient of the user profile information may be able to use it.

Secure Resource Access

Sometimes the information being accessed from a service or another resource is sensitive in nature, requiring communication to be secured between a client and the resource it accesses to prevent sensitive information from being modified by or disclosed to unauthorized parties.

Federation: Conceptual Architecture

The model we want to focus on to solve the problem of establishing trust across organizations is commonly referred to as an identity federation. In order to understand the interaction between two or more organizations participating in an identity federation, let's take a closer look at the conceptual architecture of how a federation might work.

In political science, a Federation refers to a state comprising several partially self-governing regions, united by a central government. Identity federations are conceptually similar to their non-technical counterparts, with the following distinctions:

• The "regions," or domains, within an identity federation are commonly defined by the physical, network, and logical boundaries of a single organization's security infrastructure.
• Within an identity federation, the security infrastructures of different organizations are often autonomous, and are not necessarily united by a central organization.

Terms and Parties

Before we describe the process of federation, it's important to become familiar with some key concepts, terms, and parties commonly used to discuss an identity federation:

• Security Token—A set of claims about a party involved in a transaction that can be used for various purposes. Typically, a security token is used to identify and authenticate the party represented in the token. Different types of security tokens include different types of claims. Many security token types are defined by an established set of standards to provide an interoperable token format. For example, WS-Security defines the structure and use of the UsernameToken and binary security tokens, such as the KerberosToken and X509SecurityToken.
• (Security) Claims—Claims are statements about an authenticated party that are included with an issued security token. The type of claims included in a security token often depends on the type and purpose of the security token. Claims can be used for a variety of purposes, depending on their type. For example, a cryptographic key can be included as a claim to prove possession of a shared secret, or roles can be included to make authorization decisions about the party represented in the security token based on which roles they are a member of.
• Client—The client uses an application to access a resource controlled under a different security domain.
• Account Domain—The security domain in which the client has initially authenticated.
• Resource—The resource, such as a Web service, that the client is attempting to access.
• Resource Domain—The security domain where the resource resides that the client is attempting to access
• Security Token Service (STS)—An STS is the authority for token issuance within a given security domain. Although several STS's could function within a single domain, we will describe a federation model with only one STS per security domain for simplicity's sake. In our federation model, there are two STS's—one in the account domain, and one in the resource domain.

We will now illustrate the working principles of identity federation using a real world example of traveling abroad. If you wish to travel abroad, you would require a passport, because the border security of a country will not let you in or out without one. The local identification you receive in your home country, such as a driver's license, may not provide verifiable proof of your identity in another country, or may simply not be useable due to language differences. This raises the need for a common format for credentials that is accepted in several countries, which is represented by a passport. In order to obtain a passport to travel to other countries, you must first prove your identity with a birth certificate or other form of identification. Once you have proven your identity, and your local country has determined that you are not restricted from traveling for one reason or another, you are granted a passport. Some countries require you to obtain a visa in order to gain access to the country. A visa would provide the country you are visiting a means of specifying your activities or length of stay in the country so that they can have more granular visibility of your actions while in their country.

The same concept can be applied to identity federation using technology. In the electronic world, a client application accesses a resource in another domain to execute a business transaction or exchange information. In order to do so, the client application must be authorized to do so from its own security domain to prevent unwanted transactions from taking place, and obtain credentials that are useable in the security domain where the resource is located. The security domain where the resource is located not only controls access by validating credentials issued from another security domain, but also enforces control over which resources a client can access within the security domain. The resource domain may have an established policy of enforcing granular control over which resources that a client application can access, which requires clients to obtain an additional set of credentials from the security token service in the resource domain in order to access a specific resource.

Federation Process Flow

Now that we've established the key concepts and participants for our conceptual architecture, let's take a look at the process by which the participants interact within an identity federation. Figure 9 provides a high-level overview of the process:

Figure 9. Federation conceptual architecture process (Click on the image for a larger picture)

The steps in the process depicted in the figure 9 are detailed as follows:

1. Client Requests Security Token from Account Domain STS—In order to access the resource, the client must first obtain a security token from the STS in its domain to communicate with the resource domain. The client presents credentials to request a security token from its local STS in the account domain that will allow it to communicate with the resource domain STS.
2. Account Domain STS Issues a Security Token to the Client—The Account Domain STS verifies the credentials presented by the client, and issues a security token to the client so that it can communicate with the resource domain STS. The account domain STS may include claims in the issued security token to facilitate authorization or secure communication between the Client and the Resource Domain STS
3. Client Requests A Security Token from the Resource Domain STS—The client uses the security token issued by the account domain STS to obtain a security token from the Resource Domain STS that will allow it to access the resource within the resource domain.
4. Resource Domain STS Issues a Security Token to the Client—The Resource Domain STS validates the security token presented by the client, and verifies that the Account Domain STS, as the issuer of the token presented by the client, is a trusted member of the federation. The Resource Domain STS may copy claims from the security token presented by the client into the token it issues, or it may transform them into different claims so that they can be understood in the resource domain. Like the Account Domain STS, the Resource Domain STS may also include additional claims in the token it issues to the client to facilitate authorization or secure communication between the Client and the Resource.
5. Client Sends A Request to the Resource—The client sends a request to the resource, using the security token issued by the Resource Domain STS to authenticate with the resource. The client may also use the security token to do other things, such as establish secure communications when accessing the resource.
6. Resource Processes the Request and Sends a Response to the Client—The resource validates the security token presented by the client and processes the request. If the client expects a response, the resource sends a response.

Advantages

The key advantages to this model of federation are:

• Loose coupling between federation members—In a loosely coupled model, trusted members of the federation are established through policy on each STS. Since trust is established through the STS in each security domain, it eliminates the need to directly establish trust between resources and users in the different domains. Also, unlike tightly coupled federation models such as directory synchronization, infrastructure modifications such as directory schema updates are typically avoidable by using a loosely coupled approach.
• Scalability—This federation model relies on the client to understand the process of requesting and obtaining security tokens from the required STS's in the federation to access a resource in a federated domain. This means that each participating system in the federation only has to understand a single security protocol rather than modifying the service to accommodate every security protocol that a potential client may use.

Federation Patterns

In addition to the conceptual model described previously, common patterns can be identified to establish solutions to common requirements for identity federation:

Secure Communications Bootstrapping

Secure communications bootstrapping is the ability to use an issued security token to negotiate secure communications between two parties. If the two parties attempting to communicate with each other are incapable of directly establishing secure communications with each other, an STS can be used to generate a session key and provide a secure copy of the key to each participant in the communication. Figure 10 illustrates the process of secure communications bootstrapping using an STS:

Figure 10. Secure communications bootstrapping (Click on the image for a larger picture)

This process can be summarized in the following steps:

1. The client requests a security token from an STS.
2. The STS authenticates the client and issues a security token. The issued security token includes an encrypted session key, which is decipherable only by the resource. Another copy of the session key is provided by the token issuer to the client. The client's session key is provided in a proof token, as the copy of the session key included in the issued security token is only decipherable by the resource.
3. The client attaches the issued security token in a request to the resource, using its copy of the session key from the proof token to encrypt and sign the message. The initial communication that takes place between two parties to establish secure communications is often referred to as a security handshake.
4. The resource uses the encrypted session key sent by the client in the security token to decrypt the message and verify its signature. The resource then uses the decrypted session key to secure a response to the client.

Secure communications bootstrapping resolves the challenge of initiating secure communications between federation members across an insecure network connection.

Claims Protection

Claims protection is the ability to encrypt identity information within an issued security token to prevent disclosure to unauthorized parties. A token issuer may wish to protect claims within an issued security token for a variety of reasons. For example, an issued security token may contain profile information about the authenticated party that is sensitive in nature. The profile information may need to be protected from disclosure to eavesdroppers or unauthorized parties. A token issuer may not wish to reveal to the party that requested the security token any information about their capabilities or limitations that the issued security token provides them.

Claims Transformation

Claims transformation is the process of modifying claims within a security token so that they can be used in a different domain to make security and access control decisions. For security token issuance, claims transformation would take place when a token issuer analyzes claims presented in a request for a security token, adds and/or modifies claims in an issued security token so that they can be understood in the security domain where the issued security token is valid.

Two examples of claims transformation are role mapping and computation of authorization decisions. For example, role mapping between different identity domain namespaces would be performed by an STS if a user belongs to an administrative role within one domain, expressed as a membership to the "Admin" role, that same information must be conveyed in an issued security token so that it is understood by the consumer of that security token. If the same role is understood in the token consumer's security domain to be "Administrators," then the token issuer can include a claim in the issued security token indicating that the authenticated party belongs to the "Administrators" role. In addition, the STS can provide the endpoint consumer of an issued security token with explicit authorization decisions based on information about the authenticated party when it is evaluated against an access control policy. For example, a resource domain STS may have a policy that states only users belonging to a Purchasing role are authorized to call a purchasing web service in another security domain. Rather than attempting to enforce the policy within each individual client application, the decision is made by the STS and passed to the client application to make authorization decisions about resource access.

Existing Federation Technologies

There are several security infrastructure technologies that can be leveraged to implement identity federation. Some of the major ones seen recently, either in deployment or development, are Active Directory cross forest trust feature, ADFS, and SAML.

Active Directory Cross Forest Trust

Microsoft Active Directory provides the capability to establish an identity federation between domain controllers by supporting the establishment of a cross forest trust, which can be leveraged to provide a variety of security capabilities within a federation:

• Single sign-on
• Role management
• Impersonation
• Delegation

However, the AD cross forest trust feature requires federating organizations to have deployed Windows Server 2003 domain controllers in their infrastructure and set up virtual private network connections—a requirement and task that have major security implications to each organization.

Active Directory Federation Service (ADFS)

ADFS is a component of Windows Server that provides interoperable single sign-on and identity claims propagation within an enterprise and across organizational boundaries. ADFS provides an interoperable security federation solution through WS-Federation. However, ADFS currently supports passive client federation. While this reduces coupling between security domains, it does not provide support for active clients.

Security Assertion Markup Language (SAML)

SAML itself is not a product, but rather defines a standard schema for security tokens and the message definitions used to handle security tokens for token request, issuance, extension, termination and verification. SAML is leveraged in many commercial products and in custom implementations, sometimes in conjunction with WS-Trust as the defining standard for token messages, while using the SAML assertion schema to define the security tokens themselves. SAML provides a flexible and extensible model for security claims propagation, but understanding of claims within a SAML token sometimes depends on the implementation because of that flexibility.

Proprietary Solutions

Proprietary schemes were especially popular with vendors before standards had begun to be defined around identity federations. Proprietary schemes vary in their quality and capabilities, but generally do not provide an interoperable means of establishing an identity federation between different organizations without having to cater to the proprietary scheme.

Solution Scenario and Requirements

To illustrate how an identity federation solution can be implemented, we'll first describe a scenario and its requirements.

Our scenario is modeled after the Business Peer To Peer federation pattern, representing a partner business hosting a client application and a Web service publisher hosting a Web service as the resource to be accessed by the client. We've used two fictitious organizations to represent our partner business and Web service publisher. Contoso represents the partner business, hosting the client application and account domain STS, and Fabrikam represents our Web service publisher, hosting the resource domain STS and the Web service to be accessed by the client.

The users of the Contoso client application are buyers that purchase various items from Fabrikam through their Web service. The Contoso STS makes authorization decisions about authenticated users of the client application based on their role membership. In this case, the Contoso STS includes an authorization decision statement in security tokens that it issues to the Contoso client application. The authorization decision determines whether or not an authenticated user is allowed to purchase items from Fabrikam through the Contoso client application. Additionally, Contoso has a Service Level Agreement (SLA) with Fabrikam that specifies how much can be purchased by Contoso users through the Web service. The SLA is centrally administered so that the STS at Fabrikam can enforce the purchasing limit of Contoso users by issuing security tokens that include a Contoso buyer's purchasing limit to the Web service.

The information passed between the Contoso client application and the Fabrikam purchasing Web service is sensitive to all parties involved, and must be protected from disclosure and tampering from eavesdroppers. In order to satisfy this requirement, the STS of each security domain is capable of facilitating secure communications between Contoso's client application and Fabrikam's service. To accomplish this, the Fabrikam STS includes an encrypted session key in the security tokens that it issues that can be used to encrypt and sign messages between the Contoso client application and Fabrikam service.

The purchasing limit of the Contoso users is also sensitive in nature and must be protected from eavesdroppers. To protect sensitive user information in issued security tokens, each STS is capable of encrypting the security tokens it issues with the intended recipient's X.509 public key, so that only the intended recipient of the security token (such as the Fabrikam STS) is capable of deciphering it.

Figure 11 depicts the solution within the context of the Business Peer To Peer scenario between Contoso & Fabrikam:

Figure 11. Solution Diagram (Click on the image for a larger picture)

Note that trust between the Contoso and Fabrikam domains is established through their respective Security Token Services.

Solution Technology

Based on the most recent web service technology for the .NET platform in release at the time of this writing, we have implemented a federation sample using Microsoft Web Service Enhancements (WSE) 3.0. We used the STS quickstart code, available from Microsoft Patterns and Practices as a starting point for our implementation. The code for our federation implementation can be used as a reference to supplement the description of the solution architecture, and is available here.

For versatility and interoperability, we chose the SAML v1.1 assertion as our security token type. The solution uses the custom security policy and security token manager custom classes extensibility points in the WSE 3.0 architecture to provide the functionality for requesting and validating SAML tokens.

Additionally, the STS's use a custom security token service class to implement token issuance, claims protection and claims transformation. X.509 certificates are used by the STS's to provide encryption and signing of issued security tokens. Each STS must have an X.509 certificate installed in its local machine certificate store for each of the endpoints for which it can issue a token to a client.

Solution Implementation

Let's take a look at the software components of our solution and explain them as they relate to our solution architecture. The major components of the solution are based on the WSE 3.0 security model to perform specific functions:

Security Token Managers

The Security Token Services and the Fabrikam web service use implementations of the WSE 3.0 SecurityTokenManager class to validate credentials presented by the Contoso client application during each request.

Security Policy Assertions

All systems in the scenario use extensions of the WSE 3.0 SecurityPolicyAssertion class to facilitate the enforcement of security policy on outbound messages, and to facilitate the validation of incoming messages against an established security policy.

Security Token Services

The Contoso and Fabrikam Security Token Services use extensions of the WSE 3.0 SecurityTokenService class for token issuance functionality.

Below are some key points about the solution architecture that describe which classes are responsible for which actions in the federation:

Contoso Client

• The client uses the SamlTokenServiceClient class from the SamlAssertion assembly to request a security token from the account domain STS, presenting a UsernameToken in a WS-Trust Request Security Token (RST) message for authentication.
• The client uses the SamlPolicyAssertion class, located in the SamlAssertion assembly to secure communications between the resource domain STS and the service. The policy assertion uses an issued SAML token to enforce security policy by encrypting and signing outbound messages, and verifies compliance with the security policy on inbound messages.

Contoso STS

• The account domain STS uses the default UsernameTokenManager implementation in WSE 3.0 to validate the credentials presented in the RST using Windows Authentication. The account domain STS adds claims to the security token based on the role memberships of the identity provided by the client for authentication.
• The Contoso STS uses AzMan to manage the specific tasks that an authenticated user is authorized to perform, and includes them in SAML tokens that it issues to the Contoso Client application.
• The account domain STS uses a custom security token service implementation, the SamlTokenService class, to construct and issue a SAML token to the client. The SAML token implementation classes reside in the SamlAssertion assembly.

Fabrikam STS

• The resource domain STS uses a SamlPolicyAssertion custom policy assertion class located in the SamlAssertion assembly, and a custom SecurityTokenManager local class, called FabrikamSamlTokenManager, to validate the SAML token presented by a client during a request for a security token to access a resource within the resource domain.
• Like the Contoso STS, the Fabrikam STS uses the custom SamlTokenService class to create and issue a SAML token to a client. However, unlike the Contoso STS, the Fabrikam STS also adds a claim to the security tokens it issues to provide the purchasing limit for the authenticate party.
• The Fabrikam STS adds a claim to the issued security token to control the spending limit of the authenticated user within the web service. The spending limit included in the issued SAML token is determined by the account domain. The spending limit as added as an attribute statement to the issued SAML token.

Fabrikam Service

• Like the resource domain STS, the service also uses the SamlPolicyAssertion custom policy assertion class located in the SamlAssertion assembly to validate the SAML token presented by the client. The service uses the SamlTokenManager custom security token manager class located in the SamlAssertion assembly to process the purchasing limit claim included in the security token issued by the Contoso STS.
• The Fabrikam Service uses the purchase limit claim included in the token issued to determine if the purchase can take place, providing that the purchase amount does not exceed the limit specified in the issued SAML token.

Figure 12 illustrates the deployment of the key components described above on the various systems in the federation and how they interact with one another:

Figure 12. Component Deployment (Click on the image for a larger picture)

Solution Configuration

There are several configuration settings on the client, account domain STS, resource domain STS and service that control its behavior when participating within the federation. The policy configuration file on each host contains configuration settings for message layer security when communicating with other parties in the federation. Policy configuration files contained well-formed XML, but should be named with a file suffix other than .xml that does not allow it to be browsed if it is hosted on a web server. Specifically, the policy configuration file contains encryption and signing configuration, and identifies the STS from which to request a security token in order to communicate with a specific party. For example, the client samlPolicy.config file identifies the security policy requirements to communicate with the Fabrikam STS, and identifies the Contoso STS as a valid token issuer from which to request a security token to communicate with the Fabrikam STS.

Additionally, each STS uses custom settings in its web.config file to configure X.509 certificate mappings and token issuance behavior.

Client

The client contains policy settings in its samlPolicy.config file to communicate with the service, resource domain STS, and account domain STS, respectively. The following XML sample provides an example of the Contoso Client's samlPolicy.config file:

<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">
   <extensions>
      <extension name="saml" type=
"Microsoft.Practices.WSSP.WSE3.QuickStart.SamlAssertion.SamlPolicyAssertion,
Microsoft.Practices.WSSP.WSE3.QuickStart.SamlAssertion"/>
   </extensions>

   <policy name="PurchaseGoods">
      <saml issuer="http://localhost/FabrikamSTS/SamlTokenIssuer.ashx" 
issuerPolicy="FabrikamSTS" establishSecurityContext="true" 
renewExpiredSecurityContext="true" requireDerivedKeys="true">
         <protection>
            <request signatureOptions="IncludeAddressing, 
IncludeTimestamp, IncludeSoapBody" encryptBody="true" />
            <response signatureOptions="IncludeAddressing, 
IncludeTimestamp, IncludeSoapBody" encryptBody="true" />
            <fault signatureOptions="IncludeAddressing, 
IncludeTimestamp, IncludeSoapBody" encryptBody="false" />
         </protection>
      </saml>
   </policy>

   <policy name="FabrikamSTS">
      <saml issuer="http://localhost/ContosoSTS/SamlTokenIssuer.ashx" 
issuerPolicy="ContosoSTS" establishSecurityContext="true" 
renewExpiredSecurityContext="true" requireDerivedKeys="true">
         <protection>
            <request signatureOptions="IncludeAddressing, 
IncludeTimestamp, IncludeSoapBody" encryptBody="true" />
            <response signatureOptions="IncludeAddressing,
 IncludeTimestamp, IncludeSoapBody" encryptBody="true" />
            <fault signatureOptions="IncludeAddressing, 
IncludeTimestamp, IncludeSoapBody" encryptBody="false" />
         </protection>
      </saml>
   </policy>
   
   <policy name="ContosoSTS">
      <usernameForCertificateSecurity establishSecurityContext="true" 
renewExpiredSecurityContext="true" requireSignatureConfirmation="false" 
messageProtectionOrder="SignBeforeEncryptAndEncryptSignature" 
requireDerivedKeys="true">
         <clientToken>
          <username username="WSEFederationUser" password="Password1234" />
         </clientToken>
         <serviceToken>
            <x509 storeLocation="LocalMachine" storeName="My" 
findValue="CN=ContosoSTS" findType="FindBySubjectDistinguishedName" />
         </serviceToken>
        <protection>
         <request signatureOptions="IncludeSoapBody" encryptBody="true" />
         <response signatureOptions="IncludeSoapBody" encryptBody="true" />
         <fault signatureOptions="IncludeSoapBody" encryptBody="false" />
        </protection>
      </usernameForCertificateSecurity>
   </policy>
</policies>

The relevant items in the samlPolicy.config file are described in the following list:

• The <PurchaseGoods> policy contains configuration settings to communicate with the service. The settings specify the behavior of the SAML policy assertion within the <saml> element. The issuer attribute specifies the URI of the resource domain STS from which the client must request a security token to communicate with the service. The issuerPolicy attribute contains the name of a policy declaration on the client that is applied when requesting a security token and processing the response from an STS.
• The <FabrikamSTS> policy contains configuration settings for the security policy that is applied when the Contoso client communicates with the Fabrikam STS. This policy also uses the SAML policy assertion, with the STS specified in the issuer attribute of this policy as the Contoso STS, since the client must first obtain a SAML token from the Contoso STS in order to communicate with the Fabrikam STS. The issuerPolicy attribute is set to the policy that the client must use in order to communicate with the account domain STS.
• The <ContosoSTS> policy contains configuration settings to communicate with the account domain STS. This policy uses the usernameForCertificateAssertion WSE turnkey policy assertion to present a UsernameToken secured by an X.509 certificate when the client requests a security token from the account domain STS. The X.509 certificate specified in the policy assertion is for the account domain STS, which must be installed in the client's machine certificate store.
• Note that for demonstration purposes only that the <clientToken> has been specified under the <ContosoSTS> policy. Normally, you would collect the user credentials at runtime for authentication.

Contoso STS

There are a series of settings in the Contoso STS's web.config file under the <WseSaml> configuration section that control its behavior when it issues tokens. The following XML sample provides an example of the relevant configuration information from the Contoso STS's web.config file. Other sections of the file have been omitted as indicated by elipses (...) for brevity:

<configuration>
...
  <WseSaml>
<samlTokenIssuer allowCachingToken="true" ttlInSeconds="300" 
encryptToken="true">
      <!-- the config for the saml token issuer, this is the only config we 
use. This token is used to sign the SAML token -->
      <serviceTokens>
        <!-- SAML Authority certificate -->
        <add uri="http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue/SAML"
storeLocation="LocalMachine" storeName="My" findValue="CN=ContosoSTS" 
findType="FindBySubjectDistinguishedName" />
        <!-- Fabrikam STS -->
        <add uri="http://localhost/FabrikamSTS/SamlTokenIssuer.ashx" 
storeLocation="LocalMachine" storeName="My" findValue="CN=FabrikamSTS" 
findType="FindBySubjectDistinguishedName" />
      </serviceTokens>
      <policy name="ContosoSTS">
      </policy>
    </samlTokenIssuer>
  </WseSaml>
</configuration>

• The <samlTokenIssuer> element specifies characteristics of the token issued by the STS:
  • In some cases, the SAML tokens issued by an STS should only be good for one use only and should not be cacheable on a client. To control this behavior, the allowTokenCaching attribute specifies whether the token is cacheable on the client. This is expressed in a DoNotCacheCondition element in the issued SAML token.
  • As a security best practice, you should not issue SAML tokens that are valid for an indefinite period of time. To control the length of time for which an issued SAML token is valid, the ttlInSeconds attribute can be specified to provide a validity period for issued SAML tokens.
  • The encryptToken attribute can be set to true when sensitive claims are included in the token that must be protected. This will encrypt the token so that only the intended consumer of the token is capable of decrypting it.
• The <serviceTokens> element contains a series of mappings to X.509 certificates in the STS's machine certificate store. The mapped X.509 certificates are used for different purposes, depending on the endpoint URI in the mapping. One of the mappings represents the STS as the token issuer. The certificate mapped to the STS's endpoint URI is used to sign the security tokens that it issues, so that the party verifying the token has assurance that the token has not been tampered with, and ties the token to the identity of the issuing STS. Other mappings are based on the endpoint URI that the client passes in its request to the STS to identify the party for whom it wishes to obtain a valid security token. The X.509 certificates that are mapped to endpoint URIs besides the STS are used to encrypt the session key included in the issued token for secure communication bootstrapping, as well as encrypting the entire token if the STS is configured to do so by setting the encryptToken attribute to true.
• The <policy> element is used to specify the name of the policy configuration, located in the account domain STS's policy cache configuration file, samlPolicy.config, that is enforced when a client requests a security token from the STS.

Fabrikam STS

Having obtained a token to communicate with the resource domain, the client then uses the SamlTokenServiceClient to request a security token from the Fabrikam STS. The Fabrikam STS has similar behavior and configuration as the Contoso STS, with the following exceptions:

• When a client requests a security token to access a resource, the resource domain STS expects the client to present a SAML token issued by the account domain STS instead of a UsernameToken. To validate the SAML token, the <saml> policy configuration element in the samlPolicy.config file on the resource domain STS contains a list of trusted token issuers, contained within a <trustedTokenIssuers> element. Each entry in the list represents a mapping from the URI of the token issuer to the corresponding X.509 certificate that is used to verify the token. A mapping for the account domain STS must be present in the <trustedTokenIssuers> element, and the corresponding X.509 certificate for the account domain STS must be installed in the machine certificate store on the resource domain STS.

Fabrikam Service

Like the Fabrikam STS, the service uses settings defined in the <saml> policy configuration in its samlPolicy.config file to specify trusted token issuers.

• The service is configured to only accept requests from the client that have been secured using a token issued by the resource domain STS. The service must have the X.509 certificate specified under the <trustedTokenIssuers> element for the resource domain STS installed in its local certificate store.
• The samlPolicy.config file on the service also contains a <samlAuthorization> assertion element to control authorization based on the authorization decision statements included in a SAML token presented by the client.

Conclusion

Using technology to securely exchange information and consume services between different organizations can be a challenging task. The right identity federation solution for your scenario must address both business and technical requirements in a way that minimizes organizational coupling and dependencies while maximizing interoperability and security. To help you identify challenges and requirements specific to your environment, we've described common scenarios and patterns. We have used the more common elements of the scenarios that we described to create a solution for addressing the identified requirements.

Our solution approach is based on a conceptual architecture model that mirrors the real world example of how trust and identification is established in cross country travel with a passport. We then illustrate that the model can be implemented with currently shipping WSE 3.0 technology.

We believe that our trust-based solution has several merits:

• It is able to capitalize on the business trust relationships that must exist prior to technological collaboration between organizations.
• It interoperates with other systems through Web-services security and federation standards.
• It enhances organizational agility through the use of:
  • Standard based policy mechanism, which drives application security interactions and behavior.
  • Security token services that act as the trust and namespace anchor points between applications and external identities.

We hope that this paper, along with the scenario implementation, will help jumpstart the solution you need for securing your interactions with your business partners.