HTTP Proxy

The HTTP Proxy mode deploys the Maverics Orchestrator as an identity-aware reverse proxy. It sits in front of your applications — intercepting HTTP traffic to inject authentication headers, manage sessions, and enforce access policies without requiring any changes to the application’s code or configuration.

Console terminology: In the Maverics Console, the combination of applications, policies, headers, and connector bindings is managed through User Flows. In YAML, these elements are configured directly within each app’s configuration block under apps[].policies[].

When to use this mode

HTTP Proxy — Choose this mode when you cannot modify the application’s authentication code. Best for legacy apps, COTS products, and header-based authentication patterns.
OIDC Provider — Choose this mode when the application natively supports OpenID Connect.
SAML Provider — Choose this mode when the application natively supports SAML 2.0.
LDAP Provider — Choose this mode for applications that require an LDAP directory. Often paired with HTTP Proxy for comprehensive legacy app identity.
AI Identity Gateway — Choose this mode for securing AI agent-to-tool communication via MCP.

Use Cases

Protecting legacy apps without code changes — Add modern authentication to legacy applications that rely on form-based login, basic auth, or no authentication at all.
Header-based authentication injection — Inject identity headers (e.g., SM_USER, REMOTE_USER) into upstream requests for applications that expect header-based identity.
Session management for stateless apps — Provide cookie-based session management for applications that do not handle sessions natively.
Combining with LDAP Provider for legacy stacks — Pair HTTP Proxy with LDAP Provider mode to modernize applications that depend on both header-based auth and LDAP directory lookups.

How It Works

The HTTP Proxy request flow follows these steps:

Traffic interception — The Orchestrator listens on configured route patterns (hostname/path combinations) and intercepts all matching HTTP requests before they reach the upstream application.
Policy evaluation — Each request is matched against location-based policies. The Orchestrator determines which authentication and authorization rules apply based on the request path.
User authentication — If the user is not authenticated (no valid session), the Orchestrator redirects them to the configured identity provider. After successful authentication, a session cookie is established.
Authorization check — The Orchestrator evaluates authorization rules against the authenticated user’s attributes. Rules use and/or conditions with operators like equals, contains, etc. Unauthorized users are redirected or receive a 403 response.
Header injection — For authorized requests, the Orchestrator injects identity headers (e.g., SM_USER, X-Remote-User) into the upstream request using template syntax ({{ connector.claim }}). The upstream application receives these headers and uses them for its own identity decisions.
Proxying and response — The request (with injected headers) is forwarded to the upstream backend. The response flows back through the Orchestrator to the client. Optional Service Extensions can modify the request or response at this stage.

Key Concepts

Route Patterns and Upstreams

Route patterns define which traffic the proxy intercepts. Each proxy app maps one or more hostname/path patterns to an upstream backend URL. The Orchestrator acts as a transparent reverse proxy — the client connects to the Orchestrator, and the Orchestrator forwards to the backend.

Header Injection

Header injection is the primary mechanism for passing identity to legacy applications. Using {{ connector.claim }} template syntax, the Orchestrator maps claims from identity providers into HTTP headers that the upstream application expects. This replaces legacy access management products like SiteMinder without changing the application.

Location-Based Policies

Unlike OIDC and SAML modes where authorization is per-app, HTTP Proxy supports location-based policies. Different URL paths within the same application can have different authentication requirements and authorization rules. For example, / might allow all authenticated users while /admin requires a specific role.

Session Management

The Orchestrator manages sessions for proxied applications using cookies. This is critical for applications that lack their own session management. Session configuration (cookie name, lifetime, idle timeout) is defined at the global level and applies to all proxy apps. Some legacy applications have their own login flows in addition to the identity headers. The upstream login feature automates posting credentials to the upstream’s login form after the Orchestrator has authenticated the user, handling the “double login” problem.

Setup

Console UI
Configuration

HTTP Proxy mode does not have deployment-level settings in the Maverics Console. Unlike OIDC Provider, SAML Provider, LDAP Provider, and MCP Provider — which are configured in the Deployment Settings dialog — HTTP Proxy is configured entirely at the application level.To configure an HTTP Proxy application in the Console:

Navigate to Applications in the Maverics Console.
Create or select a proxy application.
Configure route patterns, upstream URL, headers, authentication policies, and authorization rules within the application’s settings.

Each proxy application manages its own routes, header injection, and location-based policies. See the Proxy App page for the complete field reference.

The Deployment Settings dialog does not include an HTTP Proxy section. All HTTP Proxy configuration is done through the Applications section of the Console. Some advanced options (Service Extensions for modifyRequestSE, modifyResponseSE, handleUnauthorizedSE, upstream login) are only available in YAML.

This example shows a proxy app protecting a legacy application with header injection, authentication policy, and logout configuration.

maverics.yaml

connectors:
  - name: my-idp
    type: oidc
    oidcWellKnownURL: https://idp.example.com/.well-known/openid-configuration
    oauthClientID: my-client
    oauthClientSecret: <my_client_secret>
    oauthLoginRedirect:
      urls:
        - https://app.example.com/oidc-callback
    scopes: openid profile email

apps:
  - name: legacy-app
    type: proxy
    routePatterns:
      - app.example.com/
    upstream: https://backend.internal:8443
    tls: upstream
    headers:
      - name: SM_USER
        value: "{{ my-idp.email }}"
      - name: X-User-Name
        value: "{{ my-idp.name }}"
      - name: X-User-Given-Name
        value: "{{ my-idp.given_name }}"
    policies:
      - location: /
        authentication:
          idps:
            - my-idp
        authorization:
          allowAll: true
      - location: /admin
        authentication:
          idps:
            - my-idp
        authorization:
          rules:
            - and:
                - equals: ["{{ my-idp.role }}", "admin"]
          rulesAggregationMethod: "and"
    logout:
      logoutURL: /logout
      postLogoutRedirectURL: https://app.example.com/

Configuration Reference

HTTP Proxy mode does not have a separate provider-level configuration key. The HTTP server settings (listen address, TLS, timeouts) are configured under the http top-level key, documented on the Configuration page. All proxy-specific configuration is at the app level.

Proxy App Configuration

Proxy apps define route patterns, upstream backend URL, header injection, location-based policies, and authorization rules.

Proxy App

Full configuration reference, Console UI setup steps, and troubleshooting for proxy apps

The HTTP Proxy mode works with all Identity Fabric connectors. The Orchestrator authenticates users via any upstream IdP and injects identity headers into proxied requests. These are the most commonly used pairings:

Microsoft Entra ID

Microsoft Entra ID for enterprise SSO

Okta

Okta SSO consolidation

LDAP

Directory attributes for header enrichment

Generic OIDC

Any OIDC-compliant provider

See the connector compatibility matrix for all supported pairings and the Identity Fabric overview for the full connector list. The HTTP Proxy also pairs with:

LDAP Provider — Pair with LDAP Provider mode for applications that need both header-based auth and LDAP directory access
Caches — Distributed session storage with Redis for multi-instance deployments

Proxy App

Full proxy app configuration reference, setup steps, and troubleshooting

LDAP Provider

Virtualize LDAP directories for legacy applications — often paired with HTTP Proxy

OIDC Provider

Configure the Orchestrator as an OpenID Connect authorization server

Identity Fabric

Connect upstream identity providers to the Orchestrator

Architecture and Concepts

Understand how modes fit into the Orchestrator architecture

Console Administration

Orchestration

Use Cases

How It Works

Key Concepts

Route Patterns and Upstreams

Header Injection

Location-Based Policies

Session Management

Setup

Configuration Reference

Proxy App Configuration

Proxy App

Microsoft Entra ID

Okta

LDAP

Generic OIDC

Proxy App

LDAP Provider

OIDC Provider

Identity Fabric

Architecture and Concepts

Console Administration

Orchestration

​Use Cases

​How It Works

​Key Concepts

​Route Patterns and Upstreams

​Header Injection

​Location-Based Policies

​Session Management

​Upstream Login

​Setup

​Configuration Reference

​Proxy App Configuration

Proxy App

​Related Integrations

Microsoft Entra ID

Okta

LDAP

Generic OIDC

​Related Pages

Proxy App

LDAP Provider

OIDC Provider

Identity Fabric

Architecture and Concepts

Use Cases

How It Works

Key Concepts

Route Patterns and Upstreams

Header Injection

Location-Based Policies

Session Management

Upstream Login

Setup

Configuration Reference

Proxy App Configuration

Related Integrations

Related Pages