Securely Exposing Dynamics NAV SOAP Services to External Client Applications using Azure AD App Proxy
When working with Dynamics NAV ISV applications, you'll routinely be asked by vendors to expose NAV's SOAP service to the internet. This should make you feel uncomfortable.
Thankfully, leveraging the Azure Active Directory Application Proxy makes this much more secure, and saves having to configure any additional infrastructure on-premise which may require thinking about DMZs and unruly firewall rules.
A little background info...
If you aren't familiar with Azure's App Proxy service, see my post about configuring it for general web applications here. It's a good introduction to it. This article goes on to assume that you have a functioning Azure AD App Proxy connector service running in your environment.
I'll also make the assumption that you have a Dynamics NAV 2016 or newer service tier configured with an SSL certificate thumprint installed such that SSL can be enabled on the SOAP services.
...and A note on SSL...
Secure everything with an SSL cert. Everything you can, that is. Vendors will always seem reluctant to support your security aspirations, but at the end of the day it's your environment. I've set the policy within my IT environment that everything we do - be it a custom web app over HTTPS or an ERP platform like Dynamics NAV - it will be secured with an SSL certificate (in our case, our wildcard certificate upon which we secure a lot of friendly subdomains with).
1. Configuring the Dynamics NAV Service Tier
Ensure Enable SOAP Services is checked and, per the above, I recommend checking Enable SSL and configuring the tier to support it.
I recommend configuring a friendly DNS name for your SOAP service. It's not required, but it keeps things simple and tidy compared to IP addresses or server names. I use friendly DNS names wherever I can. It makes things easy for my users and adds a polished look to your environment(s).
I use a .com suffix which let's me create internal subdomains like "subdomain.mydomain.com" which are easy to remember and immediately indicate what they are for.I'm creating this tier on a staging server, and so I've created an A record called navstgsoap, pointed it to my staging server's IP and then configured the SOAP Base URL to it, such that it reads (hypothetically) https://navstgsoap.mydomain.com:7147/ServiceTierName/WS/.
Authentication type of the user, and whether you require a Web Service Access Key will depend on the Credential Type of your service tier. If you're using Access Control Service (ACS), you will need to generate a web service access key and use that in the client application that is accessing the NAV data. For the Windows Credential type, a regular username/password combo will do, though you can choose between a Windows user or a NAV user.
See Figure 1, below.
Now, test access to the SOAP services (internally). You'll need a published NAV Web Service to do this properly. I'm using a Jet Professional one. Note that spaces between the Web Service name are replaced with underscores in the URL pattern.
2. Configuring an Azure AD App Registration
With internal access verified, you can now begin the setup of the Azure AD App Registration required. Again, a prerequisite to this is having a the Azure AD App Proxy service installed and configured in your environment. See my post about configuring it for general web applications here.
Create a new Azure AD App Registration. Your Homepage URL is going to be the SOAP Base URL you previously configured excluding the port and path. If you're using SSL, use an HTTPS protocol, otherwise use an HTTP protocol. The Application type can be left as Web app / API. See Figure 3, below.
That's all that is required to create the App Registration. Now we need to configure the App Proxy. To do that, open Enterprise applications from the Azure AD menu blade and open the Application you just created, in my case Dynamics NAV 2018 Staging SOAP.
Set Pre Authentication to Passthrough as you're vendor's application likely won't be able to handle any kind of Azure AD authentication.
The Internal Url is going to be the Homepage URL you configured above, but this time including the port your services are running on. In my case, 7147, such that it reads (for me) "https://navstgsoap.mydomain.com:7147/". Note that the external request that will be made to the App Proxy service will be made on either port 80 or (hopefully) port 443 via the HTTP or HTTPS protocal. The Azure AD App Proxy will transform the request to me made over your SOAP port as part of its inner workings.
For the External Url, you can choose to use a subdomain on some domain you already own, or you can use the basic Azure App Proxy URL pattern which is typically your application name + "-[Your Azure Tenant Name].msappproxy.net/". It'll work either way, but note that if you set the External Url to something custom on your own domain, you will need to create the requisite A record in your DNS hosting provider's DNS Zone settings for it to be reachable. Assuming you've gone with the HTTPS protocal, you'll need to upload and configure the SSL cert you're using to encrypt it to Azure AD too.
I'm going to leave the basic ..msappproxy.net URL which I believe is fine for my circumstance.
Select the Connector group you want to use (for me, it's default), and the remainder of the settings can be left at their defaults. See Figure 4, below.
Hit Save, and that's it! You've just configured secure, external access to your Dynamics NAV's SOAP services tier.
You'll be able to test this by opening a browser (ideally, external to your corporate network), and entering External Url, this time with the remainder of the path specific to the NAV web service that you want to access. E.g., if I wanted to test my Jet Professional web service externally, I would enter https://navstgsoap.mydomain.com/ServiceTierName/WS/Codeunit/Jet_Data_Source which would return the same XML that was returned with my internal testing back in Step 1.