Export (0) Print
Expand All
1 out of 2 rated this helpful - Rate this topic

Partner organizations

Updated: August 22, 2005

Applies To: Windows Server 2003 R2

When you plan for cross-organizational (federation-based) collaboration using Active Directory Federation Services (ADFS), 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 ADFS, and it is fundamental in the planning of your ADFS infrastructure.

For Federation scenarios such as Federated Web Single Sign-On (SSO) and Federated Web SSO with Forest Trust (but not the Web SSO scenario), ADFS 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 trusts" is used in ADFS to characterize the one-way, nontransitive relationship that is established between the account partner and the resource partner.

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 store or an Active Directory Application Mode (ADAM) 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 to access 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 Active Directory, the account partner in ADFS is conceptually equivalent to a single Active Directory 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.

noteNote
This analogy is meant strictly to emphasize how the relationship between account and partner organizations in ADFS is similar, in concept, to the relationship between an account forest and a resource forest in Active Directory. External trusts and forest trusts are not required for ADFS 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:

  • 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 where the 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 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 Web servers that are located in the resource partner.

To function as an ADFS resource, Web servers in the resource partner organization must have the ADFS Web Agent component of ADFS installed. Web servers that function as an ADFS resource can host either claims-aware applications or Windows NT token-based applications. For more information about the two types of applications, see Controlling Access to Web-based Applications.

noteNote
If the application that is hosted on the Web server is a Windows NT token–based application, a resource account may be required for the Active Directory forest in the resource partner organization.

In relation to Active Directory, 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.

noteNote
This analogy is meant strictly to emphasize how the relationship between account and partner organizations in ADFS is similar, in concept, to the relationship between an account forest and a resource forest in Active Directory. External trusts and forest trusts are not required for ADFS 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 a 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 can be configured 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.

How enhanced identity privacy works

If the Enable enhanced identity privacy setting is enabled, the user’s identity is transformed by the account Federation Service before it is sent to the resource realm. The account Federation Service does this by hashing a combination of the privacy key (for salting), the resource partner Uniform Resource Identifier (URI), and the identity claim itself. Therefore, the resulting transformed identity will be the same when the following values are the same:

  • Privacy key

  • Resource partner URI

  • Identity claim (UPN or e-mail)

The hashing algorithm is case sensitive. Therefore, the hashed results are different if the case of the URI or the user-name portion of the UPN claim or e-mail claim is different.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.