ADFS Architecture

ADFS Architecture
The core architecture of Active Directory Federation Services (ADFS) requires an Active Directory (AD) or Active Directory Application Mode (ADAM) instance that contains user credentials. ADFS doesn't replace the existing account repository; rather, it extends the repository's visibility to other organizations in a highly controller manner. ADFS is a security token service that's used mainly to compile statements about the user account in the form of security tokens, For custom applications, ADFS also populates claims, which are statements about the security principal (e.g., username, user's title), that the Web application uses to ascertain the level of access that should be given to the requesting user.

ADFS also manages the federation trusts it shares with other organizations' federated services. A federation trust isn't an AD forest trust; rather, it's a special trust that uses certificates for token signing between organizations. The trusting forest can't use the federation trust to query information about accounts in the account forest. The only information the trust ever sees is when specific users attempt to access Web services in its forest, and then it sees only account information designated as appropriate for that relationship. Federated-services servers in different organizations never communicate with each other; all communication occurs via the requesting client, which means the ports that have to be open for a typical domain trust aren't required for a federated trust. Creation of the federated trust is all done out-of-band with only the signing certificate for the account side of the trust required at both ends, which can be sent via an email or burned to media and sent via carrier. All communication from the client is via HTTP Secure (HTTPS, port 443).

The next component of ADFS is the Federation Server Proxy (FSP), which is essentially what Web-based servers communicate with and also provides a user interface for the benefit of the Web-based clients. Because of the FSP UI, clients don't have to communicate with the ADFS (i.e., federated services) server directly. Communication can occur via an ADFS proxy, which could reside in a demilitarized zone (DMZ) along with the Web application servers. By default, FSP is installed on all federated services. However, you can install it without the ADFS component to provide only the credential-collection facility and communicate back to the federated-services server. This would be useful in the DMZ situation in which you don't want your entire federated-services server on an extranet.

The last ADFS component is an ADFS Web agent that runs on the Web server. The Web agent helps enforce user authentication, creates the relevant user-authorization context, enables integration with Authorization Manager, enables support for Windows NT impersonation and various ASP.NET authentications, and enables support for the role-checking function.

The following steps outline a sample scenario in which a federated-services server authenticates a user. The diagram that Web Figure A shows illustrates these steps.

1. The user in the account forest tries to access a Web server in another organization's forest that's connected to the account forest via a federated trust. The ADFS Web agent on the Web server checks for the user's security token, which doesn't exist yet.
2. Because the user has no security token, ADFS doesn't give the user access to the application and redirects the user to the federated-services server in the resource forest.
3. The resource forest federated-services server performs a home realm discovery , by which the server determines the user's home forest either by prompting the user (via a Web page that displays a drop-down list of all the forests that the federated-services server trusts) or by inspecting a persistent cookie (which the resource federated-services server places on the client after the first successful communication).
4. After it has identified the requesting user's home forest, the resource federated-services server redirects the user to his or her local federated-services server to continue processing.
5. Authentication then occurs with the user's local federation service, which in turn authenticates via AD and pulls from AD information pertinent to the token that ADFS will create for transmission to the resource forest currently attempting access. (The home-forest federated-services server might designate different information for the different resource forests that trust the account federation.)
6. The local federated-services server then issues the client a token specifically for the resource forest and redirects the user to the federated-services server in the resource forest.
7. The resource federated-services server checks the passed token, confirms that it's been digitally signed with the correct certificate, and creates its own local token for the user to use when communicating with the Web application. The resource federated-services server then redirects the user to the Web application server. (This process works similarly to referral tickets in a multiple-domain forest.)
8. The Web application checks the passed token. This is a Security Assertion Markup Language (SAML) 1.1 token, an industry-standard format. The Web application reads the SAML token and allows authorization to the application and its content depending on the access limitations specified in the token.

This federated capability allows a user's AD-based credential to be used in cross-organizational trusts with partner companies. The bottom line of ADFS is that only one user account is required to sign on to multiple systems, which greatly improves accessibility of information and data security. For example, imagine a typical situation in which a user has 10 different accounts to access Web-based data in partner companies—or even in one's own company. Why synchronize if you can federate? Should the user leave the company, in a federated-services environment disabling access for the user's single account terminates all access for that user.