Federated Web SSO with Forest Trust Example

  • Article

Applies To: Windows Server 2008

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 Domain Services (AD DS) 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 or Windows Server 2008) 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.

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 (AD FS) 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 AD FS Web Agent on the AD FS-enabled Web server also creates a Windows NT token for the user and the token can be impersonated by the application.

All the AD FS-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 AD FS-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 AD FS-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 AD FS using TLS/SSL.

  1. The traveling salesman uses his Web browser to open the purchasing application on the AD FS-enabled Web server.

  2. The AD FS-enabled Web server refuses the request because there is no AD FS 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.

  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 AD FS 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:

    • The resource federation server returns an HTML page that contains Java script code, which when executed by the Web browser will result in an HTTP POST of the security token to the AD FS-enabled Web server.

    • The AD FS 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 AD FS authentication cookie.

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

    • The resource federation server returns an HTML page that contains Java script code, which when executed by the Web browser will result in an HTTP POST of the security token to the AD FS-enabled Web server.

    • The AD FS authentication cookie is written to the browser.

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

  9. The AD FS-enabled Web server redirects the Web browser to its application URL, and then:

    • The AD FS-enabled Web server component validates the security token.

    • The AD FS-enabled Web server builds the new AD FS authentication cookie.

    • The AD FS authentication cookie is written to the browser.

  10. The Web browser requests the original application URL from the AD FS-enabled Web server with the AD FS authentication cookie.

  11. The AD FS-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 AD FS-enabled Web server with its AD FS authentication cookie.

Message flow for warehouse manager internal access

The AD FS-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 AD DS in the corporate network validate the credentials and obtain attributes for building a security token.

When corporate network users connect to the AD FS-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 AD FS using TLS/SSL.

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

  2. The AD FS-enabled Web server refuses the request because there is an AD FS authentication cookie. The AD FS-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 AD FS. Unless it is otherwise noted, all traffic uses TLS/SSL.

  1. The account federation server does the following:

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

    • Builds the security token for the Web application.

    • Builds the AD FS authentication cookie.

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

    • The resource federation server returns an HTML page that contains Java script code, which when executed by the Web browser will result in an HTTP POST of the security token to the AD FS-enabled Web server.

    • The AD FS 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 AD FS authentication cookie.

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

    • The resource federation server returns an HTML page that contains Java script code, which when executed by the Web browser will result in an HTTP POST of the security token to the AD FS-enabled Web server.

    • The AD FS authentication cookie is written to the browser.

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

  6. The AD FS-enabled Web server redirects the Web browser to its application URL:

    • AD FS validates the security token.

    • The AD FS-enabled Web server builds the new AD FS authentication cookie.

    • The AD FS authentication cookie is written to the browser.

  7. The client browser requests the original application URL from the AD FS-enabled Web server with the AD FS 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 AD FS-enabled Web server with its AD FS authentication cookie.