Table of contents
A zero trust proxy sits between users and an application, verifies identity and applies access policies before forwarding permitted requests. For web applications, it commonly works as an identity-aware reverse proxy: users reach the proxy first, and the proxy determines whether they can reach the requested resource.
This is useful when an internal portal, legacy application, or custom web app needs stronger access controls but cannot easily adopt a new authentication system. Instead of rebuilding the entire application, teams can introduce an access layer in front of it.
In this guide, we explain the architecture, compare it with a VPN and a standard reverse proxy, and walk through an illustrative deployment using Datawiza Access Proxy (DAP).
What makes a proxy “zero trust”?
The defining principle is that being on the corporate network does not automatically make a user or device trustworthy. NIST describes zero trust as an approach that removes implicit trust based on network location or asset ownership and focuses access decisions on individual resources. A proxy can provide an enforcement point within that architecture; installing one does not create a complete zero trust program. Source: NIST SP 800-207.
For a web application, three questions guide the design:
- Who is requesting access? Establish the user’s identity through the configured authentication system.
- What may that identity access? Apply policies to the application or URL being requested.
- Can the request bypass those checks? Restrict direct access to the application behind the proxy.
“Zero trust proxy” describes this access pattern. It is not, by itself, evidence of a product certification or a guarantee that every possible access path is secure.
How does a zero trust proxy work?
Consider an employee opening a protected expense portal. In an identity-aware deployment, the request follows this sequence:
- The browser requests the application through the proxy. The application hostname routes to the access layer.
- The proxy checks for an authenticated session. If needed, the browser is redirected to the identity provider (IdP).
- The IdP authenticates the user. With the appropriate policies configured, this includes multi-factor authentication (MFA).
- The proxy evaluates application access policies. A successful sign-in does not automatically authorize every application or URL.
- An allowed request reaches the application. Where configured, the proxy also supplies identity attributes that the application can consume.
Microsoft documents this session-check, sign-in, policy-evaluation, and identity-header flow for Datawiza with Microsoft Entra ID. The exact authentication exchange depends on the integration. Source: Microsoft’s Datawiza integration tutorial. Datawiza’s Entra ID authentication-flow example also distinguishes configured IdP MFA and Conditional Access from the proxy’s application access policies.
Verifying a session does not mean asking the user to complete MFA on every page load. Authentication frequency, session expiration, and access-policy evaluation are separate controls that need to be designed together.
Zero trust proxy vs. VPN vs. reverse proxy
These technologies overlap, but they answer different access questions. This comparison describes common deployment patterns, not every product configuration.
For Datawiza specifically, the documented browser-access use case covers HTTP and HTTPS applications without an endpoint agent. Requirements such as SSH, RDP, or raw database connections call for an access solution that supports those protocols. Datawiza can also complement a broader ZTNA deployment when web applications need additional identity integration. Source: Datawiza’s web application access guidance.
Zero trust proxy example: Datawiza Access Proxy
Datawiza Access Proxy is a container-based identity-aware proxy that places an authentication and authorization layer in front of applications. It can run near the application in a sidecar deployment or on a separate server in standalone mode. The Datawiza Cloud Management Console (DCMC) provides centralized configuration and policy management. Source: Datawiza Access Proxy introduction.
The diagram below shows a simplified self-hosted example, with the identity provider above the application request path. The management console is omitted to keep the access flow easy to read.
DAP checks sessions and access policies before forwarding allowed requests. Authentication is handled by the identity provider. Browser redirects are omitted for clarity.
The horizontal arrows show the application request path. DCMC manages configuration and policies separately and is not shown in this simplified diagram. Application traffic does not pass through DCMC. Restrict backend access to the approved proxy path to prevent bypass. Sources: Datawiza architecture, self-hosted data-plane guidance.
An illustrative Finance portal deployment
Suppose a company has an internal Finance portal with three areas: employee expenses, Finance reports, and administration. This is a hypothetical policy design, not a customer case study or a measured implementation result.
The team connects DAP to Microsoft Entra ID, configures the relevant IdP authentication requirements, and defines URL-level access rules. Datawiza’s documented policy inputs include user attributes, groups, the request URL, and HTTP method. Source: Datawiza granular access control.
The application should still decide which expense records a person may view, edit, or approve. A rule allowing access to /expenses/ is not a substitute for record-level authorization inside the portal.
Before rolling out this design, test actual group claims, path matching, rule precedence, and fallback behavior. A route called /finance/ is only an example; configure rules for the real application, including its API endpoints.
What about applications that do not support modern SSO?
A proxy can separate the identity-provider integration from the application, but the application still needs a supported way to recognize the user. Depending on the application, that may be an existing header-based integration or an application-specific mechanism.
For custom applications, Datawiza’s integration guide describes targeted changes to read identity headers, establish application sessions, and coordinate logout. Some supported integrations can avoid code changes; others need a small integration effort. Confirm the login and session model before promising a no-code rollout. Source: Datawiza custom web app integration guide.
Deployment checklist: make the access policy effective
Use these checks to turn a diagram into an enforceable deployment.
1. Close the direct route to the application
If a user can open the backend hostname or IP address directly, the proxy may be bypassed. This is especially important when the application trusts identity headers. Restrict the application’s ingress using the appropriate firewall, security group, or local network controls so that it accepts connections from DAP. Source: Datawiza network restriction guidance.
Test the old hostname, alternate ports, and direct IP access as part of acceptance testing. Successful login through the proxy is only half the test; an unauthorized direct route should fail.
2. Review protected paths and policy exceptions
Datawiza distinguishes protected rules from “Not Protected” rules, which pass requests upstream without authentication. Exact and prefix path matches also behave differently. Check exceptions deliberately, particularly broad prefixes and overlapping rules. Source: Datawiza rules configuration guide.
For the Finance example, try an allowed Finance user, a signed-in non-Finance user, a user with no matching group, and an unauthenticated browser. Include similar-looking paths and API calls in the test set.
3. Validate identity, sessions, and logout
Confirm which system enforces MFA, what identity information the application receives, and how the application binds that identity to its own session. Check logout and expiration at both layers. Also test what happens after a user’s group membership changes; do not assume an existing session immediately reflects every identity update.
These are rollout acceptance criteria, not claims that every integration behaves identically.
4. Plan transport security and operations
Use production HTTPS configuration and assess encryption on the proxy-to-application connection. Datawiza’s troubleshooting documentation specifically calls for configuring HTTPS after its getting-started setup. Source: Datawiza production HTTPS guidance.
Define certificate renewal, proxy upgrades, capacity, health checks, log handling, and recovery procedures. Test a proxy restart and an IdP interruption before expanding the rollout. The access layer becomes part of the application’s availability design.
When is Datawiza Access Proxy a good fit?
Datawiza is worth evaluating when the project centers on existing web applications and the missing controls are SSO, MFA integration, and application access policy. Its product documentation describes role-based, attribute-based, and URL-level controls, along with access visibility and centralized administration. Source: Datawiza Access Proxy product overview.
Start with one application whose access rules are easy to state. Document its current login method, required user groups, sensitive routes, and backend network exposure. Use those details to validate the integration and deployment effort before extending the pattern to other apps.
For a hands-on starting point, follow Datawiza’s Flask application walkthrough. To discuss an existing application’s requirements, contact Datawiza.
Frequently asked questions
Is a zero trust proxy the same as an identity-aware proxy?
The terms often overlap in web application access. “Identity-aware proxy” describes a proxy that uses identity in access decisions. “Zero trust proxy” emphasizes its role in enforcing explicit access policies without treating network location as sufficient trust.
Does a zero trust proxy replace a VPN?
It can remove the need for VPN connectivity for selected web applications. It does not automatically replace access to every private resource. Decide separately how users will reach SSH, RDP, databases, and other non-web services.
Can Datawiza add MFA to a legacy application?
Datawiza can place an access layer in front of a supported application and integrate it with modern authentication. In the example above, the identity provider enforces configured MFA. Validate the application’s login integration and session behavior before deployment.
Does every request trigger a new MFA prompt?
No. A proxy may validate an existing authenticated session while applying access policy. A fresh MFA challenge depends on the authentication configuration, session state, and identity provider’s policies.
Does a zero trust proxy replace application authorization?
No. Proxy policies can limit access to applications and routes. The application still needs appropriate business permissions, such as restricting which records a user can read or approve.
