Step 3: Plan to Publish Applications using AD FS Preauthentication

Updated: August 26, 2013

Applies To: Windows Server 2012 R2

This topic describes the general preauthentication flow when using Active Directory Federation Services (AD FS) preauthentication and the planning tasks for publishing applications through Web Application Proxy using AD FS preauthentication, including the preauthentication flow for different clients and applications.

For all types of application that you can publish using AD FS preauthentication, you must add a AD FS relying party trust to the Federation Service.

The general AD FS preauthentication flow is as follows:

1. The client device attempts to access a published web application on a particular resource URL; for example https://app1.contoso.com/.

   The resource URL is a public address on which Web Application Proxy listens for incoming HTTPS requests.

2. Web Application Proxy redirects the HTTPS request to the AD FS server with URL encoded parameters, including the resource URL and the appRealm (a relying party identifier).

   The user authenticates using the authentication method required by the AD FS server; for example, user name and password, two-factor authentication with a one-time password, and so on.

3. After the user is authenticated, the AD FS server issues a security token, the ‘edge token’, containing the following information and redirects the HTTPS request back to the Web Application Proxy server:

   • The resource identifier that the user attempted to access.

   • The user’s identity as a user principal name (UPN).

   • The expiry of the access grant approval; that is, the user is granted access for a limited period of time, after which they are required to authenticate again.

   • Signature of the information in the edge token.

4. Web Application Proxy receives the redirected HTTPS request from the AD FS server with the edge token and validates and uses the token as follows:

   • Validates that the edge token signature is from the federation service that is configured in the Web Application Proxy configuration.

   • Validates that the token was issued for the correct application.

   • Validates that the token has not expired.

   • Uses the user identity when required; for example to obtain a Kerberos ticket if the backend server is configured to use Integrated Windows authentication.

5. If the edge token is valid, Web Application Proxy forwards the HTTPS request to the published web application using either HTTP or HTTPS.

6. The client now has access to the published web application; however, the published application may be configured to require the user to perform additional authentication. If, for example, the published web application is a SharePoint site and does not require additional authentication, the user will see the SharePoint site in the browser.

7. Web Application Proxy saves a cookie on the client device. The cookie is used by Web Application Proxy to identify that this session has already been preauthenticated and that no further preauthentication is required.

3.1. Plan Claims-Based Applications

To publish an application that uses claims for authentication, you must add a relying party trust for the application to the Federation Service.

When publishing claims-based applications and accessing the application from a browser, the general authentication flow is as follows:

1. The client attempts to access a claims-based application using a web browser; for example, https://appserver.contoso.com/claimapp/.

2. The web browser sends an HTTPS request to the Web Application Proxy server which redirects the request to the AD FS server.

3. The AD FS server authenticates the user and the device and redirects the request back to Web Application Proxy. The request now contains the edge token. The AD FS server adds a single sign-on (SSO) cookie to the request because the user has already performed authentication against the AD FS server.

4. Web Application Proxy validates the token, adds its own cookie, and forwards the request to the backend server.

5. The backend server redirects the request to the AD FS server to get the application security token.

6. The request is redirected to the backend server by the ADFS server. The request now contains the application token and the SSO cookie. The user is granted access to the application and is not required to enter a user name or password.

3.2. Plan Integrated Windows Authentication-Based Applications

Web Application Proxy can be used to publish applications that uses Integrated Windows authentication; that is, Web Application Proxy performs preauthentication as required, and can then perform SSO to the published application that uses Integrated Windows authentication. To publish an application that uses Integrated Windows authentication you must add a non-claims-aware relying party trust for the application to the Federation Service.

To allow Web Application Proxy to perform single sign-on (SSO) and to perform credentials delegation using Kerberos constrained delegation, the Web Application Proxy server must be joined to a domain. See 1.4. Plan Active Directory.

To allow users to access applications that use Integrated Windows authentication, the Web Application Proxy server must be able to provide delegation for users to the published application. You can do this on the domain controller for any application. You can also do this on the backend server if it is running on Windows Server 2012 R2 or Windows Server 2012. For more information, see What's New in Kerberos Authentication.

For a walkthrough of how to configure Web Application Proxy to publish an application using Integrated Windows authentication, see Step 3: Configure and test accessing a website using Integrated Windows authentication.

When using Integrated Windows authentication to backend servers, the authentication between Web Application Proxy and the published application is not claims-based, instead it uses Kerberos constrained delegation to authenticate end users to the application. The general flow is described below:

1. The client attempts to access a non-claims-based application using a web browser; for example, https://appserver.contoso.com/nonclaimapp/.

2. The web browser sends an HTTPS request to the Web Application Proxy server which redirects the request to the AD FS server.

3. The AD FS server authenticates the user and redirects the request back to Web Application Proxy. The request now contains the edge token.

4. Web Application Proxy validates the token.

5. If the token is valid, Web Application Proxy obtains a Kerberos ticket from the domain controller on behalf of the user.

6. Web Application Proxy adds the Kerberos ticket to the request as part of the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) token, and forwards the request to the backend server. The request contains the Kerberos ticket; therefore, the user is granted access to the application without the need for further authentication.

3.3. Plan Applications for MSOFBA Clients

Web Application Proxy supports access from Microsoft Office clients such as Microsoft Word that access documents and data on backend servers. The only difference between these applications and a standard browser is that the redirection to the STS is done not via regular HTTP redirection but with special MSOFBA headers as specified in here: https://msdn.microsoft.com/en-us/library/dd773463(v=office.12).aspx. Backend application may be claims or IWA.
To publish an application for clients that use MSOFBA, you must add a relying party trust for the application to the Federation Service. Depending on the application, you can use claims-based authentication or Integrated Windows authentication. Therefore, you must add the relevant relying party trust depending on the application.

To allow Web Application Proxy to perform single sign-on (SSO) and to perform credentials delegation using Kerberos constrained delegation, the Web Application Proxy server must be joined to a domain. See 1.4. Plan Active Directory.

There are no additional planning steps if the application uses claims-based authentication. If the application used Integrated Windows authentication, see 3.2. Plan Integrated Windows Authentication-Based Applications.

The authentication flow for clients that use the MSOFBA protocol using claims-based authentication is described below. The authentication for this scenario can either use the application token in the URL, or in the body.

1. The user is working in an Office program, and from the Recent Documents list, opens a file on a SharePoint site.

2. The Office program shows a window with a browser control that requires the user to enter credentials.

   Note

   In some cases, the window may not appear because the client is already authenticated.

3. Web Application Proxy redirects the request to the AD FS server, which performs the authentication.

4. The AD FS server redirects the request back to Web Application Proxy. The request now contains the edge token.

5. The AD FS server adds a single sign-on (SSO) cookie to the request because the user has already performed authentication against the AD FS server.

6. Web Application Proxy validates the token and forwards the request to the backend server.

7. The backend server redirects the request to the AD FS server to get the application security token.

8. The request is redirected to the backend server. The request now contains the application token and the SSO cookie. The user is granted access to the SharePoint site and is not required to enter a user name or password to view the file.

3.4. Plan Applications for Clients that use Windows Store Apps

To publish an application for Windows Store apps, you must add a relying party trust for the application to the Federation Service.

To allow Web Application Proxy to perform single sign-on (SSO) and to perform credentials delegation using Kerberos constrained delegation, the Web Application Proxy server must be joined to a domain. See 1.4. Plan Active Directory.

In the AD FS Management console, you must make sure that the OAuth endpoint is proxy enabled. To check if the OAuth endpoint is proxy enabled, open the AD FS Management console, expand Service, click Endpoints, in the Endpoints list, locate the OAuth endpoint and make sure that the value in the Proxy Enabled column is Yes.

The authentication flow for clients that use Windows Store apps is described below:

1. The client attempts to access a published web application using a Windows Store app.

2. The app sends an HTTPS request to the URL published by Web Application Proxy.

3. Web Application Proxy returns an HTTP 401 response to the app containing the URL of the authenticating AD FS server. This process is known as ‘discovery’.

   Note

   If the app knows the URL of the authenticating AD FS server and already has a combo token containing the OAuth token and the edge token, steps 2 and 3 are skipped in this authentication flow.

4. The app sends an HTTPS request to the AD FS server.

5. The app uses the web authentication broker to generate a dialog box in which the user enters credentials to authenticate to the AD FS server. For information about web authentication broker, see Web authentication broker.

6. After successful authentication, the AD FS server creates a combo token that contains the OAuth token and the edge token and sends the token to the app.

7. The app sends an HTTPS request containing the combo token to the URL published by Web Application Proxy.

8. Web Application Proxy splits the combo token into its two parts and validates the edge token.

9. If the edge token is valid, Web Application Proxy forwards the request to the backend server with only the OAuth token. The user is granted access to the published web application.

See also

• Step 2: Plan the Web Application Proxy Server

• Step 5: Plan to Publish Applications using Pass-through Preauthentication

• Plan to Publish Applications through Web Application Proxy

• Installing and Configuring Web Application Proxy for Publishing Internal Applications

• Web Application Proxy Walkthrough Scenario