In my years of working with Azure I always find that Azure AD Application Proxy is a some kind of a hidden gem. Not everyone heard about that and even less people worked with it.
What is the Azure AD Application Proxy?
It is a service which expose your internal/on-premises application through Azure services with added Azure AD authentication. In order to do that, it has two components:
- Application Proxy Service in Azure
- Application Proxy Connector on server in your network.
How it is working?
Official Microsoft documentation has following picture:
Steps are:
- User who is trying to access the application is asked to perform authentication through Azure AD.
- After successful sign-in user receives a token.
- Token is provided to Application Proxy Service which sends request to Application Proxy Connector.
- If SSO is configured, Connector is going to handle additional authentication.
- Connector sends request to required webservice.
- Response is returned to user.
You might say that you still have to have connectivity between App Proxy Service and App Proxy Connector. And you are right, but not quite.
The beauty of Azure AD Application Proxy.
Great piece here is that you don’t need to allow inbound traffic to your Application Proxy connector. All connections will be initiate from your Application Proxy Connector to Application Proxy Service. Once again, no inbound connection, only outbound.
That would make everyone in your cybersecurity department very happy.
On top of that, because you will have Azure AD authentication as a first step, you can use the power of Azure AD Conditional Access to protect this workload by having requirements for connections, such as use of compliant device.
How this is working?
At the moment of configuring everything on Azure side, you will create address for your application in the address space msappproxy.net and provide your internal address. In this way users will be connecting using external address and App Proxy Service will check which App Proxy Connector group corresponds to this app and send request to them.
As you noticed, i mentioned new concept – App Proxy Connector Group, which is basically a group of servers in your network which you designate to balance requests for your application and help in case of failure of one server, because requests will be distributed between other servers in the group.
Also, now there are more complex concepts, like adding Front Door and Traffic Manager, using custom DNS, but for them I would advise to look for official documentation.
What is the catch?
Well, I found two major flaws or issues:
- Hard connectivity limits which are not advertised widely.
- No way to monitor service out of the box.
For connectivity limits you can not have more than 500 requests per second per app and 750 requests per tenant. Users with requests on top of this limit, will get error 429 (too many requests).
For some reasons this data is buried in Azure AD service limits
For monitoring, there is just no built in ways to monitor state of connectors and number of requests, so you just have to believe in everything working without issues, or built your own monitoring solution.
Should you use it or it is too bad?
I would definitely advise to use it for some internal corporate applications (especially if they are not mission critical) and quick proof of concept. It is not suitable for some high load applications, but for typical internal corporate apps you should not hit limit of connections.
And as I mentioned, you are not just exposing your internal website, instead you can cover it with the whole tools set of Azure AD identity protection, including Conditional Access.
Alex Vanyurikhin 