The myth of Azure Application Gateway – Part 2

In part 1 of this article I have gone through creating Azure Applications Gateways (AGW) using Powershell which is a powerful way of deploying resources on Azure, using recursive functions and methods you could build a complex solution in few lines. Unlike Powershell, JSON is a static solution. It gives you a way of creating a baseline deployment, I still haven’t found a way of controlling sub-resources (which isn’t governed by the JSON Copy() function).

In this article I will go over the same deployment using a JSON template, this only serve as a reference point for your deployment. I will use the same Azure AGW configuration I used in part 1 to keep both deployments consistent.

When building Azure AGW, same prerequisites apply to the JSON method. There is a subtle difference which I will go over when I get to that point.

So this time I have prepared a Visio diagram to simplify our deployment and understand what we are trying to achieve – see below.

The diagram shows a Web server hosting four websites running a combination of HTTP HTTPS with authentication (using Basic authentication) or Anonymous access.

The only thing different in comparison to previous Powershell deployment is the steps we take to process SSL certificates and passing them over to the JSON template.

The above steps will ensure SSL cert is passed on based on Base 64 Binary which is what is expected by the JSON parameter.

As part of the deployment I have also created a custom probe that target an HTTPS site which accepts anonymous authentication, otherwise the default probe would fail causing the whole site to be unavailable. Custom probes are a good way in overcoming issues around sites that require NTLM or basic authentication (but not form based authentication).

Make sure your Application Gateway can talk to the backend server, if you have firewalls or even IIS Request Filtering could cause the connection to fail, ensure appropriate ports are allowed both ways.

So without further ado I have attached the full code below for your leisure ….

I know I haven’t written a detailed article around how each section of the JSON template code work together. I have tested this code in my own environment and I know it works for the web server I have for the backend. If you require help using the above template, please hit me with a message and I will try to clear some of the information around the code and usage cases.

Need one help, I want to provide the PFX file using above template, if I convert the PFX to base64 then how i can proivde it in parameter. Actually i have not tested yet , but the confusion is, 1)after converting the pfx to base 64 it will be text file or just a string?
2. If it is string then i can easy pass it thorugh VSTS pipeline or parameter file, but if it is text file then how i can pass it to template.

Thank you for your message.
The JSON script expects a .pfx file and not a string, You should add this file to your VS project before you start referencing it in your code.
I don’t use VSTS for deployment but I used GitHub in the past and by ensuring the file lives within your project boundaries then you could always reference it from that same location, or if you are making it available using some other methods then you could always specify the URI to that file.

let me know how you get on and if you need any further assistance with this.

I am working on somewhat same config deployment.The problem that i am facing is the password for the pfx file after conversion to base64 does not work out. it errors out with below message:
Error: Code=ApplicationGatewaySslCertificateInvalidData; Message=Data or Password is invalid.