Publishing Custom Auth based Internal Apps via Azure AD Application Proxy

Introduction

Azure Active Directory Application Proxy, is a modern way of publishing internal enterprise applications over internet, protected via familiar Azure Active Directory Authentication challenge which also has Multi Factor Authentication(MFA) feature that most enterprises enable for identity security.

More details on Azure AD Application Proxy here:

Remote access to on-premises apps - Azure AD Application Proxy

This article dives into one of the SSO solutions implemented for publishing an internal application which had custom cookie based authentication/authorisation.

While Azure AD Application Proxy supports many backend application SSO methods (e.g. listed below), there are scenarios when these alone won’t work and you might have to develop a custom solution of your own to work in conjunction with one of these.

1. Kerberos Constrained Delegation (KCD)
2. SAML SSO
3. Password Vaulting: In this, AAD Proxy caches user’s credentials after first use on published backend internal application and for subsequent request onwards, it uses the same cached creds on user’s behalf, providing an SSO experience. It remembers the username/password form fields and pre-fills them with remembered creds and submits without user’s intervention.
4. Headers (using 3rd party service named PingAccess): In this, an additional utility i.e. PingAccess has to be installed and configured on an internal server. PingAcess installation comes inbetween AAD proxy and the internal application and translates attributes in AAD token to required (by backend application) headers for authentication. However, this has some additional considerations and limitations e.g.

• It does not provide a way to update existing headers in case your application’s authentication is based on standard HTTP headers e.g. HTTP_COOKIE i.e. to add new cookies with required values from AAD token claim, for example.
• It requires a lot of careful configurations both at AAD and PingAccess side.
• In case your application requires a custom header, which is not in standard JWT tokens/claims from AAD, then configurations related to additional claims and may be changes to AAD connect on what on-prem attributes to Sync in AAD etc, must be done.
• PingAccess only allows 20 internal applications to be published for free, so in case you have any current or future additional requirements of publishing such custom Header Auth based internal applications, then you might have to buy Licences.

Problem Scenario

So we had an internal application, which in requests to it, required a custom Cookie with a definite name and its value as in user’s sAMAccountName attribute from Active Directory. The application was hosted on a JBOSS based app server and did not support Windows Authentication. The requirement was thus to publish the internal application on AAD Proxy and setup SSO with it, while the only change for user was to pass through familiar Azure AD based authentication as for any other O365 based application. There was no scope of changes in backend application, due to time, resources and budget constraints. Azure AD application proxy, didn’t provide any direct method for enabling SSO with such internal applications.

Solution

As a solution, similar to PingAccess, but native and customizable, we deployed and configured IIS URL Rewrite / ARR(Application Request Routing) extensions and developed an IIS managed module to intercept incoming request and inject required Cookie for authentication with backend internal application.

The overall solution looked as below:

The custom IIS managed module, principally, can have below structure. This will work on an IIS site having Windows Integrated Authentication enabled on it. It will be triggered on PostAuthenticateRequest event in IIS request pipeline and it will add a cookie in a redirect (302) response asking user browser to come again with the cookie set in subsequent request headers.

Next, on AAD Proxy connector server, this managed module was registered to a site in IIS i.e. http://localhost. The same site was used to act as reverse proxy (for backend internal application) and to only allow requests having required cookie in request header. Both of these were achieved via below web.config file. Notice the backend internal application URL configuration and the rules for checking presence of required cookie.

Since the solution was deployed on the same servers as AAD Proxy Connector, the application internal URL configured in AAD Proxy on Azure Portal was set to http://localhost. This also helped add redundancy to the solution, as we could deploy it in all redundant AAD Proxy Connector servers with same settings.

AAD Proxy Internal Application configuration

Further in AAD Proxy, the published application was configured with Kerberos based SSO with required SPN and Login Identity attribute set as shown below. Please note that SAM account name set here is only for authentication with the reverse proxy site http://localhost hosted on AAD Proxy Connector servers.

Further details in link below on how to enable Kerberos based SSO for internal application publishing with AAD Application Proxy:

Single sign-on with Application Proxy

These were the basic parts of the solution. Apart from these, there will be other additional settings in AAD Proxy service such as custom domain, SSL certificate etc, which have to be done as part of application publishing via AAD Application proxy.

Once set, user, on browsing the application’s external link, will get AAD login page, which will take the request to AAD App proxy and beyond (as explained in the solution diagram), working through the deployed solution to provide a seamless SSO experience.

Additional Considerations

As with any application published via Azure AD Application proxy, if user is already logged into any of its Organization’s O365 application or other applications hosted via AAD Proxy, user will not be prompted for any creds, as same AAD tokens persisted in user’s browser will be used, for accessing this application (hosted in above manner).

Azure AD application proxy as any other proxy solution will add some minor latency. Though in principal, above light weight solution shall not put any further addition to the latency, proper performance testing should be carried out, in case a highly transnational, performance intensive internal application is being considered to be published in this manner.

Conclusion

Using IIS URL Rewrite and ARR extensions, further opens up the possibilities of how heterogeneous (w.r.t authentication, custom request header/body requirements) Internal Applications could be published securely via Azure Active Directory Application Proxy, giving a unified user experience and SSO for an Enterprise’ user base.