A missing piece in the Azure Application Proxy but there is hope
At the time of writing, the Azure Application Proxy makes it easy to pubish an on-prem web application to Azure. There are tons of resources explaining how to do that and it is a straightforward process.
The published application is therefore accessible via an External URL to which an Internal URL is mapped. The proxy makes its job and providing you setup a correct kerberos constraint delegation in your on-prem system, the identities are correctly transfered as well. This all works great ....with a browser. What if you try to consume the published resource from a webapi or from a mobile service? Well, today, there is no API to do this.
So there is a missing piece somewhere. I thought I had found something until I realized this was not working. The idea was simply to use ADAL to get an Access Token for the proxy resource and try to attach the Authorization header to any subsequent request targeting the external URL. I was quite execited because I managed to get that token via ADAL.
Indeed, to do so, you simply:
- Create an AAD Application to which you add the Proxy AAD Application
- You set the "Access" delegate permission
- You get a token via ADAL with your AAD Application
and guess what, you get an Access Token but it isn't usable against the external URL because the proxy just ignores it. The best evidence is to add an invalid token on purpose and you'll see that the proxy will keep redirecting you to the login page and will not complain about an invalid token. So, the hope is that Microsoft will work on getting Application Proxy AAD Applications similar to the other AAD Applications, meaning that you can consume on-prem resources by passing a Bearer token and let the proxy make the magic to convert that token into a kerberos ticket.
That would give us a single way to authenticate and authorize users against online and on-prem applications.