Active Directory Federation Services (AD FS) supports federated identity designs (also referred to as federation scenarios) that use Web Services Federation (WS-Federation), WS-Federation Passive Requestor Profile (WS-F PRP), and WS-Federation Passive Requestor Interoperability Profile specifications. The AD FS solution helps administrators deal with federated identity management challenges by making it possible for organizations to securely share a user's identity information over federation trusts. The following three descriptions of deployment designs illustrate how you can use a combination of AD FS server roles to federate identities, depending on the needs of your organization. For more information about the various server roles, see Understanding AD FS Role Services.
Federated Web SSO
The Federated Web Single Sign-On (SSO) design involves secure communication that often spans multiple firewalls, perimeter networks, and name resolution servers, in addition to the entire Internet routing infrastructure. Communication over a federated Web SSO environment can help foster more efficient and secure online transactions between organizations that are joined by federation trust relationships.
As shown in the following illustration, a federation trust relationship can be established between two businesses. In this design, federation servers route authentication requests from user accounts in Tailspin Toys to Web-based applications that are located in the network of Online Retailer.
Federation servers authenticate requests from trusted partners based on the credentials of the partners. Representations of the credentials are exchanged in the form of security tokens.
For enhanced security, federation server proxies can be used to relay requests to federation servers that are not directly accessible from the Internet.
Federated Web SSO with Forest Trust
The Federated Web SSO with Forest Trust design involves two Active Directory forests in a single organization, as shown in the following illustration. One of the forests is located in the organization's perimeter network (also known as a demilitarized zone, extranet, or screened subnet). The other forest is located in the internal network. A one-way, forest trust is established so that the forest in the perimeter network trusts the forest in the internal network. Federation servers are deployed in both networks. A federation trust is established so that accounts in the internal forest can be used to access a Web-based application in the perimeter network, whether the accounts access the site from the intranet forest or from the Internet.
In this design, external users, such as customers, can access the Web application by authenticating to the external account federation server, which is located in the perimeter network. External users have user accounts in the perimeter-network Active Directory forest. Internal users, such as employees, can also access the Web application by authenticating to the internal account federation server, which is located in the internal network. Internal users have accounts in the internal Active Directory forest.
If the Web-based application is a Windows NT token–based application, the AD FS Web Agent that is running on the Web application server intercepts requests and creates Windows NT security tokens, which are required by the Web application to make authorization decisions. For external users, this is possible because the AD FS-enabled Web server that hosts the Windows NT token-based application is joined to the domain in the external forest. For internal users, this is enabled through the forest trust relationship that exists between the perimeter forest and the internal forest.
If the Web-based application is a claims-aware application, the AD FS Web Agent that is running on the Web application server does not have to create Windows NT security tokens for the user. The AD FS Web agent can expose the claims that come across, which makes it possible for the application to make authorization decisions based on the contents of the security token that is provided by the account federation server. As a result, when it deploys claims-aware applications, the AD FS-enabled Web server does not have to be joined to the domain, and the external-forest-to-internal-forest trust is not required.
Web SSO
In the AD FS Web SSO design, users must authenticate only once to access multiple Web-based applications. In this design all users are external, and no federation trust exists. Because the AD FS-enabled Web servers must be Internet accessible and also joined to the Active Directory domain, they are connected to two networks; that is, they are multihomed. The first network is Internet facing (the perimeter network) to provide the needed connectivity. The second network contains the Active Directory forest (the protected network), which is not directly Internet accessible. The federation server proxy is also multihomed to provide the necessary connectivity to the federation server and the Internet. In this design, placing the federation server on a network that is not directly accessible from the Internet greatly reduces the risk to the federation server.
