If you are familiar with Web Application Proxy in Windows Server 2012/2016, Azure AD Application Proxy should not be your surprise. Microsoft builds it to allow you to securely set up a remote access to your application which you do not want to publish over the Internet. It also helps you achieve single sign-on (SSO) as well. This is fully aligned with “mobile-first, cloud first” strategy when business users have the ability to securely access their corporate applications hosted on cloud from their mobile devices in anywhere.

Azure AD Application Proxy acts like a reverse proxy in the language of network & computer security. For any sensitive-classified system you do not allow to access directly from the Internet, a reverse proxy works to forward (don’t confuse with Forward Proxy) incoming request from the Internet to your internal system. This is very similar like what I used to do during my time working with many Government agencies.

Not too much to explain here on what Azure AD Application Proxy is and how it works since you can read here: Azure AD Application Proxy Get Started

I’ve recently involved in troubleshooting for an application called Qlik Sense Enterprise  working with Azure AD Application Proxy. Qlink Sense Enterprise is supported in Azure AD and Microsoft did state that organizations are able to achieve SSO with Azure AD Application Proxy. Believe or not? The answer until comes when you practice and make it work. I had never worked with Qlik Sense Enterprise before getting engaged to look into the problem, including consultancy.

The customer did not want to publish the internal Qlik Sense Enterprise web application hosted on Azure VM over the Internet. Moreover the authentication service was required to run under port 4244 due to nature of the product. That said, they wanted to have a reverse proxy acting in front-end side to reverse incoming requests from the Internet to internal web application. I don’t know the actual context in whom suggested to use Azure AD Application Proxy in this case. But the ideal illustration looks like this:

In this case, the requirement was to use HTTPS Windows authentication which the default port was 4244. And this is part of Qlik Sense Proxy Service (QPS) we needed to implement. Ideally Azure AD Application Proxy would reverse the incoming request (https://proxy-qlik.abc.com) to the internal QPS (https://qlik.abc.com:4244). After a few times trying to configure, the implementation was still not successful even network security group to allow all incoming requests was created. Azure AD Application Proxy did not manage to reverse to the internal Qlik Sense web application which has authentication redirection. When I came to support, I realized that Azure AD Application Proxy after I entered credential redirected to the unresolved internal web application (you would see the DNS resolution issue in your browser). Changing to use Translate URL in Header setting still did not work.

I thought of IIS URL Rewrite to make a reverse after Azure AD Application Proxy to the internal web application. Ideally when a user browses the proxy URL then enters his credential, Azure AD Application Proxy redirects to IIS URL Rewrite server before the request is written to the internal web application. The incoming request can be rewritten from port 80 to non-standard port. I’ve done several cases for government agencies with Microsoft platform (e.g SharePoint) but never implemented for Qlik Sense Enterprise. The illustration looks like this:

Setting IIS and Rewrite URL is not hard thanks to Kudu tool. Ironically in this approach, I must set up a private VPN connection from my IIS website to the Qlik Web App VM to let IIS website be able to “see” Qlik Web App VM.

Refer here to do this case I mentioned above: Configure Virtual Network for your Azure App Service with VNET

This setup is pretty complicated and I did not chose this one. I then came to change from Azure App Service to an Azure VM hosting IIS and URL Rewrite. This machine must be in the same virtual network with Qlik Web App.

Everything seemed to work correctly from the Internet, redirected to IIS URL Rewrite VM before being reversed to the internal authentication service running under port 4244. But when I configured outbound rule for IIS Rewrite URL this did not work. The gateway did not accept the HTTP response content from internal web application.

I dig into more about how Qlik Sense Enterprise works, and even use Fiddler to capture HTTP Traffic to see whether I could copy a response content to set up outbound rule in IIS URL Rewrite. During my investigation, the customer created a ticket request to Microsoft Azure team. They did the same as mine, and they came to a conclusion that Azure AD Application Proxy currently was not supporting websocket protocol which Qlik Sense authentication service used.

Just my experience to be shared, as of this writing Azure AD Application Proxy is currently not supporting WebSocket protocol. Make sure if you are going to use it for your web application, it must not use websocket. NGINX would be a new alternative approach, but you have to be familiar with it. To be more specific to Qlik Sense, using Windows authentication seems not to work with any reverse proxy. The following threads may help you:

Do not propose to your customer Azure AD Application Proxy with non-Microsoft platform, until you practically have done it.