Azure Application Gateway with APIM Internal Mode: Set Up Part 3 (Exposing Developer Portal on Internet and using path-based routing for external API in Application Gateway)

We are going to change only the Developer Portal details so that we can access it through Application Gateway from the Internet. No change is required on API Manger Gateway as we have tested that from the Application Gateway.

There is an issue that we cannot use the same RootCA certificate for the Gateway and Developer Portal as one RootCA can cater to only one backend. We must change the RootCA certificate for the Developer Portal so that we can expose it. So, we will keep the old RootCA certificate for the Gateway and create a new RootCA and SSL cert for the Developer Portal, but we need to make sure that we don’t change the FQDN which is devportal.demo.com as we have used the same name in Private DNS Zone.

Create a new RootCA and SSL certificate:

• Let’s follow the same process I used in the first part of the blog.

C:\Work\study\APIM\demo\portal>openssl req -x509 -newkey rsa:4096 -keyout portal.key -out portal.crt -days 365 -nodes
...+.+..+...+....+.....+...+....+++++++++++++++++++++++++++++++++++++++++++++*.+......+............+........+...+....+++++++++++++++++++++++++++++++++++++++++++++*..+....+...+...+...+.....+.........+...........................+....+..+..........+.........+.....+...+.+.....+.........+...+..........+........+......................+.....+++++
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:NZ
State or Province Name (full name) [Some-State]:Wellington
Locality Name (eg, city) []:Wellington
Organization Name (eg, company) [Internet Widgits Pty Ltd]:student
Organizational Unit Name (eg, section) []:student
Common Name (e.g. server FQDN or YOUR name) []:fabrikamportal.com
Email Address []:

C:\Work\study\APIM\demo\portal>openssl pkcs12 -export -in portal.crt -inkey portal.key -out portal.pfx
Enter Export Password:
Verifying - Enter Export Password:

C:\Work\study\APIM\demo\portal>openssl req -newkey rsa:4096 -out demo.csr -keyout demo.key -nodes
...+....+..+.............+..+..........+...+.....+.+.....+.+........+.+............+....................+...+++++++++++++++++++++++++++++++++++++++++++++*...+....+.....+.+..+...+....+...+...+...+..+...+......+...+.+..+.......+......+..+.......+.....+...+..........++++++++++++++++++++
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:NZ
State or Province Name (full name) [Some-State]:Wellington
Locality Name (eg, city) []:Wellington
Organization Name (eg, company) [Internet Widgits Pty Ltd]:student
Organizational Unit Name (eg, section) []:student
Common Name (e.g. server FQDN or YOUR name) []:devportal.demo.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:password
An optional company name []:

C:\Work\study\APIM\demo\portal>openssl x509 -req -in demo.csr -CA portal.crt -CAkey portal.key -CAcreateserial -out demo.crt -days 365
Certificate request self-signature ok
subject=C = NZ, ST = Wellington, L = Wellington, O = student, OU = student, CN = devportal.demo.com

C:\Work\study\APIM\demo\portal>openssl pkcs12 -export -in demo.crt -inkey demo.key -out demo.pfx
Enter Export Password:
Verifying - Enter Export Password:

C:\Work\study\APIM\demo\portal>

    Commands:

• openssl req -x509 -newkey rsa:4096 -keyout portal.key -out portal.crt -days 365 -nodes
• openssl pkcs12 -export -in portal.crt -inkey portal.key -out portal.pfx
• openssl req -newkey rsa:4096 -out demo.csr -keyout demo.key -nodes
• openssl x509 -req -in demo.csr -CA portal.crt -CAkey portal.key -CAcreateserial -out demo.crt -days 365
• openssl pkcs12 -export -in demo.crt -inkey demo.key -out demo.pfx

Update the new SSL cert for the custom domain in the API Manager instance.

• Follow the same process I did in the first part

• Click the save button, it will take some time to get updated once done we will test the Developer Portal from the VM

• The certificate is saved now, let’s try to access the developer portal from the Virtual Machine.

All looking good from the VM, and we can access the developer portal after changing the certificate.

Open Application Gateway and add a new Listener for Developer Portal

Create a new listener for the portal with the below details, I am using port 80 to keep things simple

• Click on save
• Update the backend pool with the below details and make sure you use devportal.demo.com on your FQDN which we configured

Add Backend Setting:

Add a backend setting like the below details

• Change the certificate extension from .crt to .cer and upload it. This should be RootCA cert we just created for the developer portal

Your setting should be similar below

Add Rule:

• Add a new Rule for the Developer Portal
• Select PortalListner

• And update the Backend target and Backend Settings

• Click Save.

If all good, then you should be able to see your developer portal exposed on http port 80 over public IP address, let’s test this out

The developer portal is now exposed successfully.

Your Backend Health must be healthy as mentioned below.

Expose External APIs using path-based routing in Application Gateway.

I will be creating a separate blog for path-based routing, but at a high level what we do, I have written here

We have everything we need now, to secure internal and external API we can make use of path-based routing. For example, we have 2 below APIs running on VM and we want to expose only one API to an external vendor and want to keep one for internal.

·       https://<host_name>/api/produc

·       https://<host_name>/api/employee

We must create an API proxy for each service on API Manager with the below URL

 

API Management Proxies:

·       https://<host_name>/internal/api/product

·       https://<host_name>/external/api/employee

 

We can now create path-based routing for external API

Open Application Gateway

• Delete the existing External Rule
• Add new External Rule

• Add path-based setting

• Give /external/* value in the Path which makes sure that all the API which has the external keyword in the URL can be accessed from Application Gateway

• Click add

• We can now provide details of this API to external customers and publish it through Developer Portal

Azure Application Gateway with APIM Internal Mode: Set Up Part 2 (Adding Application Gateway in VNET)

We are trying to replicate the above architecture design. As I mentioned in my previous blog, 1st part of the same architecture here, this architecture can cater to most of the current industry demands where developers can orchestrate internal APIs or On-Prem APIs. They can secure internal APIs with the API manager instance which is running inside a virtual network and if a developer needs to expose APIs for the business needs for the 3rd party vendor, they can do that too by using an Application Gateway. 

As Application Gateway is a layer 7 load balancer, we can decide what traffic we want to come inside and what to block.

In the first part, we created below resources:

• Virtual Network 

• API Manager inside a virtual network with a specific subnet

• A Virtual Machine

• An API inside the virtual machine

• An API proxy on API manager and pointed that to VM’s API

• We also successfully tested our API internally from the API manager

Architecture Diagram:

Step 1: Create an Application Gateway resource 

• Create an application gateway resource as mentioned below

• We want to keep very basic so won’t be selecting Auto Scaling or Availability 

• Click next to put frontends details
• Create an app-gw-public IP and put a private IP in the same subnet 10.0.2.10

 

Click next to add Backends as mentioned below

• Give the Backend pool name

• apim-backend-pool

• API Gateway FQDN – api.demo.com

• Click next to add Routing Rules

Add routing rules and fill in the below details

• Add Rule

• Add Listener

• I am keeping it simple and using frontend with HTTP on port 8080

• Add backend target details

• Add Backend setting

• Once done it should be as below 

• Click the tag and create it. We will configure for internal IP later or part 3

After adding the setting, one more setting is required which is important.

• Click on “Health Probes”
• Give “/status-0123456789abcdef” in path
• Choose the backend setting as HttpSetting
• Click Test and Add

• You can check the "Backend Health", it should be green if all is good.

Testing:

I am hitting the application gateway’s public IP address with an 8080 port from my machine and getting the expected result

This request is going via the Application gateway to the API manager to Virtual Machine (where we have created an API)

Internal Listener Setup:

Since Internal and External can’t listen on the same port, so using the 443 port and uploading a wild card cert for the same that I used in the API Manager custom domain, fill out below details 

• Use Private IP in Frontend IP
• Port: 443
• Give any name in my case its gatewaycert
• Upload .pfx cert
• Provide password which was used during certificate creation
• Click on Add

Provide below routing details

• Choose Internal Listener this time
• Give priority number I have given 10
• Click Add

Provide Below details for the Backend Targets

• Choose same apim-backend-pool
• Choose same HttpSeting as our backend is going to be same
• Click on Add button

We have now configured everything, let’s test this out from the Postman

• Login to the VM that we have
• Try with Private IP Address this time, other URL parameter will remain same
• You can see the expected result as mentioned below

We have demonstrated that we can now access the Application gateway inside the virtual network. The above request is flowing through Application Gateway to API Manager to Virtual Machine

We now might have another requirement where we have to expose our APIs to the 3rd party vendor. for that, we have exposed our developer portal to the Internet so that our vendor can access those APIs. Let’s expose our developer portal on internet in our next blog here

Azure Application Gateway With API Manager Internal mode: Set Up Part 1

 

This is one of the famous design patterns we are going to set up. We will put API Manager inside a virtual network so that we can secure our internal APIs. Since it is going to be inside the virtual network, we can have all the connectivity inside de Virtual network and On-Premise with the help of Express Route. In the API world, we also need to expose our APIs outside of the network so that our external vendor can connect with these APIs. To achieve that we will be putting Application Gateway in front of API Manager and will expose only those APIs which are required. 

Architecture Diagram:

Based on the above architecture diagram, we will create an API inside the VM, and this API will be treated as an internal API. We will put API Manager and Application Gateway inside the virtual network. This is going to be a lengthy process so make sure you have enough time to complete the setup.

If you are working in the office and trying to set up, then grab a coffee.

If you are working from home and setting this up for learning, then grab a few beers 😉

From step 1 to step 5 you can create resources parallelly then you need to wait for another process to complete. Let’s get started…

Step 1: Create an APIM instance with Developer SKU

Step 2: Create a Virtual Machine for our backend

·       Create a VM, this will be treated as backend internal services for the APIM. When we create this VM it will give us some other resources like interface, public IP, VM, Virtual Network, etc. We will use the same virtual network for APIM. Let’s complete this task parallelly while our APIM is getting ready

·       On the network tab I am updating the virtual network name and creating 3 subnets,

o   apim-vet                       :           virtual network name

o   backend-subnet            :           subnet name

o   apim-subnet                  :           subnet name

o   app-gw-subnet             :           subnet name

·       We need 2 separate empty subnet one for API Manager and another for Application Gateway, which is required.         

 

·       Click review and create and click create.

Step 3: Create an API inside the VM:

Let’s create a dummy API inside backendvm and test it. Same API we will call from API Manager so that we can test our API manager in internal mode and later same API will be called from the application gateway to test end to end

      ·       Install IIS server

·       Put a json file inside “C:\inetpub\wwwroot\test”

You can choose any method to create an API

·       I have installed the Postman inside the VM.

·       I have given a test as mentioned below our API is working as expected

·       We will create a proxy of this API in API manager.

Step 4: Create a network security group for API Manager:

 We now create a security group for the API Manager, we will attach this security group to “apim-subnet”. We will then put some inbound and outbound rules so that API Manager can talk to internal API and can be reachable on specific ports.

      ·       Go to Subnets and associate” apim-vnet” and “apim-subnet” to it as mentioned below.

·       Add Inbound Rules

·       Add any internet connection to reach ports 443 and 80 inside the virtual network

·       Add API Management.AustraliaEast (location for the API Manager) to reach to virtual network on port 3443

·       Add one below outbound rule

These above 4 steps you can do while creating an API Management instance. Now wait if your API Manager is not yet ready.

Once your API Manager instance is ready it should be like the below. This should currently have connectivity from the internet.

Step 5: Put this API Manager in the virtual network:

·       Go to Network and choose Internal Virtual network and select “apim-vnet” and “apim-subnet” as mentioned below.

·       Click apply and save it. It will again take some time to complete.

    ·       Once completed then you can see the private IP of the API Manager as above

Step 6: Create RootCA and SSL self-signed certificate

Execute the below commands one by one. We are creating RootCA certificate and then creating SSL certificate. Our SSL certificate is a wildcard certificate which is why we have given its name *.demo.com and RootCA certificate with the name fabrikam.com

·       openssl req -x509 -newkey rsa:4096 -keyout fabrikam.key -out fabrikam.crt -days 365 -nodes

·       openssl pkcs12 -export -in fabrikam.crt -inkey fabrikam.key -out fabrikam.pfx

·       openssl req -newkey rsa:4096 -out demo.csr -keyout demo.key -nodes

·       openssl x509 -req -in demo.csr -CA fabrikam.crt -CAkey fabrikam.key -CAcreateserial -out demo.crt -days 365

·       openssl pkcs12 -export -in demo.crt -inkey demo.key -out demo.pfx

·       if the password is asked while creating the cert, I have given “password”

      You will 2 certificates one is for Root CA and another SSL certificate is signed by Root CA

     The complete step looks like this below:

C:\Work\study\APIM\demo>openssl req -x509 -newkey rsa:4096 -keyout fabrikam.key -out fabrikam.crt -days 365 -nodes

....+..+.......+...+..+..........+...........+....+.....+......+....+.....+......+.+...........+....+......+.....+....+.....+....+++++++++++++++++++++*..................+..+.......+..+....+..+.............+++++

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:NZ

State or Province Name (full name) [Some-State]:Wellington

Locality Name (eg, city) []:Wellington

Organization Name (eg, company) [Internet Widgits Pty Ltd]:student

Organizational Unit Name (eg, section) []:student

Common Name (e.g. server FQDN or YOUR name) []:fabrikam.com

Email Address []:

 

C:\Work\study\APIM\demo>openssl pkcs12 -export -in fabrikam.crt -inkey fabrikam.key -out fabrikam.pfx

Enter Export Password:

Verifying - Enter Export Password:

 

C:\Work\study\APIM\demo>openssl req -newkey rsa:4096 -out demo.csr -keyout demo.key -nodes

..+.+...+..+++++++++++++++++

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:NZ

State or Province Name (full name) [Some-State]:Wellington

Locality Name (eg, city) []:Wellington

Organization Name (eg, company) [Internet Widgits Pty Ltd]:student

Organizational Unit Name (eg, section) []:student

Common Name (e.g. server FQDN or YOUR name) []:*.demo.com

Email Address []:

 

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:password

An optional company name []:

 

C:\Work\study\APIM\demo>openssl x509 -req -in demo.csr -CA fabrikam.crt -CAkey fabrikam.key -CAcreateserial -out demo.crt -days 365

Certificate request self-signature ok

subject=C = NZ, ST = Wellington, L = Wellington, O = student, OU = student, CN = *.demo.com

 

C:\Work\study\APIM\demo>openssl pkcs12 -export -in demo.crt -inkey demo.key -out demo.pfx

Enter Export Password:

Verifying - Enter Export Password:

    

·       Change the extension of .crt to .cer for the RootCA certificate

·       Below files are created

Step 7: Private DNS ZONE

Create a private DNS with the “demo.com” name. This part is very important in terms of its name because we have created certificates for the same demo.com name. API Manager inside VNET can’t be reachable with private IP so we must create a portal and gateway private DNS so that we can connect to it.

·       Let’s create one for the API gateway and another for the developer portal. We will access them with this FQDN.

o   api.demo.com – API gateway

o   devportal.demo.com – Developer portal

·       Below is one for the developer portal

·       Click on the Virtual Network Link to link apim-vnet with this private DNS Zone

·       Give any name you like, I have given apim-vnet-link

·       Finally, it should look like the below screenshot

Step 8: Update Custom Domain in API Manager

The default custom domain comes with it. We must add 2 custom domains one for the API gateway and another for the developer portal. This domain name must be the same as what we created in the private DNS zone and cert for that from an open SSL script

·       Create one for the Gateway and give “api.demo.com” and upload the certificate in .pfx format. Password is password (you can choose your own)

·       Create one for the Developer Portal and give “devportal.demo.com” and upload the certificate in .pfx format. Password is password

·       Final custom domain, click save again it will take some time

·       Click on the save button, this will take again some time

·       If all is good, then you can see your developer portal and Gateway URL will be changed to the new custom domain

Step 9: Create an API in API Manager and point its backend to the backend VM’s API

·       Click on the API menu and add an API “Internal API”

·       Backend is private IP with API URL

o   http://10.0.0.4/api

·       Add base URL suffix

o   Product.json

·       Add an operation with the below details

·       Click save. Since it is an internal URL and we have given private IP as a backend. Let’s test this from Backend VM.

Step 10: Testing:

·       Login to VM

·       Open “https://devportal.demo.com” URL in the VM browser, you will see that you can reach the developer portal

·       Test the API that we have created (however this API is running in the same VM only, but the request is coming via API Manager)

·       This gives a successful result.

·       This concludes that API Manager is working in internal mode successfully

 

Our next step is to add Application Gateway before the API manager so that we can also reach from the Internet.  Let’s complete that in part 2 here.