Modernizing Legacy SSO with Microsoft Entra, Protect On-Prem Apps Without Rewriting Code

Sauhard Bhatt — Mon, 16 Mar 2026 05:23:24 +0000

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

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

DEV Community: Sauhard Bhatt