Mastering Identity with Azure Active Directory – Episode 7: The Azure AD Application Proxy
The seventh part of John Craddock’s series into Azure Active Directory shows you how to publish applications to the Internet using the Azure AD Application Proxy. The proxy can be used to publish with Single-Sign-On, claims-aware applications, applications using Kerberos Windows authentication and forms authentication. Also, using PingAccess, a variety of applications that use host-header authentication can be published.
By In this series, I will take you through the key aspects of Azure Active Directory, and you will discover how by using Azure AD you can build identity solutions for the future. The series is about the technology rather than the marketing hype. It’s also something I cover in more depth in my masterclass, which is a deep-dive into the technologies and goes into the real technical detail. For an introduction to this series and some background on myself, see Episode 1: Introductions all round.
Caveat: To the best of my knowledge the information was accurate at the time of writing this blog but changes to Azure AD and the portals are frequently happening, and the precise details may change.
Apology: First off, I must apologise for the delay between publishing part 6 and the remaining blogs in this series. My only excuse is that a major project sucked all my spare time, but that’s now out the way, and I should now be able to complete the posts within the next few weeks. Lots has changed in Azure AD since the last blog, and almost all configuration can now be done in the new Azure Portal without the need to revert to the Classic Portal.
Episode 7: The Azure AD Application Proxy
At Microsoft Ignite 2016 I presented a breakout session on the Azure AD Application Proxy, you can find the Channel 9 video here. In 2015, I also wrote a whitepaper on troubleshooting the proxy which you can find here. Both the video and the whitepaper will probably provide you with more details than you need to know! This blog will be an introduction to the proxy, and will highlight things that have changed.
Introduction
The Azure AD Application Proxy provides you with a mechanism to publish your applications without the need for you to deploy a reverse proxy, firewalls and other DMZ associated infrastructure. The proxy is an Azure AD service that you enable in the Azure Portal, which allows you to publish an external public HTTP/HTTPS URL endpoint in the Azure Cloud that connects to an internal application server URL in your organisation. The connection to the internal application server URL is facilitated through the use of an Azure AD Application Proxy connector, which is installed on a server. See Figure 1.
Figure 1
All network traffic is established outbound from the connector to the Azure Cloud. Consequently, there is no need to open inbound connections on firewalls protecting your network.
Multiple connectors can be installed to provide fault-tolerance and load balancing, and multiple connectors can be grouped together into connector groups. This allows the appropriate connectors to be chosen for routing the traffic to the internal application. For example, App 1 might be hosted in the Paris data centre, and App 2 in the New York data centre. Multiple connectors are installed on servers in both Paris and New York to provide fault-tolerance and load balancing. A connector group is created to group together all the Paris connectors, and similarly, all the New York connectors are added to another connector group. When publishing an application through the proxy, a connector group is chosen to route the traffic directly to the appropriate data centre.
Incoming traffic to the external URL can be passed straight through to the published internal URL or pre-authentication can be required. Pre-authentication requires that the user is authenticated by Azure AD before any traffic is passed to the internal URL. In addition to authentication, the user must be assigned to the published application and have an appropriate Azure AD licence (Basic, P1 or P2).
After authenticating with Azure AD, the user must authenticate to the published application using the authentication method that has been configured for the application. The authentication to the Azure AD uses OpenID Connect (claims based). When the proxy was first released, to achieve single-sign-on to the internal application, the internal application had to be configured for claims-based authentication, Kerberos Windows Integrated Authentication (WIA) or forms authentication. Forms authentication was not directly supported through the proxy configuration UI but could be achieved by setting up password based authentication (password vault) for the internal application.
When using claims-based authentication, SSO will only work if the internal application and the proxy use the same identity provider. This is either configured with the internal application using Azure AD as its STS/identity provider (Figure 2) or the internal app using an on-premises AD FS as its STS/identity provider and the Azure AD configured to Federate with the on-premises AD FS (Figure 3). View my Channel 9 video or read the troubleshooting whitepaper, links are given above, to find out more details. In my next blog, I will be covering Federated SSO with on-premises AD FS.
Figure 2: Azure AD configured as the STS/identity provider for the application
Figure 3: Application configured to use on-premises AD FS ad identity/STS provider. Azure AD configured to federate with on-premises AD FS
If you want to publish an application which uses WIA, the application must be using Kerberos, the connector endpoint requests a Kerberos ticket using Kerberos Constrained Delegation. See Figure 4.
Figure 4: Publishing a WIA application
At Ignite last year, the Azure AD Application Proxy had to be configured via the Classic Portal. In the proxy UI, it was only possible to configure SSO for claims-aware applications and WIA applications. Also at that time, it was announced that Microsoft had partnered with Ping Identity to integrate PingAccess with the proxy service.
Since last year the configuration of the Azure AD Application Proxy has been integrated into the new Azure Portal. Under the single sign-on options for the proxy, it is possible to configure password-based sign-on (using the password vault) and header-based sign-on using PingAccess. Go here to find out about more details of PingAccess.
Please watch my Channel 9 video for a lot more detail. That’s it until next time.
For details of all the episodes in this series, look here. To learn and become skilled in implementing identity systems based on Azure AD, on-premises AD and AD FS, join me at one of my Masterclasses. To find out more visit XTSeminars.