Understanding Federation

Applies to: Exchange Server 2010

Information workers frequently need to collaborate with external recipients such as vendors, partners, and customers, and share their availability (free/busy) information, calendar, or contacts. Microsoft Exchange Server 2010 provides easy sharing of information with external recipients. Federation provides the underlying trust infrastructure to enable easy and secure sharing of information across Exchange organizations and in cross-premises organizations.

In Exchange 2010, federation is used for federated sharing, which allows easy sharing of availability information, calendar, and contacts with recipients in external federated organizations. For more information about federated sharing, see Understanding Federated Sharing.

Looking for management tasks related to federation? See Managing Federation.

Contents

Microsoft Federation Gateway

Federation Trust

Federated Organization Identifier

Certificate Requirements for Federation

Transitioning to a New Certificate

Microsoft Federation Gateway

Exchange 2010 uses the Microsoft Federation Gateway, an identity service that runs in the cloud (over the Internet and beyond your corporate network domain), as the trust broker. Exchange organizations wanting to use federation establish a federation trust with the Microsoft Federation Gateway, allowing it to become a federation partner to the Exchange organization. The trust allows users authenticated by Active Directory (known as the identity providers) to be issued Security Assertion Markup Language (SAML) delegation tokens by the Microsoft Federation Gateway. These tokens allow users from one federated organization to be trusted by another federated organization. With the Microsoft Federation Gateway acting as the trust broker, organizations aren't required to establish multiple individual trust relationships with other organizations. Users can access external resources using a single sign-on (SSO) experience. For more information, see Microsoft Federation Gateway.

Return to top

Federation Trust

To use Exchange 2010 federation, you must establish a federation trust between your Exchange 2010 organization and the Microsoft Federation Gateway by exchanging your organization's certificate with the Microsoft Federation Gateway, and retrieving the Microsoft Federation Gateway certificate and federation metadata. You can establish a federation trust by using the New Federation Trust wizard in the Exchange Management Console (EMC) or the New-FederationTrust cmdlet in the Exchange Management Shell. The certificate is used for signing and encrypting tokens. For details about certificate requirements, see Certificate Requirements for Federation later in this topic.

For details about creating a federation trust, see Create a Federation Trust.

When you create a federation trust with the Microsoft Federation Gateway, an application identifier (AppID) is generated for your Exchange organization and provided in the output of the New Federation Trust wizard or the New-FederationTrust cmdlet. The AppID is used by the Microsoft Federation Gateway to identify your Exchange organization. It's also used by the Exchange organization to provide proof of ownership of the registered domains being federated. This is done by creating a TXT resource record in the Domain Name System (DNS) zone of each federated domain.

For details about creating the DNS resource record, see Create a TXT Record for Federation.

Return to top

Federated Organization Identifier

The federated organization identifier defines which of the authoritative accepted domains configured in the Exchange organization are enabled for federation. Only recipients that have e-mail addresses with accepted domains configured in the organization identifier are recognized by the Microsoft Federation Gateway and can use features such as federated sharing. When you configure the organization identifier, an account namespace is created with the Microsoft Federation Gateway using the first accepted domain added to it. We recommend that you use the organization's primary domain name, which is the domain name used to generate e-mail addresses for most users, as the account namespace.

You can add or remove additional accepted domains at any time, and the domain used for the account namespace can be changed if required. You can disable or enable the organization identifier to disable or enable all federation features for the Exchange organization in a single step.

For more information about configuring the federated organization identifier, see Manage Federation.

After you create a federation trust with the Microsoft Federation Gateway, create TXT records for all accepted domains you want to use for federation. Then configure the organization identifier with the accepted domains.

Return to top

Certificate Requirements for Federation

To establish a federation trust, you must procure and install an X.509 certificate on the Exchange 2010 server used to create the trust. The certificate is used only to sign and encrypt delegation tokens. The certificate must meet the following requirements:

• Trusted certification authority   The certificate must be signed by a trusted certification authority (CA). For a list of trusted CAs, see Trusted Root Certification Authorities for Federation Trusts.
• Subject key identifier   The certificate must have a subject key identifier field. Most X.509 certificates issued by commercial certification authorities have a subject key identifier.
• CryptoAPI cryptographic service provider (CSP)   The certificate must use a CryptoAPI CSP. Certificates that use Cryptography Next Generation (CNG) providers aren't supported for federation. If you use Exchange to create a certificate request, a CryptoAPI provider is used. For more information, see Cryptography.
• RSA signature algorithm   The certificate must use RSA as the signature algorithm.
• Exportable private key   The private key used to generate the certificate must be exportable. You can specify that the private key of a certificate be exportable when you create the certificate request using the New Certificate wizard in the EMC, or the New-ExchangeCertificate cmdlet in the Shell.
• Current certificate   The certificate must be current. You can't use an expired or revoked certificate to create a federation trust.
• Enhanced key usage   The certificate must include the enhanced key usage (EKU) type Client Authentication (1.3.6.1.5.5.7.3.2). This usage type is intended for the purpose of proving your identity to a remote computer. If you use Exchange tools to generate the certificate request, this usage type is included by default.

Because the certificate isn't used for authentication, it doesn't have any subject name or subject alternative name requirements. You can use a certificate with a subject name that's the same name as the host name, the domain name, or any other name. Only one certificate is required for the federation trust. Exchange automatically distributes the certificate to other Exchange 2010 servers in the organization.

Return to top

Transitioning to a New Certificate

The certificate used to create the federation trust is designated as the current certificate. You may need to install and use a new certificate periodically, for example, when the current certificate expires, or you need to change the certificate to meet the organization's business or security requirements. To ensure a seamless switchover to a new certificate, you must install the new certificate on your Exchange 2010 server, and configure the federation trust to designate it as the next certificate. Exchange 2010 automatically distributes the next certificate to other Exchange 2010 servers in the organization. Depending on your Active Directory topology, distribution of the certificate may take some time. You can verify the certificate status using the Manage Federation wizard in the EMC, or the Test-FederationTrustCertificate cmdlet in the Shell.

After you verify the certificate's distribution status, you can configure the trust to switch to the next certificate. When this happens, the current certificate is designated as the previous certificate, and the next certificate is designated as the current certificate. The new current certificate is published to the Microsoft Federation Gateway, and then tokens exchanged with the Microsoft Federation Gateway are encrypted with the new certificate. The transition is shown in the following figure.

Certificate transitions

For more information about transitioning to a new certificate, see Manage Federation.

Return to top