Federated Web SSO example

Applies To: Windows Server 2003 R2

In this scenario, the fictitious company A. Datum Corporation has employees that work at their corporate offices and mobile employees that work at their homes. As with any other company, office supplies must be ordered from other retailers for the A. Datum employees. When users need to be authenticated, the account partner discovery page on the federation server in Trey Research always returns a Uniform Resource Locator (URL) for the external Federation Service Proxy.

As shown in the following illustration, employee sessions may originate from the corporate network for an office employee or from the Internet for a remote employee. Office employees are authenticated transparently to the federation server through their desktop logon sessions. Mobile employees are authenticated through passwords and forms authentication, or if it is configured, through client Secure Sockets Layer (SSL).

All the ADFS-enabled Web servers in the perimeter network of Trey Research are exposed directly to the Internet, without a federation server proxy. They are protected only by a firewall that screens out non-Web traffic. In a production environment, a business like Trey Research would probably deploy proxy servers in front of its Web farm servers. In this example, a proxy is omitted for the sake of clarity because it complicates the message flow with extra steps.

Message flow for federation through internal access

The ADFS-enabled Web server that is hosted by the online retailer is located in the perimeter network. When the office employees connect to the ADFS-enabled Web server directly, they are redirected to the default logon URL at the resource federation server proxy. Then, the employees must use home realm discovery to select the Federation Service endpoint URL. Corporate network DNS servers resolve that to the IP address of the internal account federation server.

The office employee authenticates by using his currently logged-on desktop session credentials and integrated authentication at an internal account federation server in the corporate network. The account federation server and Active Directory in the corporate network are used to validate the office employee's credentials and obtain attributes for building a Security Assertion Markup Language (SAML) security token.

Client application request

The following illustration and corresponding steps provide a description of the client application request process in ADFS using Transport Layer Security / Secure Sockets Layer (TLS/SSL).

1. The office employee uses his Web browser to open an application on the ADFS-enabled Web server.

2. The ADFS-enabled Web server refuses the request because there is no ADFS authentication cookie. The Web server redirects the client browser to the logon Web page on the resource federation server.

3. The client browser requests to sign-in from the resource federation server.

Authenticating the user

The following illustration and corresponding steps provide a description of the authentication process in ADFS. Unless it is otherwise noted, all traffic uses TLS/SSL.

1. The logon Web page on the resource federation server prompts the user for account partner discovery.

2. The resource federation server redirects the client browser to the logon Web page on the account federation server proxy.

3. The client browser requests the logon Web page from the account federation server proxy:

   • Internal DNS servers resolve the account federation server proxy URL to the CNAME of the account federation server.

   • Windows Integrated authentication occurs transparently.

4. The account federation server does the following:

   • Validates user credentials and gets attributes from Active Directory in the corporate network forest using Lightweight Directory Access Protocol (LDAP).

   • Builds the security token for the resource federation server.

   • Builds the ADFS authentication cookie.

5. The account federation server redirects the Web browser to send the POST request to the resource federation server:

   • The POST request includes the security token in the body and Java script to activate.

   • The ADFS authentication cookie is written to the browser.

6. The client browser sends a POST request to the resource federation server.

7. The resource federation server redirects the Web browser to send the POST request to the ADFS-enabled Web server:

   • Builds the security token for the Web application.

   • Builds the new ADFS authentication cookie.

   • The POST request includes the security token in the body and Java script to activate.

   • The ADFS authentication cookie is written to the browser.

8. The Web browser sends the POST request to the ADFS-enabled Web server.

9. The ADFS-enabled Web server redirects the client to its application URL:

   • ADFS validates the security token.

   • Builds the new ADFS authentication cookie.

   • The ADFS authentication cookie is written to the browser.

10. The client browser uses the ADFS authentication cookie to request the original application URL from the ADFS-enabled Web server.

11. The ADFS-enabled Web server application authorizes the user’s request based on attributes from the security token.

The Web browser requests additional application URLs from the ADFS-enabled Web server with its ADFS authentication cookie.

Message flow for federation through remote access

When mobile employees connect to the ADFS-enabled Web server directly, they are redirected to the default logon URL at the resource federation server. Then, they must use home realm discovery to select the account Federation Service endpoint URL. A mobile employee may then enter his credentials through a Web page that is displayed by the browser.

Client application request

The following illustration and corresponding steps provide a description of the client application request process in ADFS using TLS/SSL.

1. The remote employee uses the Web browser to open the application on the ADFS-enabled Web server.

2. The ADFS-enabled Web server refuses the request because there is no ADFS authentication cookie. The ADFS-enabled Web server redirects the client browser to sign-in on the resource federation server.

3. The client browser requests the logon Web page from the resource federation server.

4. The Web page on the resource federation server prompts the user for account partner discovery.

5. The resource federation server redirects the client browser to the logon Web page on the account federation server proxy.

6. The Web browser requests the logon Web page from the account federation server proxy.

Authenticating the user

The following illustration and corresponding steps provide a description of the user authentication process in ADFS. Unless it is otherwise noted, all traffic uses TLS/SSL.

1. The Web page on the account federation server proxy prompts the client for user credentials.

2. The account federation server proxy requests a security token from the account federation server by using Secure Hypertext Transfer Protocol (HTTPS).

3. The account federation server does the following:

   • Validates user credentials and gets attributes from Active Directory in the corporate network forest using LDAP.

   • Builds the security token for the resource federation server.

   • Builds the ADFS authentication cookie.

4. The account federation server sends the security token and the ADFS authentication cookie to the account federation server proxy using Web methods and HTTPS.

5. The account federation server proxy redirects the Web browser to send the POST request to the resource federation server:

   • The POST request includes the security token in the body and Java script to activate.

   • The ADFS authentication cookie is written to the browser.

6. The client browser sends the POST request to the resource federation server.

7. The resource federation server redirects the Web browser to send the POST request to the ADFS-enabled Web server:

   • The POST request includes the security token in the body and Java script to activate.

   • Builds the new ADFS authentication cookie

   • The ADFS authentication cookie is written to the browser.

8. The client browser sends the POST request to the ADFS-enabled Web server.

9. The ADFS-enabled Web server redirects the Web browser to its application URL:

   • ADFS validates the security token.

   • Builds the new ADFS authentication cookie.

   • The ADFS authentication cookie is written to the browser.

10. The Web browser requests the original application URL for the ADFS-enabled Web server with the ADFS authentication, ADFS-enabled Web server cookie.

11. The Web application authorizes the user’s request, based on attributes in the security token.

The Web browser uses its ADFS authentication cookie to request additional application URLs from the ADFS-enabled Web server.