When you plan for cross-organizational (federation-based) collaboration using Active Directory Federation Services (AD FS), you first determine whether your organization will host a Web resource to be accessed by other organizations across the Internet—or the reverse. This determination affects how you deploy AD FS, and it is fundamental in the planning of your AD FS infrastructure.
For federation designs such as Federated Web Single Sign-On (SSO) and Federated Web SSO with Forest Trust (but not the Web SSO design), AD FS uses terms such as "account partner" and "resource partner" to help differentiate the organization that hosts the accounts (the account partner) from the organization that hosts the Web-based resources (the resource partner). The term "federation trust" is used in AD FS to characterize the one-way, nontransitive relationship that is established between the account partner and the resource partner.
For more information about AD FS designs, see Understanding Federation Designs.
The following sections explain some of the concepts that are related to account partners and resource partners.
Account partner
An account partner represents the organization in the federation trust relationship that physically stores user accounts in either an Active Directory Domain Services (AD DS) store or an Active Directory Lightweight Directory Services (AD LDS) store. The account partner is responsible for collecting and authenticating a user's credentials, building up claims for that user, and packaging the claims into security tokens. These tokens can then be presented across a federation trust for access to Web-based resources that are located in the resource partner organization.
In other words, an account partner represents the organization for whose users the account-side Federation Service issues security tokens. The Federation Service in the account partner organization authenticates local users and creates security tokens that are used by the resource partner in making authorization decisions.
In relation to AD DS, the account partner in AD FS is conceptually equivalent to a single AD DS forest whose accounts need access to resources that are physically located in another forest. Accounts in this example forest can access resources in the resource forest only when an external trust or forest trust relationship exists between the two forests and the resources to which the users are trying to gain access have been set with the proper authorization permissions.
 | Note |
|
This analogy is meant strictly to emphasize how the relationship between account and partner organizations in AD FS is similar, in concept, to the relationship between an account forest and a resource forest in AD DS. External trusts and forest trusts are not required for AD FS to function. |
Producing claims that go to the resource partner
A claim is a statement that a server makes (for example, name, identity, key, group, privilege, or capability) about a client. An account partner produces claims that the resource partner Federation Service consumes. The following list describes the different types of claims that can be configured in the account partner on the resource federation server side:
-
UPN claim
When you configure the account partner, you can specify a list of user principal name (UPN) domains and suffixes that may be accepted from the account partner. If a UPN identity is received whose domain part is not in the list, the request is rejected.
-
E-mail claim
When you configure the account partner, you can specify a list of e-mail domains and suffixes that may be accepted from the account partner. As with the UPN claim, if an e-mail identity is received whose domain part is not in the list, the request is rejected.
-
Common name claim
When you configure the account partner, you can specify whether common name claims can be received from the account partner. This type of claim may not be mapped; it is simply passed through if it is enabled.
-
Group claims
When you configure the account partner, you can specify a set of incoming group claims that may be accepted from the partner. You can then associate each possible incoming group with an organization group claim. Note that this creates a group mapping. If an incoming group is encountered that has no mapping, it is discarded.
-
Custom claims
When you configure the account partner, you can specify a set of incoming names of custom claims that are accepted from the partner. You can then map each possible incoming name to an organization custom claim. Note that this creates a name mapping. If an incoming custom claim is encountered that has no mapping, it is discarded.
Resource partner
A resource partner is the second organizational partner in the federation trust relationship. A resource partner is the organization where the AD FS-enabled Web servers that host one or more Web-based applications (the resources) reside. The resource partner trusts the account partner to authenticate users. Therefore, to make authorization decisions, the resource partner consumes the claims that are packaged in security tokens coming from users in the account partner.
In other words, a resource partner represents the organization whose AD FS-enabled Web servers are protected by the resource-side Federation Service. The Federation Service at the resource partner uses the security tokens that are produced by the account partner to make authorization decisions for AD FS-enabled Web servers that are located in the resource partner.
To function as an AD FS resource, an AD FS-enabled Web server in the resource partner organization must have the AD FS Web Agent component of AD FS installed. Web servers that function as an AD FS resource can host either claims-aware applications or Windows NT token–based applications.
| Note |
|
If the application that is hosted on the AD FS-enabled Web server is a Windows NT token–based application, a resource account may be required for the AD DS forest in the resource partner organization. |
In relation to AD DS, the resource partner is conceptually equivalent to a single forest whose resources are made available over an external trust or forest trust relationship to accounts that are physically stored in another forest.
| Note |
|
This analogy is meant strictly to emphasize how the relationship between account and partner organizations in AD FS is similar, in concept, to the relationship between an account forest and a resource forest in AD DS. External trusts and forest trusts are not required for AD FS to function. |
Consuming claims that come from the account partner
A resource partner consumes claims that the account partner Federation Service produces and packages in security tokens. The following list describes how claims can be sent to the resource partner:
-
UPN claim
When you configure the resource partner, you can specify whether a UPN claim is to be sent to the resource partner. You can also specify a suffix mapping so that any suffix is mapped into a specified outgoing suffix. For example, julianp@sales.tailspintoys.com can be mapped to julianp@tailspintoys.com. Note that only one outgoing suffix may be specified.
-
E-mail claim
When you configure the resource partner, you can specify whether an e-mail claim is to be sent to the resource partner. You can also specify a suffix mapping so that any suffix is mapped into a specified suffix. For example, vernettep@sales.tailspintoys.com can be mapped to vernettep@tailspintoys.com. Note that only one outgoing suffix may be specified.
-
Common name claim
When you configure the resource partner, you can specify whether common name claims can be sent to the resource partner. This type of claim may not be mapped; it is simply passed through to the resource partner if it is enabled.
-
Group claims
When you configure the resource partner, you can specify a set of outgoing group claims that will be accepted by the resource partner. You can then associate each possible outgoing group claim to organization group claims. Note that this creates a set of group mappings. Organization group claims that do not match an outgoing group claim are not created.
-
Custom claims
When you configure the resource partner, you can specify a set of outgoing custom claims that are accepted by the resource partner. You can map each possible outgoing custom claim to an organization custom claim. Note that this creates a set of name mappings. Organization custom claims that do not match an outgoing custom claim are not created.
Enhanced identity privacy
Enhanced identity privacy is an optional setting that you can configure on a resource partner in the trust policy. If the Enhanced identity privacy option is enabled, this setting hashes the user-name portion of outgoing UPN claims and e-mail claims. It substitutes the common name with a random value.
The purpose of this feature is to prevent:
-
The resource partner from correlating identity claims to personally identifiable user information.
-
Collusion between partners in correlating identity claims to personally identifiable user information. This setting creates a unique hash per partner so that identity claim values are different across different trusting realm partners but consistent across sessions for a single partner.
-
Simple dictionary attacks against the hash by "salting" the user value with data that is in the trust policy—data that is not known by the resource partners.