Skip to main content

Deployment Models

UDMG Secure Proxy (USP) can be tailored to support different deployment scenarios depending on your organization's security posture, infrastructure layout, and operational needs. These scenarios, comprising specific combinations of Components and Configuration, are referred to as Deployment Models.

This page outlines two recommended deployment models in detail, briefly introduces one additional model, and provides considerations for choosing the best approach.

Model 1: Double Authentication with Credential Passthrough​

A diagram showing the USP Server in the DMZ performing pre-authentication with LDAP, and a secure tunnel to UDMG via USP Client.

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 can be validated against a local Account Repository, or against an LDAP directory server (orange arrow), which could reside in the LAN (the latter example illustrated above).

Once the first authentication is successful, the USP Server then 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 relays (passes through) the client-provided credentials for authentication with UDMG Server (as illustrated in this example, against the same LDAP directory).

Use CaseBenefitsDrawbacks
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 2: No Pre-Authentication with Credential Passthrough​

Diagram showing the USP Server in the DMZ bypassing pre-authentication, and a secure tunnel relaying credentials to UDMG.

As in Model 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 is not performing authentication.

The USP Server still terminates the inbound connections and acts as a reverse proxy, maintaining the session break architecture. It then connects to the internal UDMG Server in the LAN via a secure tunnel established by the USP Client and relays (passes through) the client-provided credentials for authentication with UDMG Server.

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

Use CaseBenefitsDrawbacks
Environments that prioritize performance or have fewer concerns about exposing authentication attempts to the back end.
  • Simpler configuration and faster setup.
  • Reduced latency due to the elimination of authentication at the proxy.
  • Maintains some attack filtering benefits by still terminating and relaying sessions.
  • Can still perform other activities in the DMZ, such as inspecting files via ICAP, prior to relaying them to the back end server.
  • Invalid credentials reach UDMG, increasing its exposure and resource usage.
  • May demand scaling UDMG in the event of brute-force login attempts.

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.

Optional Deployment Model​

warning

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

Model 3: Double Authentication with Dedicated Credentials​

In this setup, USP Server authenticates external incoming connections, but does not relay their credentials to UDMG Server. Instead, it uses a fixed credential set. This effectively anonymizes user identity beyond the proxy.

Use CaseBenefitsDrawbacks

Specific business requirements that can withstand identity abstraction at the backend 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.
  • Identity of inbound connections is lost when passing through the proxy, making all outbound connections appear as the same user.

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.