Exchange Server 2010 uses Microsoft Federation Gateway (MFG), an identity service that runs in the cloud, as the trust broker. Exchange organizations wanting to use Federation establish a Federation Trust with MFG, allowing it to become a federation partner to the Exchange organization. The trust allows users authenticated by Active Directory , known as the identity provider (IP), to be issued Security Assertion Markup Language (SAML) delegation tokens by MFG. The delegation tokens allow users from one federated organization to be trusted by another federated organization. With MFG acting as the trust broker, organizations are not required to establish multiple individual trust relationships with other organizations. Users can access external resources using a single sign-on (SSO) experience.

To use exExchange2010 Federation, you must establish a Federation Trust between your Exchange 2010 organization and MFG by exchanging your organization's certificate with MFG, and retrieving MFG's certificate and federation metadata. You can establish a Federation Trust using the New Federation Trust wizard in the EMC or the New-FederationTrust cmdlet. The certificate is used for signing and encrypting tokens. For more details about certificate requirements, see the Certificate Requirements for Federation section.

For more information about creating a Federation Trust, see Create a Federation Trust.

When you create a Federation Trust with MFG, an Application Identifier (AppID) is generated for your Exchange organization and provided in the output of New Federation Trust wizard in EMC or the New-FederationTrust cmdlet. The AppID is used by MFG to identify your Exchange organization. It is also used by the Exchange organization to provide proof of ownership of the registered domain(s) being federated, by creating a TXT resource record in the DNS zone of each federated domain.

Important:
To federate an accepted domain, you must add the domain to the Federated Organization Identifier (OrgId). Before you add a domain to the Organization Identifier, you must create the TXT record with the AppID created for your organization when establishing the Federation Trust. You must do this for each accepted domain you wish to add to the Organization Identifier as a federated domain.

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

The Federated Organization Identifier (OrgID) defines which of the authoritative accepted domains configured in the Exchange organization are enabled for federation. Only users that have e-mail addresses with accepted domains configured in the Organization Identifier are recognized by MFG, and can use features such as Federated Sharing. When you configure the Organization Identifier, an Account Namespace is created with MFG 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 MFG, create TXT records for all accepted domains you wish to use for federation, and configure the Organization Identifier with the accepted domains, you can configure federation features such as Federated Sharing.

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 only used 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 certification authorities, see Trusted Root Certification Authorities For Federation Trusts.
  
• Subject Key Identifier   The certificate must have a Subject key Identifier (SKI) field. Most X.509 certificates issued by commercial certification authorities have a SKI.
  
• CryptoAPI CSP   The certificate must use a CryptoAPI cryptography service provider (CSP). Certificates that use CryptoAPI Next Generation (CNG) providers are not supported for Federation. If you use Exchange to create a new certificate request, a CryptoAPI provider is used.
  
• 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 EMC, or the New-ExchangeCertificate cmdlet.
  
• Current certificate   The certificate must be current. You can't create a Federation Trust using a certificate that is expired or revoked.
  
• Enhanced Key Usage   The certificate must include the Enhanced Key Usage type Client Authentication (1.3.6.1.5.5.7.3.2). This usage type is inteded 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.
  

Since the certificate is not used for authentication, it does not have any subject name or subject alternative name requirements. You can use a certificate with a subject name that is the same name as the hostname, 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.

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 EMC, or the Test-FederationTrustCertificate cmdlet.

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 MFG, following which tokens exchanged with MFG are encrypted with the new certificate.

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

Note:
This transition mechanism is only used by Federation. If you use the same certificate for other Exchange 2010 features that use certificates, you must take the feature requirements into consideration when planning to procure, install, or transition to a new certificate.