Table of contents
Many important business applications still run on-premises or inside private networks. The question is not only how to make them reachable. The real question is how to publish them with the right identity, MFA, policy, and audit controls.
There are several ways to expose private web applications. The best choice depends on whether users need broad network access or only application-level access.
The Common Options
Option 1: VPN
VPN gives users private network access. It is familiar and useful for broad access across many protocols, but it often requires client software, endpoint setup, and careful network segmentation.
Option 2: ZTNA
ZTNA can improve private access control compared with traditional VPN. It is often a good fit for workforce access to many private resources, but it may still focus on reachability more than application-level SSO, MFA, and legacy login modernization. For web apps, see ZTNA alternatives for app-level access.
Option 3: Tunnel or Connector
Tunnel and connector models can publish private apps through a cloud service. They can be convenient, but teams should evaluate where the data path runs, how identity is enforced, and whether the application still needs a separate login experience.
Option 4: Traditional Reverse Proxy
A reverse proxy can publish HTTP and HTTPS applications, but a basic proxy does not automatically solve identity, MFA, headers, session handling, or audit requirements.
Option 5: Identity-Aware Proxy
An identity-aware proxy combines the reverse proxy pattern with identity enforcement. It can authenticate the user, require MFA, apply policy, translate identity to the application, and log access before the request reaches the protected app.
Why App-Level Identity Matters
Many on-premises web applications were built before modern identity standards were common. They may not support SAML or OIDC, may depend on headers or legacy sessions, or may be owned by vendors who cannot change the login code quickly.
- The app has no native MFA or 2FA support.
- The app cannot easily join Microsoft Entra ID, Okta, Ping, or another IdP.
- Users outside the corporate IdP still need access.
- Auditors need application-level evidence, not just network-login evidence.
- The business cannot wait for a code rewrite or application upgrade.
Where Datawiza Fits
Datawiza Access Proxy sits in front of existing HTTP and HTTPS applications and adds modern access controls without changing application code.
It is commonly used for Oracle E-Business Suite, PeopleSoft, JD Edwards, SharePoint, SAP web applications, admin portals, customer and partner portals, custom internal web apps, and legacy applications that do not support modern identity protocols.
- Use your existing IdP for SSO, MFA, conditional access, and centralized identity policy.
- Use built-in MFA when users should keep existing application credentials.
- Use a dedicated Datawiza IdP when contractors or third parties need a separate identity store.
- Publish the application through a self-hosted or hosted access layer.
- Collect app-level access logs for audits and reviews.
A Practical Architecture
A typical pattern is simple: user traffic reaches Datawiza Access Proxy first; Datawiza enforces authentication, MFA, and policy; then approved requests are forwarded to the protected on-premises web application.
The proxy can run in a DMZ, VPC, private cloud, or on-premises environment depending on the architecture. The goal is to keep the data path under the control model that fits the application while adding modern identity at the access layer.
When This Pattern Is a Good Fit
- The target application is browser-based over HTTP or HTTPS.
- The app is hard to rewrite, upgrade, or migrate.
- You need app-level SSO, MFA, or 2FA before access.
- You need to support internal users, customers, partners, suppliers, or contractors.
- You need logs and access evidence for audits, cyber insurance, or compliance.
How to Choose the Right Approach
Use VPN when users need broad private network access. Use ZTNA when you are standardizing workforce private access across many resources. Use a tunnel or connector when a cloud-brokered publishing path fits your architecture. Use an identity-aware proxy when the problem is specifically web application access, SSO, MFA, legacy login modernization, and audit.
For MFA-specific web application use cases, see MFA for web applications.
Frequently Asked Questions
What is the best way to publish on-premises web applications?
For browser-based applications that need modern identity controls, an identity-aware proxy is often the cleanest pattern. It publishes the app and enforces authentication, MFA, policy, and audit before access.
Is this the same as ZTNA?
It overlaps with some ZTNA use cases, but it is more app-specific. Datawiza focuses on HTTP and HTTPS applications that need app-level SSO, MFA, headers, session handling, and no-code identity modernization.
Can Datawiza publish apps without code changes?
Yes. Datawiza Access Proxy sits in front of existing web applications, so the application usually does not need to be rewritten to support SSO or MFA.
Does Datawiza support non-web protocols?
Datawiza Access Proxy is designed for web applications over HTTP and HTTPS. Non-web protocols may still require VPN, ZTNA, or other private access tools.
Conclusion
Publishing on-premises web applications securely is not only a networking problem. It is an identity and access problem. The best pattern gives users only the app access they need, enforces MFA before access, and creates evidence for every protected application. Schedule a demo to review your application publishing architecture.
