Modernizing Identity and Access: Move to the cloud with Entra ID (Formerly Azure AD) - Part 1: Overview
I was the IAM architect for a Global fortune 500 CPG company for many years. The enterprise was in the midst of a major transformation to modernize and simplify the environment while improving security posture and improving end user experience. The transformation included a new cloud strategy, a new HRMS, and a change in strategy from best of breed to an integrated platform.
This enterprise decided early on in 2016 to adopt a cloud only strategy. To help seal the deal and ensure the strategy was adhered to the enterprise sold their datacenters, requiring that all infrastructure and applications migrate to a multi-cloud environment within a 24 month timeline.
This posed many challenges to include many related to identity and access management. The majority of applications, around 600, were integrated with an on-premises web access management (WAM) tool providing SSO based on Active Directory credentials. There also was a perceived notion that this environment was unstable and there was a strong desire to replace it. The decision was made to replace the existing access management with a cloud service, so Azure AD (now Entra ID) was chosen.
The organization had previously adopted Office 365 and had established an Azure AD tenant, directory, and related infrastructure. All of this needed to be reviewed and updated to support the user data required to provide for enterprise access management., which included:
• Synchronizing all user and group identities to AAD
• Syncing custom attributes from AD to AAD
• AADC upgrades
• How to handle B2B AD user accounts
• Migrate off on-premises Web Access Management tool
• Enable the change of HRMS solutions
• Enable MFA
• Adopt adaptive authentication
We developed a strategy to categorize applications by types, allowing a “factory approach” to migration:
• Modern apps (SAML enabled i.e SaaS)
• Existing Header based SSO enabled applications
• Custom Apps which would need updates or transformation
• Non-SSO enabled applications
An additional challenge at the time was the lack of Azure App Proxy support for header based SSO with applications. Even now with App Proxy support of header-based authentication, it still has some limitations for global organizations. Deploying Azure App Proxy requires that all application traffic traverse the internet to the Azure App Proxy service and then on to App Proxy connector deployed near the application. This solution does not allow for using the optimized corporate network, minimizing bandwidth and utilizing LAN speed to allow direct access from client to application.
The Solution – Utilize Azure AD as the single authentication control plane for authentication and conditional access with App Proxy for access while remote from company network but place an “authentication bridge” near applications to integrate Azure AD OpenID Connect to legacy application authentication like those still relying on HTTP Headers.
The authentication bridge was based on Open Source components using Apache HTTP Server as a reverse Proxy, various Apache modules like mod_rewrite– handle necessary changes for urls, mod_headers –set HTTP headers and mod_memcache– maintain session cache. We still needed a way to take the modern authentication from Azure AD and get the user authenticated into the Apache Reverse Proxy, and that is where modules like mod_auth_openidc or Shibboleth help to get that local authentication and necessary user profile information to Apache. This also allowed us to use the same policy data to perform local authorization bypassing App Proxy for application traffic other than the initial user authentication.
In the next installments I will discuss technical details regarding Azure AD extension attributes, extending JWT/SAML claims through custom claims, Apache server configuration and migration techniques.
