Working with Web Application Proxy

 

This content is relevant for the on-premises version of Web Application Proxy. To enable secure access to on-premises applications over the cloud, see the Azure AD Application Proxy content.

Web Application Proxy is a new Remote Access role service in Windows Server® 2012 R2. Web Application Proxy provides reverse proxy functionality for web applications inside your corporate network to allow users on any device to access them from outside the corporate network. Web Application Proxy preauthenticates access to web applications using Active Directory Federation Services (AD FS), and also functions as an AD FS proxy.

Providing Access to Applications

Web Application Proxy provides organizations with the ability to provide selective access to applications running on servers inside the organization to end users located outside of the organization. The process to make the application available externally is known as publishing. Unlike traditional VPN solutions, when you publish applications through Web Application Proxy end users can gain access only to applications that you publish. However, Web Application Proxy can also be deployed with VPN as part of a Remote Access deployment in your organization. See Interoperability with other remote access products, below.

Publishing Applications

Web Application Proxy publishing enables end users to access their organization’s applications from their own devices, so that users are not limited to corporate laptops to do their work, they can use their home computer, their tablet, or their smartphone. In addition, end users are not required to install any additional software on their device to access published applications. Web Application Proxy can be used on clients with a standard browser, an Office client or a rich client using OAuth (for example Windows Store apps). Web Application Proxy serves as a reverse proxy for any application that is published through it and as such, the end user experience is the same as if the end user’s device connects directly to the application.

Accessing Applications

Web Application Proxy must always be deployed with AD FS. This enables you to leverage the features of AD FS, such as, single sign-on (SSO). This enables users to enter their credentials one time and on subsequent occasions, they will not be required to enter their credentials. SSO is supported by Web Application Proxy for backend servers that use claims-based authentication; for example SharePoint claims-based applications, and Integrated Windows authentication using Kerberos constrained delegation. Integrated Windows authentication-based applications can be defined in AD FS as relying party trusts which can define rich authentication and authorization policies that are enforced in requests to the application.

Protecting Applications from External Threats

Web Application Proxy serves as a barrier between the Internet and your corporate applications. In many organizations, when you deploy Web Application Proxy and publish applications through it, those applications will be available to external users on devices that are not joined to your domain; for example, personal laptops, tablets, or smartphones. These devices are not domain-joined and as such, they are described as unmanaged devices, and are untrusted within the corporate network. Since you want your users to be able to access important information whenever and wherever they are located, you must mitigate the security risk of allowing users access to corporate resources from these unmanaged and untrusted devices. Web Application Proxy provides a number of security features to protect your corporate network from external threats. Web Application Proxy uses AD FS for authentication and authorization to ensure that only users on devices who authenticate and are authorized can access your corporate applications.

Defense in Depth

In the recommended deployment, Web Application Proxy is deployed in a perimeter network between an Internet-facing firewall and a corporate network firewall. However, in addition to the protection provided by the firewalls themselves, Web Application Proxy provides additional protection for your applications from external threats.

• When HTTPS traffic arrives that is directed to an address published by Web Application Proxy, it terminates the traffic and initiates new requests to the published applications. It therefore acts as a session-level buffer between external devices and published applications. That is, when users access published applications, they do not directly access the application, instead, they access the application through Web Application Proxy.

• Any other traffic that arrives at Web Application Proxy is dropped and not forwarded to the published applications. This includes any illegal HTTP or HTTPS requests that might be used as part of denial of service attacks, zero day attacks, SSL attacks, and so on.

• Any authenticated request that arrives at Web Application Proxy containing an authentication token from AD FS will be inspected to make sure that the token received was intended for the client sending the token. This is done by checking that the device (through the Workplace Join certificate) corresponds to the claim within the token that identified the device when authenticated to AD FS.

Authentication and Authorization

To protect access to applications in your organization, it is recommended to allow access only to authenticated and authorized users. When you publish applications through Web Application Proxy, this is achieved through the use of AD FS, which provides authentication and enforces authorization for the published applications.

Note

Web Application Proxy also allows pass-through preauthentication, which enables you to publish applications that do not require preauthentication or whose clients do not support the available authentication capabilities.

Authenticating Users and Devices

When you publish applications through Web Application Proxy, the process by which users and devices are authenticated before they gain access to applications is known as preauthentication. Web Application Proxy supports two forms of preauthentication:

• AD FS preauthentication—When using AD FS for preauthentication, the user is required to authenticate to the AD FS server before Web Application Proxy redirects the user to the published web application. This ensures that all traffic to your published web applications is authenticated.

• Pass-through preauthentication—Users are not required to enter credentials before they connect to published web applications.

  Note

  Pass-through preauthentication has no impact on whether an application requires users to provide credentials to the application. That is, an application configured with pass-through preauthentication does not require users to enter credentials to get into the corporate network, but may require users to enter credentials to view the application content.

To easily access applications published by Web Application Proxy, and to use AD FS preauthentication end users should use one of the following clients:

• Any client that supports HTTP redirects; for example, a web browser. Web Application Proxy performs the appropriate action on the incoming request to redirect the user to an authentication address and back to the original web address, this time with the authentication proof.

• Rich clients that use HTTP basic, for example, Exchange ActiveSync.

• Any client that uses MSOFBA; for example, Word, Excel, or PowerPoint. In this case, a user attempts to access a document from their Recent Documents list that is stored on a server within the corporate network.

• Windows Store apps and RESTful applications with clients that use the Web Authentication Broker for authentication. A user can open an app on their device which obtains a token from AD FS via the Web Authentication Broker, and includes that token in the HTTP Authorization header in subsequent requests to the app.

Note

Depending on the client used to access the published application, Web Application Proxy decides how to process the request.

Authentication Capabilities

When you use AD FS for authentication, you also benefit from all of the features that AD FS provides:

• Workplace Join—This is a new feature in AD FS in Windows Server 2012 R2. It allows users to join devices to the workplace that would not normally be domain-joined; for example, personal laptops, tablets, and smartphones. When this feature is enabled, the AD FS administrator can configure all applications, or individual applications, to require devices to be registered before they can gain access to published applications. For more information, see Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications.

• SSO—This allows users to enter credentials once and be authenticated to all supported published applications. See Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications.

• Multifactor authentication (MFA)—AD FS can be configured to require users to authenticate with more than one authentication scheme; for example, a one-time password or a smart card. See Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications.

• Multifactor access control—Access control in AD FS is implemented with authorization claim rules that are used to issue a permit or deny claims that will determine whether a user or a group of users will be allowed to access AD FS-secured resources or not. Authorization rules can only be set on relying party trusts. All of the above features can be combined, as required, to provide stricter security for confidential applications, or ignored for less confidential applications. See Manage Risk with Conditional Access Control.

When you publish applications through Web Application Proxy you are not required to configure the AD FS authentication features mentioned above. This allows you to provide access to devices that are not able to join the workplace, or provide additional factors of authentication, such as kiosks.

Web Application Proxy Technical Overview

When you decide to use Web Application Proxy in your organization, we recommend that you deploy your Web Application Proxy servers behind a frontend firewall to separate it from the Internet, or between two firewalls; a frontend firewall to separate it from the Internet, and a backend firewall to separate it from the corporate network. In this topology, Web Application Proxy provides a protection layer against malicious users that may be coming from the Internet. No other servers are required to be located in this perimeter network; that is, your AD FS servers are located in the corporate network and can only be reached via Web Application Proxy using its built-in AD FS proxy functionality.

The following diagram shows a typical topology for deploying Web Application Proxy in a perimeter network between two firewalls.

Web Application Proxy Configuration Storage

The Web Application Proxy configuration is stored on the AD FS servers in your organization; therefore, Web Application Proxy servers require connectivity to the AD FS servers. In addition, after configuring the first Web Application Proxy server, you can install additional Web Application Proxy servers to create a cluster deployment. When you install the role service on the new server in the cluster, the configuration is automatically transferred to the new server after completing the Web Application Proxy Configuration Wizard.

Since Web Application Proxy stores its configuration on the AD FS servers it has no locally stored configuration information.

AD FS Proxy Functionality

The Web Application Proxy role service is also an AD FS proxy. That is, Web Application Proxy listens to all of the end-points that AD FS listens to. Web Application Proxy also forwards any requests from the Internet to AD FS and responses from AD FS to the Internet. Note that the Web Application Proxy role service is a replacement for the AD FS proxy role.

Creating a proxy in your organization for your Federation Service adds additional security layers to your AD FS deployment. Consider deploying Web Application Proxy in your organization’s perimeter network when you want to:

• Prevent external client computers from directly accessing your AD FS servers. By deploying a Web Application Proxy server in your perimeter network, you effectively isolate your AD FS servers. Web Application Proxy servers do not have access to the private keys that are used to produce tokens.

• Provide a convenient way to differentiate the sign-in experience for users who are coming from the Internet as opposed to users who are coming from your corporate network using Integrated Windows authentication.

Managing Web Application Proxy

Web Application Proxy uses a number of tools and features provided by Windows Server 2012 R2 to enable you to easily install, deploy, and manage it in your corporate deployments.

• Web Application Proxy is a role service in Windows Server 2012 R2. This allows you to easily install Web Application Proxy in your deployment using Server Manager or Windows PowerShell.

• Web Application Proxy is integrated into the Remote Access Management console, allowing you to manage your Web Application Proxy servers and other Remote Access technologies, such as DirectAccess and VPN from the same Remote Access Management console.

• Web Application Proxy provides full functionality through a set of Windows PowerShell commands and a Windows Management Instrumentation (WMI) API.

• To aid troubleshooting, Web Application Proxy:

  • Writes events to the Windows Event log.

  • Exposes a number of performance counters.

  • Has a dedicated Best Practices Analyzer (BPA).

Interoperability with Other Remote Access Products

Web Application Proxy is a role service of the Remote Access role in Windows Server 2012 R2. You can install Web Application Proxy side-by-side with Remote Access in the following scenarios:

DirectAccess	VPN	Web Application Proxy
Single server deployment	Single server deployment	Single server deployment
Multisite deployment	Multiple server deployment	Not supported on the same server
Not supported on the same server	Multiple server deployment	Multiple server deployment
Cluster deployment1	Multiple server deployment	Multiple server deployment2

Note

1—In a pre-existing DirectAccess cluster deployment, you can install Web Application Proxy only using Windows PowerShell. 2—In a pre-existing multiple server Web Application Proxy deployment, you can install DirectAccess only using Windows PowerShell.

Web Application Proxy provides application publishing capabilities, similar to Forefront Unified Access Gateway (UAG). However, Web Application Proxy interacts with other servers and services to provide a more streamlined deployment. This helps you to concentrate on configuring only the necessary parts of your deployment. It is recommended that for any new deployments where you require application publishing capabilities for the scenarios described above, you should use Web Application Proxy.

See Also

Planning to Publish Applications Using Web Application Proxy