Many enterprise applications still rely on legacy identity platforms such as SiteMinder or PingFederate. Rewriting these applications to support modern authentication can take years of engineering effort.
what if you could modernize authentication using Microsoft Entra without changing the application code at all?
Although many organizations have moved toward cloud-native architectures, critical legacy applications remain in many enterprise environments, hosted on platforms such as Oracle WebLogic, Tomcat, or Apache. Many of these applications are complex, tightly coupled systems, where modernizing microservices is not straightforward and can take a long time due to their complexity and security concerns. These applications were designed to work with previous identity solutions, such as CA SiteMinder or PingFederate. A significant number of these applications use HTTP header-based authentication rather than more modern protocols such as OAuth2, OpenID Connect, and SAML. Rewriting legacy applications to support modern authentication protocols may take years of engineering effort and carry operational risk.
Another important factor that enterprises consider during this transition is cost optimization. Legacy identity platforms such as Broadcom SiteMinder or PingFederate often require significant annual licensing and support renewals. In large enterprise environments, these renewal costs can become substantial. This creates a practical modernization in decision-making:
• Continue paying high licensing costs for legacy IAM platforms
• Or undertake costly and time-consuming application rewrites
A better approach is to modernize the identity control plane while preserving the existing authentication contract. By using Microsoft Entra Application Proxy with header-based SSO, organizations can migrate authentication to Entra while keeping the legacy application unchanged. This allows enterprises to gradually retire legacy access management platforms and avoid expensive renewal cycles while modernization progresses.
The Challenge with Legacy Authentication
Modern cloud applications typically support:
• OAuth2
• OpenID Connect
• SAML tokens
• JWT validation
Legacy enterprise applications were written long before these standards became common. Instead, they rely on trusted HTTP headers injected by an access gateway. For example, systems protected by SiteMinder often expect headers like:
• SM_USER
• SM_ROLE
• SM_USERDN
Once authentication occurs, the application simply trusts these headers to determine identity and authorization. Now, replacing SiteMinder or PingFederate can look like it requires a full application rewrite.
However,
if the header remains unchanged, the application itself need not change
.
Key Idea: Preserve the Header Contract
Instead of rewriting the application, you replace the authentication layer in front of it. Microsoft Entra provides this capability through application Proxy with header-based SSO. In this architecture:
- Users authenticate with Microsoft Entra ID
- Entra issues identity claims
- Application Proxy converts claims into HTTP headers
- Headers are forwarded to the on-prem application
- The application continues operating exactly as before
- From the application's perspective, nothing changed (e.g., it still receives: SM_USER=john.doe, SM_ROLE=Admin )
This approach allows enterprises to:
• Remove legacy federation infrastructure
• Centralize authentication in Entra
• Apply Conditional Access and MFA
• Avoid rewriting applications
Platform Integration Considerations
While the overall architecture remains the same, the exact integration approach may vary by application platform. For example:
•** WebLogic applications**
Many enterprise WebLogic applications already support SAML-based authentication through container-managed security. In these environments, WebLogic can be configured to act as a SAML Service Provider (SP) and redirect unauthenticated users to Microsoft Entra for authentication.
• Tomcat or JBoss applications
For applications running on Tomcat or JBoss that rely primarily on header-based authentication, a lightweight Servlet Filter can intercept incoming requests. The filter checks whether the required authentication headers are present and, if not, redirects the user to the Entra authentication flow through the Application Proxy.
Implementing Header-Based SSO
To enable header-based SSO
- Publish the on-prem application via Microsoft Entra Application Proxy
- Enable Pre-authentication with Entra ID
- Configure Header-based Single Sign-On
- Map identity claims to headers
- The proxy then injects those headers when forwarding the request to the backend application.
Optional: Header Translation Layer - In some environments, applications expect very specific legacy headers. For example: SM_USER, SM_ROLE
For such environments, you can introduce a lightweight Servlet Filter that translates modern headers into legacy ones. Servlet filters intercept HTTP requests before the application processes them. Below is a simplified example filter that translates Entra headers into SiteMinder-compatible headers. Below is an example of a WebLogic filter
Register the filter in web.xml
This allows the backend application to continue reading the same legacy headers.
Handling Authorization at Scale
Many legacy applications depend heavily on group membership. However, identity tokens have limits on the number of groups they can include. Instead of sending large group lists, a better approach is:
Use Application Roles - Define roles in Entra:
- Admin
- Approver
- Reviewer
Assign users or groups to these roles, then pass them as a header: X-ENTRA-ROLES=Admin
Your WebLogic filter can translate this to SM_ROLE=Admin
This keeps the header size small and authorization manageable.
Security Considerations
Header-based authentication must be implemented carefully. A critical rule is:
- Only trusted infrastructure should be allowed to send authentication headers.
- Recommended controls:
- Restrict backend access to Application Proxy connector IPs
- Block direct internet access to application servers
- Use Entra Pre-authentication
- Enable Conditional Access and MFA
When implemented correctly, this architecture can improve security posture compared to legacy access gateways.
Benefits of This Approach
This architecture allows enterprises to modernize identity without disrupting legacy systems. Key benefits include:
- Elimination of expensive legacy IAM platforms
- No application code rewrite
- Centralized identity using Microsoft Entra
- Reduced infrastructure complexity
- MFA and Conditional Access support
- Improved security posture
Most importantly, it enables organizations to modernize authentication across hundreds of legacy applications with minimal risk.
Final Thoughts
Many organizations assume modernizing identity requires rewriting legacy applications. The fastest path is preserving the application's existing identity contract while modernizing the authentication layer. By combining Microsoft Entra Application Proxy, header-based SSO, and lightweight compatibility filters, enterprises can move legacy applications into a modern identity ecosystem without major redevelopment. If you're responsible for modernizing enterprise identity architecture, this approach can save years of engineering effort and millions in IAM platform costs.
Next Steps
In a follow-up article, I will walk through the detailed configuration steps for implementing this architecture in enterprise Java environments, including:
- Configuring WebLogic as a SAML Service Provider with Microsoft Entra
- Implementing Servlet-based request interception for Tomcat and JBoss applications
- Mapping Entra identity claims to legacy header contracts
Top comments (0)