How to use cloud identity proxies to secure legacy on-premises web applications
The most practical approach is to put a cloud identity-aware proxy in front of each legacy web application, so users must authenticate through your identity provider and satisfy access policies before their requests reach your data center.
This lets you add modern security controls—such as single sign-on (SSO), multifactor authentication (MFA), and conditional access—without necessarily modifying the legacy application's code. Microsoft Entra Application Proxy and Google Cloud Identity-Aware Proxy (IAP) are two documented approaches for this pattern.
The key security principle is that the application should no longer be directly accessible to arbitrary internet users. The proxy evaluates identity and policy before allowing access, following the Zero Trust principle of not trusting users merely because of their network location.
2. Choose the right proxy
Microsoft Entra Application Proxy
Best when your organization already uses Microsoft 365, Entra ID, and Conditional Access. It publishes on-premises web apps through connectors, supports preauthentication, and can integrate with SSO for supported legacy authentication methods.
A strong fit for organizations using Google Cloud and Google identities. Its on-premises connector architecture can put HTTP-based applications behind a cloud load balancer and apply IAM-based access policies per application.
Worth evaluating if you want identity-aware access for self-hosted applications and already use, or plan to use, Cloudflare's network and access services. It can apply policies based on identity-provider and device-posture signals.
Documentation:
These products serve similar purposes, but connector design, supported authentication flows, network requirements, and licensing differ. Start with the identity platform your organization already operates unless a specific requirement points elsewhere.
3. Implement it in six steps
Inventory your legacy applications
Record each application's hostname, backend protocol, authentication method, user groups, dependencies, and sensitivity. Identify whether it uses Windows Integrated Authentication, LDAP, form-based login, basic authentication, or no authentication.
Configure identity and access policies
Connect the proxy to your identity provider. Require MFA for sensitive applications, restrict access by security group, and use device compliance or risk-based policies where supported. Give users access only to the applications they need.
Deploy the connector
Install the vendor-supported connector in a suitable network segment or configure the required hybrid connectivity. Restrict its outbound traffic to the necessary services and its access to the specific backend applications.
Publish each application securely
Create a dedicated external HTTPS hostname, configure its TLS certificate, and map it to the internal application. Enable proxy preauthentication so unauthenticated requests are stopped before they reach the legacy server.
Integrate legacy authentication
Determine whether the proxy can provide SSO to the application or whether the application must retain its own login. For example, Microsoft Entra Application Proxy supports several SSO approaches, but not every legacy authentication mechanism works automatically. Test session handling, redirects, cookies, and file uploads.
Test, monitor, and roll out gradually
Pilot with a small user group. Test authorized and unauthorized users, MFA challenges, expired sessions, direct backend access, and application functionality. Review proxy, identity-provider, and application logs before expanding access.
Deploy redundant connectors or supported highly available components and test recovery.
Important: A proxy does not automatically fix vulnerabilities inside the legacy application. Also, if users can reach the backend directly, they may bypass the new identity controls. Keep the backend private, and ensure the application trusts identity assertions only from the designated proxy.
5. Validate the deployment
Before broad rollout, confirm these outcomes:
An unauthenticated internet user cannot reach the protected application.
An authenticated but unauthorized user is denied.
MFA and device policies work as intended.
Approved users can complete normal application workflows.
Direct access to the backend is blocked or equivalently protected.
Identity and application logs provide enough information for investigation.
Connector failure and recovery have been tested.
My recommendation
For most organizations, start with one moderately sensitive, HTTP-based internal application and use the existing enterprise identity provider to front it with an identity-aware proxy. Validate compatibility before moving applications that depend on older authentication protocols or unusual browser behavior.
To narrow this down to a concrete reference architecture, which identity platform do you use today?
User Request: A remote user attempts to access your legacy web app via a public URL provided by the cloud identity provider.
Authentication & Policy Check: The cloud proxy intercepts the request and prompts the user to log in via single sign-on (SSO) and multi-factor authentication (MFA). It evaluates context rules like device health, location, and group membership.[](https://delinea.com/blog/identity-aware-proxy-iap)
Secure Outbound Tunnel: A small connector agent installed inside your on-premises data center maintains an active, outbound-only connection to the cloud service.
Choose Your Identity Provider: Select a cloud platform matching your ecosystem, such as Microsoft Entra ID Application Proxy or Google Cloud Identity-Aware Proxy (IAP) combined with on-premises connectors.
Install the On-Premises Connector: Deploy the lightweight connector software on a local server or virtual machine within your private corporate network that has internal network reachability to your legacy web app.
Publish the Application: Register your local internal URL (e.g., http://intranet.local ) and assign a public external domain within the cloud administration console.
A cloud identity proxy lets you put a modern identity/security layer in front of a legacy on-premises web application without rewriting the application first. The basic pattern is:
For example, Microsoft Entra Application Proxy and Google Cloud Identity-Aware Proxy both support this general architecture for on-premises HTTP(S) applications.
Recommended process
Inventory and classify the applications
Identify URLs, servers, authentication method, dependencies, user groups, sensitivity, and whether the app requires Windows Integrated Authentication, headers, forms-based login, etc.
Separate applications that can be modernized directly from those that need a proxy as an interim solution.
Instead of prompting the user for local credentials (like basic auth, NTLM, or an aging on-prem LDAP form), the proxy pauses the request and redirects the user to the cloud Identity Provider (IdP) (e.g., ID, , or ).
If you are planning a specific implementation, let me know:
Which cloud provider or IdP you are targeting (e.g., Microsoft Entra, Okta, Google Cloud)
The underlying auth mechanism of the legacy app (Kerberos, NTLM, header-based, or anonymous)
I can provide more targeted architectural details for your setup.
Cloud identity proxies are essentially identity-aware reverse proxies placed in front of older web applications. They let you put modern authentication and authorization in front of an application that may only understand old mechanisms such as basic authentication, NTLM, Kerberos, or even no authentication at all.
For example, Microsoft Entra Application Proxy uses a cloud service plus an on-premises private-network connector. A user visits the application's published URL, is redirected to Microsoft Entra for authentication, and the connector then reaches the internal application.
Google Cloud's IAP provides a similar model: its on-premises connector receives authenticated/authorized requests and forwards them over hybrid connectivity to the internal application.
What happens when a user connects?
1. The user goes to a normal HTTPS URL
Instead of exposing something like:
https://old-app.company.com
directly to the Internet, DNS points the user toward the proxy's public endpoint.
2. The proxy authenticates the user
The proxy redirects the browser to the organization's identity provider. This is where modern controls can happen:
SSO
MFA
group membership
device compliance
conditional/context-aware access
risk-based policies
For example, Microsoft specifically describes using Entra Application Proxy to put MFA and Conditional Access in front of legacy applications. learn.microsoft.comdocs.cloud.google.com Google IAP similarly supports identity- and context-based authorization policies.
3. The proxy makes the authorization decision
Authentication answers "Who are you?"
Authorization answers "Are you allowed to use this particular application?"
The proxy can therefore enforce something such as:
Alice is authenticated, is in the Finance group, and is using a compliant device → allow access to the payroll application.
Someone who successfully authenticates but isn't authorized for that application never reaches the legacy server.
4. The proxy connects to the private application
This is an important security advantage. The legacy server generally doesn't need to be exposed directly to the Internet.
With Microsoft Entra Application Proxy, the on-prem connector establishes the required communication with the cloud service; Microsoft documents this as avoiding the need for inbound firewall connections.
So instead of:
Internet ──► Firewall ──► Legacy server
you get approximately:
Internet
│
▼
Cloud identity proxy
│
│ authenticated/authorized request
▼
Cloud ↔ private connector
│
▼
Legacy server
The clever part: adapting modern identity to legacy authentication
This is often the main reason to deploy one.
Suppose an old application only understands a legacy mechanism such as HTTP headers. You don't necessarily have to rewrite the application to understand modern OAuth/OIDC/SAML.
The proxy can act as the translation layer:
Modern world Legacy world
Microsoft Entra / IdP
│
│ OIDC/SAML/etc.
▼
Identity proxy
│
│ legacy-compatible
│ authentication/header
▼
Old web application
Microsoft documents this explicitly for header-based applications: the intermediary authenticates the user and propagates the required HTTP headers to the destination application.
That makes the proxy a kind of security adapter around the legacy application.
Why this is useful
It lets an organization modernize access control without immediately modernizing the application.
You can consequently get:
Without proxy
With identity proxy
Application-specific passwords
Centralized SSO
Often no MFA
MFA at identity layer
Internet-facing legacy server
Private application
App-specific authorization
Centralized identity/group policies
VPN often required
Browser-based application access
Legacy authentication
Modern IdP + translation
Microsoft explicitly positions Application Proxy as a transition path for legacy on-premises applications that aren't capable of modern authentication.
One important caveat
The proxy doesn't magically make the legacy application secure.
You still need to make sure users cannot bypass the proxy and reach the application directly. Google, for example, specifically warns that backends need to be protected from direct access when IAP is being used.
And you need to decide how the proxy's authenticated identity is conveyed to the application—signed assertions/headers, Kerberos/NTLM delegation, etc.—without allowing users to forge those identity signals.
In one sentence: a cloud identity proxy puts a modern, centrally managed identity and policy enforcement point in front of a legacy application, then securely carries authorized requests from the cloud edge into the private network while translating the identity into whatever the old application can understand.
If you're interested, I can also explain how this differs from a traditional VPN, reverse proxy, and zero-trust access proxy—that's where the architectural distinction becomes especially clear.
Test and Validate: Direct users to the new public-facing URL to verify that authentication prompts trigger properly before any data packets route through the internal connector to the legacy app.
Install the vendor's lightweight connector agent (e.g., Microsoft Entra Private Network Connector or Google App/On-Prem Connector) on a local server or VM inside your corporate network.
Run diagnostic sign-on tests through the cloud administration portal to verify the connector successfully translates and forwards authenticated traffic.
If your organization uses Microsoft Entra ID, Microsoft Entra Application Proxy is a natural option.
In Google Cloud environments, Identity-Aware Proxy (IAP) can front on-premises HTTP/HTTPS applications using its on-prem connector.
Deploy the on-premises connector
Install the vendor's connector inside your network where it can reach the legacy application.
Prefer redundant connectors/instances rather than creating a single point of failure. Microsoft specifically recommends capacity planning and connector redundancy.
A major security advantage is that the connector can establish outbound connections rather than requiring you to expose the application server directly to the Internet. Microsoft documents this outbound-only connector model.
Publish the application through the proxy
Configure:
External URL
Internal application URL
TLS/HTTPS
Identity provider
Authorized users/groups
Pre-authentication behavior
With Microsoft Entra Application Proxy, for example, Microsoft recommends Microsoft Entra ID preauthentication when you want the identity layer to authenticate users before the request reaches the legacy application.
Put modern authentication in front of the legacy authentication
This is particularly useful because the legacy application doesn't necessarily need to understand modern authentication itself.
Configure SSO to the legacy application
This depends on what the application understands:
Integrated Windows Authentication: commonly use Kerberos-based SSO/Kerberos Constrained Delegation.
Header-based authentication: the proxy can inject identity attributes expected by the application.
Forms/username-password authentication: some proxy products support password-based SSO.
Unsupported/custom authentication: you may need an integration product or ultimately modify/modernize the application.
Microsoft documents all of these patterns for Application Proxy, including Kerberos-based IWA and header-based SSO.
Enforce access policy at the identity layer
This is where much of the security improvement occurs. Typical policies include:
MFA/phishing-resistant authentication
Require managed/compliant devices
Restrict particular applications to specific groups
Location/network restrictions
Sign-in risk policies
Session/lifetime controls
Microsoft Entra Conditional Access, for example, can apply policies based on user, location, device, application, and risk.
Remove direct Internet exposure
Once the proxy path is working, the legacy server should generally not also be directly exposed to the Internet. The proxy becomes the controlled ingress point. Microsoft describes Application Proxy as an alternative to exposing incoming firewall ports for supported scenarios.
Pilot before broad rollout
Start with one low-risk application and a small group:
Test authentication and MFA.
Test every important application function, not just the login page.
Test file uploads/downloads, WebSockets, redirects, APIs, timeouts, and legacy browser behavior as applicable.
Verify logging and incident-response visibility.
Test connector failure/redundancy.
Roll out application-by-application
Once the pattern works, migrate the applications in waves. Keep an inventory of which applications are merely protected by the proxy versus which have actually been modernized.
Important architectural point
A proxy is primarily a security/access bridge, not a replacement for application modernization. It can give a vulnerable legacy application a modern authentication and authorization boundary, but vulnerabilities inside the application itself—SQL injection, insecure business logic, outdated libraries, etc.—still need to be addressed.
Also, don't blindly use "passthrough" authentication if your goal is to enforce cloud identity controls. For example, Microsoft notes that Conditional Access doesn't apply to Application Proxy applications using passthrough preauthentication because the user isn't authenticated by Microsoft Entra first.
The key principle is "authenticate and authorize at the edge, then privately proxy to the legacy application." Over time, you can replace the proxy-protected applications with applications that natively support modern identity protocols, reducing the legacy dependency.
Once authentication succeeds, the cloud service passes the traffic through a lightweight connector or agent installed within the internal corporate network (behind the firewall).
This connector maintains an outbound-only encrypted connection (like a persistent WebSocket or TLS tunnel) to the cloud. Because the connection is initiated from the inside out, network administrators do not need to open fragile inbound ports like 443 or 80 on their corporate firewalls.
Token Translation and Header Injection
Legacy web apps often rely on basic session cookies, IP tracking, or simple HTTP headers (like passing a username or email in a clear-text header field) to recognize who is logged in.
Before the connector relays the final HTTP request to the internal legacy server, the cloud control plane evaluates fine-grained access rules (e.g., "Does this user belong to the 'Finance' security group?").
