There is one problem our customers often ask us to solve. This is – how to publish an application in a secure way to the external users? The answer is – Azure AD. We have plenty of examples here.
Let me give you one with our customer operating several branches and stores. As a retail company, they have a lot of data stored in internal databases. And a common scenario to enable users to access the data is to use SQL reporting services or Power BI.
That’s a typical problem that you may face when deploying a new application or data access application for your users. So how to enable them to access to this application from anywhere? How to make it easy to use and secure from a company perspective?
What businesses tended to use in the past was application firewalls and proxies deployed on-premises. Another solution was to require users to connect to a company VPN before accessing these applications.
Now, Predica is a cloud-first company – we don’t have any on-premises infrastructure. With new services offered as part of the Azure platform, we have introduced a simple solution you can use to publish such applications within minutes! And also get an additional level of security for them.
OK, let’s start. First, let me introduce you to Azure Active Directory Web Application Proxy. It is a reverse proxy service hosted for you as part of the Azure services by Microsoft. Let’s see the components one by one:
Now, when our user is moving outside of their on-premises network, they can’t access the same resources as through the Active Directory. Why? Since it was never built to extend authentication to users over the Internet.
Our company has deployed Azure AD, and the Web Application Proxy is part of this service. To make it work, we need Azure AD WAP connector implemented within our on-premises network to publish the application.
You may ask now “is this secure? How come?” Well, the WAP connector is using an outbound, secure connection to its service to publish our service. The last piece of the puzzle is the configuration to publish our service through Azure AD WAP. For this, we need an external name for it and an SSL certificate.
What you need now is to map an external name to internal resources and provide information on how to map incoming user tokens to Kerberos tickets. What can Azure AD Web Application Proxy do for us? Simple as that: it authenticates the user based on Azure AD and exchanges this information to an on-premises Kerberos ticket with constrained delegation.
This way we can authenticate the user against the Azure Active Directory and access the resource published with WAP using Azure AD. When going to the on-premises resource, it will be automatically translated to a Kerberos ticket. So here the magic happens!
We are accessing our on-premises application with user authentication and Single Sign-On provided. It means our users don’t need to log on additionally to access published application from on-premises. You can do this not only with SQL reporting but with any application you are hosting internally.
As you can see, we use the Azure AD provided service to replace typical solutions for application publishing. No firewalls or on-premises equipment has been abused during this video.
You can implement it within a few minutes and remain secure with Azure AD authentication. There can be an additional level of protection with Azure AD conditional access and multi-factor authentication provided as well.
But wait, what if you don’t have Azure AD? You can also achieve this with on-premises Active Directory, AD FS and Web Application Proxy component of Windows Server. I will cover these additional scenarios in our future episode, so make sure you are following our social media.
I covered security in GitHub last time. But some of you likely use Azure DevOps for building your products, so let’s t...
Sometimes it feels like I'm pushing too much with security and software development, but then you prove me wrong. Rec...