The Microsoft Federation Gateway is an identity service that runs over the Internet and mediates between an organization or business and the external services that the organization wants to use. The gateway acts as a hub for many of the connections the organization wants to make with applications built on Windows Azure or to a Microsoft application that is running on the Internet. The gateway connects users and other identities to the services that it works with, so that an organization only has to manage a single identity-federation relationship to enable its identities to access all Microsoft and Microsoft-based services they want to use.

The Microsoft Federation Gateway provides applications with a simple, standards-based method of establishing trust between separate organizations that uses SSL certificates to prove domain ownership. Because the organizations federate with the gateway instead of with each other, it is much easier for an organization to establish trust relationships with multiple partners than is possible when it uses conventional one-on-one federation or other trust relationships. The scope of the federation can be easily controlled by creating allow or deny lists of users and domains for licensing and by specifying the domains that can receive publishing licenses. This guarantees that that only appropriate organizations are given access to protected information.

A federated-identity relationship is a standards-based arrangement between organizations in which claims from one organization are passed to and recognized by another. Through this relationship, users can sign in to and be authenticated by their identity provider—the organization that manages their identity account—and then have their authentication passed to a federated partner without being required to sign in again.

The Microsoft Federation Gateway establishes federated-identity relationships by building on the Web service (WS-*) specifications such as WS-Trust and WS-Security that work together to simplify interoperability and improve security. By using these industry-standard protocols, organizations can establish a federated-identity relationship without requiring them to use identical platforms or infrastructure.

When two organizations establish a federated-identity relationship, one partner (the identity provider) controls its own user accounts while the other partner (the resource provider) grants access to its resources by relying on the authentication performed by the identity provider. A user’s identity is defined as a set of claims, that is, statements that a server makes about a user. Examples of such claims are the user’s name, groups, or permissions. Identity federation enables the sharing of these identity claims.

With the Microsoft Federation Gateway, authentication from the identity provider is supplied to the gateway by using a standard format called Security Assertion Markup Language (SAML). The Microsoft Federation Gateway then converts the authentication information into a service token that can be used by Microsoft services.

Microsoft Federation Gateway Support in Windows Server® 2008 R2 enables AD RMS to accept tokens from the Microsoft Federation Gateway to authenticate users for certification and licensing. For example, Microsoft Exchange Server 2010 is designed to take advantage of this capability by enabling messages protected by AD RMS to be sent between organizations that do not share an Active Directory Domain Services (AD DS) infrastructure. When the Exchange Server 2010 infrastructure is configured to take advantage of these features, users can send AD RMS–protected e-mail messages to recipients outside the sender’s organization who can than view the messages by using Exchange Server 2010 Outlook Web App or Microsoft Outlook. Also, senders can grant permission recipient organizations that use Exchange Server 2010 permission to decrypt content for such purposes as journaling and malware scanning.

For more information about how to deploy Microsoft Federation Gateway Support on AD RMS, see Checklist: Deploying AD RMS with Microsoft Federation Gateway Support.

Additional references

Table Of Contents