One of the best kept secrets in Azure is Azure Active Directory (AAD) Application Proxy. When exposing web applications running in Azure or on-premises, we all tend to look at services such as Azure Front Door or Azure Application Gateway, but this little gem can make the life of a network administrator so much simpler.
Firstly, as we will see later, you don’t need to expose any port in your network to the Internet to grant access to your applications for your users sitting in their home offices, and they don’t have to use VPN software either.
Not only network admins do not need to help users to configure and use client VPN software (I have been there, and it isn’t always pretty), but virtual desktop solutions will not be required either: if all your users need is access to web applications, why giving them a full desktop if a web browser will do just fine?
Secondly, you don’t need to work out complex authentication schemes for your apps, since AAD App Proxy has been designed from the ground up to be an authentication bridge between the Internet and the on-premises worlds.
And last but not least, due to the minimal additional infrastructure that AAD App Proxy requires, the complexity and security exposure of the solution is minimal, the dream of every administrator (at least it is mine).
One thing you should know is that you need Azure Active Directory P1 as a minimum, before you are able to configure it (see the AAD App Proxy FAQ for more on this).
Alright, enough talking, let’s get into it. But before we deep into App Proxy, let’s have a look at other reverse proxy solutions in Azure.
Reverse proxies in Azure
You might already be familiar with other reverse proxy technologies in Azure, such as Azure Front Door or Azure Application Gateway. A reverse proxy is essentially “something” that sits in front of your web servers, that performs some operations on the HTTP traffic before handing it over to the actual server:
The main difference between Front Door and Application Gateway from a network topology perspective is that while Front Door is deployed in a set of locations managed by Microsoft, Application Gateway is injected right inside your Virtual Network. The architecture remains pretty much the same for both though: the client accesses the reverse proxy, who does some magic with the packets, and then the reverse proxy goes to your web workload.
The concepts are very similar with Azure API Management, only that in this case you can deploy the API gateway (the reverse proxy component of the service) both inside and outside of a Virtual Network:
You might be thinking “that is a lot of options”, and I didn’t even come to AAD App Proxy. And you would be right, however I am going to beg you to bear with me, further down I will discuss briefly when to use which service.
AAD Application Proxy changes the model just a little bit, by splitting the reverse proxy in two components, the portal and the connector:
If you think about it, the architecture still hasn’t changed: the user goes to the reverse proxy (to the portal component), the reverse proxy goes to the web workload (from the connector component). However, by splitting the reverse proxy into portal and connector, magic happens. The most important one is that the connector communicates with the portal via outbound requests, without any need to open inbound ports in your network. This makes App Proxy very interesting when exposing on-premises applications, since no special firewall configuration is required (outbound access to port 443 is usually open in many organizations):
The architecture is the same as in the VNet example, but here both the connector and the web workload are on-premises. Of course, hybrid designs where the connector is an Azure Virtual Machine and the web workload is on-prem are possible too.
If you are asking yourself about scalability and redundancy, that is a great question: for the Portal component, Microsoft has your back, there is nothing you need to do there, and you are covered by AAD SLAs. For the Connector component though, it is recommended that you deploy at least two VMs for redundancy, and potentially more for scale out if you have a lot of traffic. You can as well dedicate specific connectors for certain applications, to reduce the blast radius of a connector failure.
The connector is a Windows VM
I have to admit this one got me thinking: why would the connector be a Windows VM, and not something easier to deploy such as a virtual appliance or a container? Two reasons I can think of:
- You want to be able to deploy the connector in any cloud (Azure, AWS, GCP and on-premises). Since everybody should know how to deploy Windows servers on their platform, and the connector is relatively easy to install, this sounds like a good idea.
- More importantly, the connector might need to participate in your on-premises authentication scheme. If that is Active Directory, you would need some administrator privilege to make it join your domain, and the fact that you have full control on the OS comes handy. Which takes me to the next point.
App Proxy is an authentication proxy
One of the most useful features of web proxies is acting as an authentication proxy. For example, I wrote some time ago about how to use Ambassador as authentication proxy for web workloads running on AKS. Why is this important? Well, your application might not (properly) implement authentication, and you might not feel like investing coding cycles on something that others already do. So you can delegate the authentication bit to your reverse proxy, and your web workload will focus on serving its wonderful content.
The neat thing about AAD App Proxy is that the proxy is broken in two components, as we saw above: the user-facing Portal in the public Internet, and the server-facing Connector inside of your network. Hence, it can bridge both authentication worlds together, making possible scenarios like using SSO on the user-facing authentication, and Kerberos on the server-facing side:
AAD App Proxy as authentication proxy
The Test
So here we go, let’s see what this all looks like: I have an application running on my Azure VNet with no authentication and using HTTP (no encryption) on port 8080. I want to use App Proxy to provide secure connectivity (HTTPS and authentication) for users over the public internet. Here my setup:
Below you can see the screenshot of a user accessing the app via App Proxy after authenticating. My application is a simple API that gives back some data about the request, such as the source IP of the packet or some HTTP headers:
By the way, if you would like to use this sample application for your testing, you can find it in my Github repository: it is a very simple Python Flask application.
As you see, App Proxy behaves like any reverse-proxy adding the client’s IP address (93.104.172.38) to the X-Forwarded-For header. The source IP address that the web server sees is the one from the connector (172.16.2.4). The server still has access to all usual HTTP headers such as the agent (Edge in my example) or the OS (Windows).
My virtual network does not have to allow any incoming access, since the only required access from the connector is outbound. The hostname and path visible from the web server are coming from the connector (“testserver:8080”), not from what the user actually typed in their browser bar.
Additionally, since the portal component of AAD App Proxy authenticated the user, you can pass on login information on to the application in the form of HTTP headers (see Header-based single sign-on for on-premises apps with AAD App Proxy for details on how to configure this). Note the headers “Givenname”, “Surname” and “Username” in the following screenshot, which were injected by AAD App Proxy upon successful authentication:
Authentication claims can be passed on as HTTP headers
When to use which proxy?
We have seen now how AAD App Proxy works, so when to use each of the reverse proxy options that Azure gives you? This is a very simplified view, but hopefully it can help you in reducing the options for your requirements:
- Azure Front Door offers CDN features for better performance as well as WAF for increased security, so it is great for public, global applications.
- Azure Application Gateway also includes WAF as option, and it is a regional service deployed inside of a virtual network, so it is perfect for single-region deployments. Additionally, the Application Gateway Ingress Controller offers a great integration with Kubernetes.
- API Management is conceived for exposing APIs and has very flexible functionality around manipulating requests and answers, plus it supports authentication proxy and throttling amongst many other things. The fact that it can be either deployed on a virtual network or in a public endpoint makes it a very versatile service. It does not include WAF, so it is often combined with either Front Door or App Gateway
- AAD App Proxy has very unique features: supports outbound access from the web workload (instead of inbound as most other reverse proxies), and has great functionality around authentication proxy.
For sophisticated requirements you might want to deploy two or more of these options. For example, Integrate API Management in an internal virtual network with Application Gateway explains how to deploy an App Gateway in front of an APIM gateway to increase security for public access to APIs.
Another common requirement is integrating AAD App Proxy with App Gateway’s WAF, to provide Web Application Firewall to internal applications. The setup to access an on-prem application might look like this:
Of course, chaining reverse proxies will increase application latency and cost, so make sure that the overall topology satisfies your application requirements and constraints.
TL;DR
Hopefully this post gave you a better idea of what AAD App Proxy is, and how you can use it to expose over the Internet applications that were not designed for that, either because they lack HTTPS support or proper authentication functionality. Thanks for reading!