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.

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.