Deployment Models

UDMG Secure Proxy (USP) supports multiple deployment scenarios based on your organization's security posture, infrastructure layout, and operational requirements. These scenarios are referred to as Deployment Models.

This page describes the recommended deployment models, introduces one additional model, and outlines the trade-offs and typical use cases for each.

info

Deployment models apply at the Inbound Node level (through their associated Rules) or TCP Listener level, not at the USP Server level. As a result, a single USP Server instance can host multiple Listeners using different deployment models within the same architectural deployment.

However, hybrid deployments may introduce additional configuration and operational complexity.

With Session Break Mode

For more information on Session Break and Direct Mode, refer to Connection Modes.

Model 1.1: Double Authentication with Credential Passthrough

In this model, all three USP components (USP Manager, USP Server, and USP Client) are used (see Note on Minimal Installations).

The USP Server, deployed in the DMZ and configured via the USP Manager, performs authentication of external inbound connections. The provided credentials are subsequently validated against a local Account Repository or an LDAP directory server, which could reside in the LAN (the latter example illustrated above).

After the first authentication succeeds, the USP Server connects to the internal UDMG Server in the LAN via a secure tunnel established by the USP Client, also residing somewhere in the LAN, and replays (reuses) the client-provided credentials for authentication with UDMG Server (as illustrated in this example, against the same LDAP directory).

Use Case	Benefits	Drawbacks
High-security environments where external clients must be validated before reaching internal systems.	Prevents unauthenticated clients from reaching UDMG. Mitigates various SFTP-based attacks at the proxy layer. Reduces load on UDMG by filtering out invalid connections at the DMZ.	Requires setting up a credential store accessible by the USP Server. May introduce latency if used with LDAP, especially with frequent short-lived sessions.

Model 1.2: No Pre-Authentication with Credential Passthrough

As in Model 1.1, all three USP components are deployed (see Note on Minimal Installations) and the USP Server is configured via the USP Manager. However, in this model, the USP Server does not perform authentication.

The USP Server still terminates the inbound connections and acts as a reverse proxy, maintaining the session break architecture and still requiring credentials from the client; however, instead of authenticating locally, it connects to the internal UDMG Server in the LAN via a secure tunnel established by the USP Client and sends the client-provided credentials to UDMG Server for authentication.

The UDMG Server receives and authenticates the credentials. If authentication fails, the USP Server replays the failure back to the external client and terminates the connection.

Use Case	Benefits	Drawbacks
Environments that require session break at the proxy for reasons other than authentication. For example, inline scanning of files for viruses or to comply with security or regulatory requirements.	Simpler configuration and faster setup. Reduced latency due to the elimination of authentication at the proxy. Maintains some attack-filtering benefits by terminating and relaying sessions. Can still perform other activities in the DMZ, such as inspecting files via ICAP, prior to replaying them to the backend server.	Invalid credentials reach UDMG, increasing its exposure and resource usage. May demand scaling UDMG in the event of brute-force login attempts.

info

This Deployment Model is the one selected in the Tutorial: Setting Up SFTP Forwarding.

Model 1.3: Double Authentication with Dedicated Credentials

warning

The following model is supported by USP but not recommended for most production use cases due to its weak security posture.

The USP Server, deployed in the DMZ and configured via the USP Manager, performs authentication of external inbound connections. The provided credentials are subsequently validated against a local Account Repository or an LDAP directory server, which could reside in the LAN (the latter example illustrated above).

After the first authentication succeeds, the USP Server connects to the internal UDMG Server in the LAN via a secure tunnel established by the USP Client, also residing somewhere in the LAN, but does not replay the client-provided credentials to UDMG Server. Instead, it uses a fixed credential set. This effectively anonymizes user identity beyond the proxy.

Use Case	Benefits	Drawbacks
Specific business requirements where identity abstraction in backend systems is acceptable. Another scenario may involve environments requiring public key authentication only, which is not supported in Model 1.1, and thus requires using a dedicated credential for the backend authentication leg. An alternative to this approach is to use Public Key and Password in USP, but Password only in UDMG with Model 1.1 above. USP will replay the client's password but ignore the public key during the second leg of the authentication sequence.	Prevents unauthenticated clients from reaching UDMG. Mitigates various SFTP-based attacks at the proxy layer. Reduces load on UDMG by filtering out invalid connections at the DMZ.	Requires setting up a credential store accessible by the USP Server. Identity of inbound connections is lost when passing through the proxy, making all outbound connections appear as the same user.

With Direct Mode

For more information on Session Break and Direct Mode, refer to Connection Modes.

Model 2.1: No Pre-Authentication with Credential Passthrough

In this model, all three USP components (USP Manager, USP Server, and USP Client) are used (see Note on Minimal Installations).

In Direct Mode, USP operates as a TCP-level reverse proxy without implementing the Session Break architecture nor performing authentication.

Because no session break occurs, the USP Server does not interrupt or modify protocol data. Any authentication is performed exclusively by the internal target system (UDMG).

Use Case	Benefits	Drawbacks
Environments prioritizing authentication fidelity, reduced operational complexity, support for non-replayable authentication methods (public key authentication for SFTP), or replacement of legacy direct passthrough proxy deployments.	Preserves full end-to-end authentication semantics at the backend. Supports non-replayable authentication methods (e.g., public key or multi-factor authentication). Lower operational complexity by centralizing authentication in UDMG. Protocol-agnostic; supports any TCP-based protocol. Lower latency due to a single end-to-end session. Maintains IP-based access control at the proxy layer.	Backend receives unauthenticated traffic and handles authentication directly. Security boundary shifts closer to the backend system. Larger backend attack surface compared to Session Break Mode. No proxy-level authentication enforcement. No protocol inspection or ICAP integration.

Other Models

The deployment models described above represent the most common and practical configurations. However, USP is highly flexible and can support additional variations tailored to specific technical or business requirements.

info

For guidance on alternative deployment models and their trade-offs, please contact our team.

Note on Minimal Installations

While USP can be deployed with just the USP Server and USP Manager (omitting the USP Client), this configuration is only appropriate in sandbox environments where security is not a concern and firewall restrictions are not imposed.

Without the USP Client, the USP Server must open a direct path through the firewall to internal systems, discarding many security benefits of the reverse proxy architecture.