Experimental – Using Azure Function Proxy as Authenticating Reverse Proxy for NodeJS Docker App

Disclaimer: Azure Function Proxies are meant to act as proxies for functions itself, and as aggregators of microservice style resources/API’s near the function proximity. If you need an actual reverse proxy, or full blown API gateway, then solutions such as Azure API management, Azure AD App Proxy, Azure App GW, Kemp VLM, or just placing NGINX on your container might be the the right pick.

Now as the disclaimer is out of the way I can continue experimenting with this excellent feature without of having any kind of business justification

My inspiration came from MS’s similar article which covers using function proxy route to publish a certain part from wordpress. My angle was to see if the same approach can be used with App Service Authentication.

Obvious caveats

• This is not necessarily the way this feature intended to be used 🙂
• cold start of any function type solution. (Maybe do the same with App service web app)
• If you are running docker image, then why not run it in the app service in the first place?
  • If the app is something else than docker image and likes to live on a VM, then this approach might still be of interest

Obvious benefits

• Deploy your reverse proxy, or API gateway and rules of the solution as code
  • Functions is not the only solution to support this approach certainly, but functions integrate with VScode and CI/CD solutions. You end up having your solution entirely defined as re-deployable code)
  • Setting reverse proxy rules as example

• Alternative approach for Single Page App /Static website, where function is acting as middle-end aggregator for certain tasks that are better handled outside of the browser due to possible security concerns
  • Don’t get me wrong here… I believe you can make perfectly secure SPA’s, and looking at JAMStack, and new Azure Static Web Sites offering, it seems that we are also heading that way 🙂

Background

• I’ve written about App Service in another article. The article covers different subject but highlights important properties of the VNET integration feature on app service
• I’ve written few articles about Azure AD App Proxy and API management, which might suit better for actual production use cases
  • Concept: Publish on-prem API using AAD App Proxy and API Management with Azure AD JWT Bearer Grant
  • Azure API Management – JWT validation for multiple Azure AD partner registrations

Test environment

• 

• Azure VM
  • running NodeJS Express app docker image baked in VSCode’s insanely good docker extension environment
  • In the same VNET as the App Service Plan
• Function
  • In the same VNET as the Azure VM running the docker image

• 

Test results

• Sign in to the application works on fresh authentication
  • After fresh authentication the session is maintained by app service cookies

• When there was existing session on Azure AD the authorization flow for this App Resulted in HTTP error 431.
  • If there was actual use scenario I would debug this further and possibly create another re-directing function to ingest the token which would drop the proper cookie for the subsequent sign in

• I haven’t tested if there are possible issues with advanced content types, I would expect that the proxy function forwards the back-end responses content-type (maybe test for another blog)
• From the TCPDump trace running the DockerVM you can see the internal IP of the App Service
  • 07:22:53.754245 IP 172.30.10.29.54044 > 172.30.10.36.8080: Flags [.], ack 218, win 221, options [nop,nop,TS val 104639808 ecr 1486010770], length 0

• 

Ideas for next blog?

Some delicious continuation tests for this approach could be:

• Based on the internal headers created by the EasyAuth module:
  • Create poc for Native and Single Page Apps using Authorization Header
  • Create test scenario for using internal B2C authentication (I have app ready for this)
  • Add internal proxy routes to perform further authorization rules
  • Forward Authentication tokens, or username headers to the docker back-end application by defining the proxy application as external redirect target, or by using the internal function methods

Till next time

Joosua