The Web Application Proxy Overview
You must have heard about the new role in Server 2012 R2, the Web Application Proxy, and you must be probably thinking at this point “What is this thing, and why do I even care”? Furthermore, if you do care, you may wonder, what’s it going to take to set up this web application proxy?
The Web Application Proxy (WAP), is a new role in Windows Server® 2012 R2® that is designed to perform two functions: One, is to provide a reverse web proxy for publishing internal web applications, and two, to function as a federation services proxy for issuing and validating federation claims for external users.
If this all sounds complicated, just bear with me, it will all make sense shortly.
Web Application Proxy
As mentioned, the Web Application Proxy is a new role with Windows Server 2012 R2, and is used to enable access to internal or SaaS based web applications for remote users and business partners. These applications can be as varied as Microsoft Exchange Outlook Web Access, SharePoint Server, web-based line of business applications, or even mobile applications, for devices based on Windows® 8, iOS and Android™.
The reverse proxy function acts like any other traditional web reverse proxy, with the WAP acting as the middle man for authenticating and authorizing users and devices, retrieving content from application servers, and performing protocol and URL translation functions.
The WAP can authenticate users to their internal applications through several methods. It can perform Kerberos constrained delegation, basic authentication, REST OAUTH for mobile device applications, pass-through authentication, MS Office Application Authentication, as well as federation-based authentication
For those of you familiar with AD Federation Services (AD FS), the federation proxy role acts much as it did before Server 2012 R2.
For those of you unfamiliar with federation services, or who think AD FS is a four letter Klingon word, worry not. AD FS is The Microsoft® implementation of Web single-sign on (SSO) using current federation standards (SAML and WS-Fed).
A federation proxy server typically resides in the DMZ, and is used to authenticate and issue claims to remote and mobile users. It may or may not be a member of your user domain, depending on authentication requirements.
WAP Requirements and Setup
Implementation of the Web Application Proxy role setup can be either a simple, or complex, depending, as most things in life, on your requirements. Most importantly, the Web Application Proxy requires you to either have an existing AD FS infrastructure, or to implement an AD FS infrastructure based on Server 2012 R2, as all the configuration storage is stored within AD FS.
First, you will need our Celestix Cloud Edge Security Appliance Solution. Our solution is a preconfigured Windows Server 2012 R2 platform with a web based management framework to install and manage AD FS. A set of appliances will need to be installed in the production Active Directory environment, and a second set in the DMZ environment for remote users. The DMZ set can be configured with either public or private IP addresses.
Second, you will need to install and configure the AD FS role in Server 2012. You will need to go through the wizard driven configuration, and provision your certificates and service accounts.
Lastly, once the internal AD FS servers are configured, you can then install the WAP role on the DMZ appliances, and configure the role with the appropriate certificates, service account, and connect them to the internal AD FS servers.
The Web Application Proxy can be configured in a high availability scenario, using either the Microsoft Network Load Balancing service, or using an external hardware load balancer.
Once the steps outlined above are complete, your AD FS and WAP infrastructure is set up, and ready for use. Of course, this is a very simple set up designed for publishing internal applications. If you need to federate with SaaS or other resource providers, then you will need to plan your infrastructure accordingly.