Federated Web SSO with Forest Trust example

  • Article

Applies To: Windows Server 2003 R2

In this scenario, the fictitious company Adventure Works is both a retail distributor and a wholesale distributor. The company sells products directly through Adventure Works salesmen, service departments, and sporting goods stores. Adventure Works obtains its entire inventory from other vendors. It does not manufacture the products it sells.

Adventure Works has two separate Active Directory forests. The forest in the perimeter network hosts the online inventory, purchasing, and customer service Web applications. The Inventory application that Adventure Works uses is critical to its operations. Therefore, this application is protected with strong security measures that require Windows impersonation and use access control lists (ACLs). The Purchasing application and the Customer Service application are claims-aware applications.

Traveling salesmen access perimeter network applications by using their employee accounts, which are managed in Active Directory in the corporate network forest.

As shown in the following illustration, a one-way trust from the perimeter network to the forest in the corporate network (an external trust for Microsoft® Windows® 2000 Server or a forest trust for Microsoft Windows Server® 2003) is created. The required ports are open in the firewall between the corporate network and the perimeter network to support trust and authentication as well as Web application traffic.

Art Image

Because a one-way trust is already in place, Adventure Works decides to take advantage of it to enable applications to create access tokens for employees and have single sign-on (SSO) in the perimeter network.

Employee sessions may originate from the corporate network, for headquarters staff such as the Plant Manager, or from the Internet for mobile staff, such as traveling salesmen. This means that two types of authentication mechanisms are used:

  • Intranet employees use integrated authentication.

  • Mobile employees use Transport Layer Security / Secure Sockets Layer (TLS/SSL) client authentication or forms authentication.

Regardless of the type of user account or authentication mechanism, Active Directory Federation Services (ADFS) authentication always generates a security token, which is delivered to the application for the purpose of authorizing user requests. Because the inventory application is used only by employees who have Active Directory accounts, the ADFS Web Agent on the ADFS-enabled Web server also creates a Windows NT token for the user and the token can be impersonated by the application.

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

Message flow for traveling salesman remote access

The ADFS-enabled Web server that hosts the Purchasing application is located in the Active Directory forest in the perimeter network. A traveling salesman authenticates to the application through an account federation server proxy. However, the default Federation Service for the ADFS-enabled Web server is the resource Federation Service. Therefore, when multiple account stores or multiple partners are configured, account partner discovery is required to redirect employees to the account federation server proxy. The account federation server and the corporate network Active Directory service validate the traveling salesman's credentials and obtain attributes for building a security token.

Client application request

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

Art Image

  1. The traveling salesman uses his Web browser to open the purchasing 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 the logon Web page from the resource federation server.

  4. Depending on whether there are multiple account stores or multiple partners configured, 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 client browser requests the logon Web page from the account federation server proxy.

Authenticating the user requesting access to the application

The following illustration and corresponding steps describe how the traveling salesman is authenticated after requesting access to the Order Entry application. Unless it is otherwise noted, all traffic uses TLS/SSL.

Art Image

  1. The Web page on the account federation server proxy prompts the user 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:

    • Maps the user certificate and retrieves any required Lightweight Directory Access Protocol (LDAP) attributes from Active Directory in the corporate network using LDAP.

    • Builds the security token for the Web application.

    • Builds the ADFS authentication cookie.

  4. The account federation server sends the authentication cookie and security token to the account federation server proxy using Simple Object Access Protocol (SOAP) and HTTPS.

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

    • POST with 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 does the following:

    • Builds the new security token for the Web application.

    • Builds the new ADFS authentication cookie.

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

    • POST with security token in the body and Java script to activate.

    • The ADFS authentication cookie is written to 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 Uniform Resource Locator (URL), and then:

    • The ADFS-enabled Web server component 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 from the ADFS-enabled Web server with the ADFS authentication cookie.

  11. The ADFS-enabled Web server application:

    • Builds an impersonation Windows NT token from the security token.

    • Uses this Windows NT token to impersonate and to access check.

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

Message flow for warehouse manager internal access

The ADFS-enabled Web server that hosts the Inventory application is located in the perimeter network forest. The warehouse manager authenticates by using currently logged on desktop session credentials and integrated authentication at the account federation server in the corporate network. The account federation server and Active Directory in the corporate network validate the credentials and obtain attributes for building a security token.

When corporate network users connect to the ADFS-enabled Web server directly, they are redirected to the resource federation server. Then, as in the case of the traveling salesman, they are redirected through Domain Name System (DNS) servers to the canonical name (CNAME) of the account federation server.

Client application request

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

Art Image

  1. The warehouse manager uses a Web browser to open the application on the ADFS-enabled Web server.

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

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

  4. Depending on whether there are multiple account stores or multiple partners configured, the Web page on the resource federation server prompts the user for account partner discovery.

  5. The client browser is sent directly to the account federation server.

Authenticating the user

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

Art Image

  1. 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 Web application.

    • Builds the ADFS authentication cookie.

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

    • POST with security token in body and Java script to activate.

    • The ADFS authentication cookie is written to the browser.

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

  4. The resource federation server:

    • Builds the new security token for the Web application.

    • Builds the new ADFS authentication cookie.

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

    • POST with security token in body and Java script to activate.

    • The ADFS authentication cookie is written to the browser.

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

  6. 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.

  7. The client browser requests the original application URL from the ADFS-enabled Web server with the ADFS authentication cookie.

  8. The Web application:

    • Builds an impersonation Windows NT token from the security token.

    • Uses this Windows NT token to impersonate and to access check.

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