> ## Documentation Index
> Fetch the complete documentation index at: https://docs.strata.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

<Tip>
  **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.
</Tip>

## 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:

1. **Traffic interception** -- The Orchestrator listens on configured route patterns (hostname/path combinations) and intercepts all matching HTTP requests before they reach the upstream application.
2. **Policy evaluation** -- Each request is matched against location-based policies. The Orchestrator determines which authentication and authorization rules apply based on the request path.
3. **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.
4. **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.
5. **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.
6. **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.

### Upstream Login

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

<Tabs>
  <Tab title="Console UI">
    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:

    1. Navigate to **Applications** in the Maverics Console.
    2. Create or select a proxy application.
    3. 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](/reference/orchestrator/applications/proxy) page for the complete field reference.

    <Note>
      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.
    </Note>
  </Tab>

  <Tab title="Configuration">
    This example shows a proxy app protecting a legacy application with header injection, authentication policy, and logout configuration.

    ```yaml maverics.yaml theme={null}
    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

    <Note>
      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](/reference/orchestrator/configuration#http-server-configuration) page. All proxy-specific configuration is at the app level.
    </Note>

    #### Proxy App Configuration

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

    <Card title="Proxy App" icon="globe" href="/reference/orchestrator/applications/proxy">
      Full configuration reference, Console UI setup steps, and troubleshooting for proxy apps
    </Card>
  </Tab>
</Tabs>

## Related Integrations

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:

<CardGroup cols={3}>
  <Card title="Microsoft Entra ID" icon="microsoft" href="/reference/orchestrator/identity-fabric/azure-ad">
    Microsoft Entra ID for enterprise SSO
  </Card>

  <Card title="Okta" icon="key" href="/reference/orchestrator/identity-fabric/okta">
    Okta SSO consolidation
  </Card>

  <Card title="LDAP" icon="folder-tree" href="/reference/orchestrator/identity-fabric/ldap">
    Directory attributes for header enrichment
  </Card>

  <Card title="Generic OIDC" icon="openid" href="/reference/orchestrator/identity-fabric/custom-oidc">
    Any OIDC-compliant provider
  </Card>
</CardGroup>

See the [connector compatibility matrix](/guides/authentication/choosing-a-mode#connector-compatibility) for all supported pairings and the [Identity Fabric overview](/reference/orchestrator/identity-fabric) for the full connector list.

The HTTP Proxy also pairs with:

* **[LDAP Provider](/reference/modes/ldap-provider)** -- Pair with LDAP Provider mode for applications that need both header-based auth and LDAP directory access
* **[Caches](/reference/orchestrator/caches)** -- Distributed session storage with Redis for multi-instance deployments

## Related Pages

<CardGroup cols={2}>
  <Card title="Proxy App" icon="globe" href="/reference/orchestrator/applications/proxy">
    Full proxy app configuration reference, setup steps, and troubleshooting
  </Card>

  <Card title="LDAP Provider" icon="folder-tree" href="/reference/modes/ldap-provider">
    Virtualize LDAP directories for legacy applications -- often paired with HTTP Proxy
  </Card>

  <Card title="OIDC Provider" icon="openid" href="/reference/modes/oidc-provider">
    Configure the Orchestrator as an OpenID Connect authorization server
  </Card>

  <Card title="Identity Fabric" icon="plug" href="/reference/orchestrator/identity-fabric">
    Connect upstream identity providers to the Orchestrator
  </Card>

  <Card title="Architecture and Concepts" icon="diagram-project" href="/introduction/architecture">
    Understand how modes fit into the Orchestrator architecture
  </Card>
</CardGroup>