Understanding Federation
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Information workers frequently need to collaborate with external recipients, vendors, partners, and customers and share their free/busy (also known as calendar availability) and contact information. Federation in Microsoft Exchange Server 2010 helps with these collaboration efforts. Federation refers to the underlying trust infrastructure that supports federated delegation, an easy method for users to share calendar and contact information with recipients in other external federated organizations. To learn more about federated delegation, see Understanding Federated Delegation.
Looking for management tasks related to federation? Check out Managing Federation.
Contents
Microsoft Federation Gateway
Federation Trust
Federated Organization Identifier
Federation Example
Certificate Requirements for Federation
Transitioning to a New Certificate
Microsoft Federation Gateway
The Microsoft Federation Gateway, a free cloud-based service offered by Microsoft, acts as the trust broker between your on-premises Exchange 2010 organization and other federated Exchange 2010 organizations. If you want to configure federation in your Exchange organization, you must establish a one-time federation trust with the Microsoft Federation Gateway, so that it can become a federation partner with your organization. With this trust in place, users authenticated by Active Directory (known as identity providers) are issued Security Assertion Markup Language (SAML) delegation tokens by the Microsoft Federation Gateway. These delegation 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, and users can access external resources using a single sign-on (SSO) experience. For more information, see Understanding the Microsoft Federation Gateway.
Return to top
Federation Trust
To use Exchange 2010 federated delegation features, you must establish a federation trust between your Exchange 2010 organization and the Microsoft Federation Gateway. Establishing a federation trust with the Microsoft Federation Gateway exchanges your organization's digital security certificate with the Microsoft Federation Gateway and retrieves 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. A self-signed certificate is automatically created by the New Federation Trust wizard and is used for signing and encrypting delegation tokens that allow users to be trusted by external federated organizations. For details about certificate requirements, see Certificate Requirements for Federation later in this topic.
For details about how to create a federation trust, see Create a Federation Trust.
When you create a federation trust with the Microsoft Federation Gateway, an application identifier (AppID) is automatically 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 uniquely identify your Exchange organization. It's also used by the Exchange organization to provide proof that your organization owns the domain for use with the Microsoft Federation Gateway. This is done by creating a text (TXT) record in the Domain Name System (DNS) zone of each federated domain.
For details about how to create a TXT record, see Create a TXT Record for Federation.
Return to top
Federated Organization Identifier
The federated organization identifier (OrgID) defines which of the authoritative accepted domains configured in your organization are enabled for federation. Only recipients that have e-mail addresses with accepted domains configured in the OrgID are recognized by the Microsoft Federation Gateway and are able to use federated delegation features. When you create a new federation trust, an OrgID is automatically created with the Microsoft Federation Gateway. This OrgID is a combination of a pre-defined string and the first accepted domain selected for federation in the wizard. For example, in the Manage Federation wizard, if you specify the federated domain contoso.com as your organization’s primary SMTP domain, the FYDIBOHF25SPDLT.contoso.com account namespace will be automatically created as the OrgID for the federation trust.
This subdomain doesn’t have to be an accepted domain in your Exchange organization and doesn’t require a domain name system (DNS) proof of ownership TXT record. The only requirement is that accepted domains selected to be federated are limited to a maximum of 32 characters. Additionally, if you use the Manage Hybrid Configuration wizard to create a federation trust associated with configuring a hybrid deployment between your on-premises organization and an Exchange Online organization, the OrgID for the federated trust is also automatically configured with the automated namespace. The only purpose of this subdomain is to serve as the federated namespace for the Microsoft Federation Gateway to maintain unique identifiers for recipients that request SAML delegation tokens. For more information about SAML tokens, see SAML Tokens and Claims
You can add or remove accepted domains at any time. If you want to enable or disable all federation features in your organization, all you have to do is enable or disable the OrgID.
Important
If you change the OrgID, accepted domains, or the AppID used for federation, all federation features are affected in your organization. This also affects any external federated organizations, including Office 365 and hybrid deployment configurations. We recommend that you notify all external federated partners of any changes to these configuration settings.
For more information about configuring the federated OrgID, see the following topics:
Return to top
Federation Example
Two Exchange organizations, Contoso, Ltd. and Fabrikam, Inc., want their users to be able to share free/busy information with each other. Each organization creates a federation trust with the Microsoft Federation Gateway and configures its account namespace to include the domain used for its user's e-mail address domain.
Contoso employees use one of the following e-mail address domains: contoso.com, contoso.co.uk, or contoso.ca. Fabrikam employees use one of the following e-mail address domains: fabrikam.com, fabrikam.org, or fabrikam.net. Both organizations make sure that all accepted e-mail domains are included in the account namespace for their federation trust with the Microsoft Federation Gateway. Rather than requiring a complex Active Directory forest or domain trust configuration between the two organizations, both organizations configure an organization relationship with each other to enable free/busy sharing.
The following figure illustrates the federation configuration between Contoso, Ltd. and Fabrikam, Inc.
Federated delegation example
.gif "Federation Trusts and Federated Sharing")
Certificate Requirements for Federation
To establish a federation trust with the Microsoft Federation Gateway, either a self-signed certificate or an X.509 certificate signed by a certification authority (CA) must be created and installed on the Exchange 2010 server used to create the trust. We recommend using a self-signed certificate, which can be automatically created and installed using the New Federation Trust wizard in the EMC. This certificate is used only to sign and encrypt delegation tokens used for federated delegation. Only one certificate is required for the federation trust. Exchange 2010 automatically distributes the certificate to other Exchange 2010 servers in the organization.
If you want to use an X.509 certificate signed by an external CA, the certificate must meet the following requirements:
Trusted CA If possible, the X.509 Secure Sockets Layer (SSL) certificate should be issued from a CA trusted by Windows Live. However, you can use certificates issued by CAs that aren't currently certified by Microsoft. For a current 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 CAs have this identifier.
CryptoAPI cryptographic service provider (CSP) The certificate must use a CryptoAPI CSP. Certificates that use Cryptography API: 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 API: Next Generation.
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 be exportable when you create the certificate request using the New Exchange 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 used to prove your identity to a remote computer. If you use the EMC or the Shell to generate a certificate request, this usage type is included by default.
Note
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 as the host name, the domain name, or any other name.
Return to top
Transitioning to a New Certificate
The certificate used to create the federation trust is designated as the current certificate. However, you may need to install and use a new certificate for the federation trust periodically. For example, you may need to use a new certificate if the current certificate expires or to meet a new business or security requirement. To ensure a seamless transition 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 awhile. 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 use the next certificate. After switching certificates, the current certificate is designated as the previous certificate, and the next certificate is designated as the current certificate. The new certificate is published to the Microsoft Federation Gateway, and all new tokens exchanged with the Microsoft Federation Gateway are encrypted using the new certificate. The following figure illustrates how you can use the Manage Federation wizard to configure this transition.
Certificate transitions
.gif "Switching to the next certificate")
For more information about how to transition to a new certificate, see Manage Federation.
Note
This certificate transition process is used only by federation. If you use the same certificate for other Exchange 2010 features that require certificates, you must take the feature requirements into consideration when planning to procure, install, or transition to a new certificate.
Return to top
© 2010 Microsoft Corporation. All rights reserved.