Choosing an Orchestrator Mode

The Maverics Orchestrator operates in five modes, each designed for a different protocol and deployment pattern. Choosing the right mode depends on what protocol your application speaks, whether you can modify the application, and what identity operations you need. Most deployments use one or two modes; some use three or more simultaneously. This guide helps you compare all five modes side-by-side so you can pick the right one without reading each mode page individually. If you already know which mode you need, jump to the mode-specific guides linked at the bottom of this page. All five modes share the same Orchestrator binary, configuration framework, and Service Extension SDK. The difference is in how identity is delivered to your applications — tokens, assertions, HTTP headers, LDAP entries, or OAuth-scoped MCP context.

​

Decision Matrix

The following table compares all five modes across the criteria that matter most when choosing a deployment pattern.

​

Decision Flowchart

Use this decision tree to identify the right mode for your application. Start at question 1 and follow the path that matches your situation.

1. Does your application support OpenID Connect natively? If yes, use OIDC Provider. OIDC is the modern standard for authentication — if your app supports it, this is the most straightforward mode. (Your IdP does not need to support OIDC — the Orchestrator can translate from any upstream protocol.)
2. Does your application only support SAML 2.0? If yes, use SAML Provider. Many enterprise apps (Salesforce, ServiceNow, Workday) require SAML assertions for federated SSO.
3. Can you NOT modify the application’s authentication code at all? If yes, use HTTP Proxy. The Orchestrator sits in front of the app as a reverse proxy, handling authentication and injecting identity headers without any changes to the application.
4. Does your application require LDAP directory lookups for authentication or user data? If yes, use LDAP Provider. The Orchestrator presents a virtual LDAP directory backed by modern cloud identity providers. This mode is often paired with HTTP Proxy for comprehensive legacy stack modernization.
5. Are you securing AI agent-to-tool communication via MCP? If yes, use AI Identity Gateway. This mode adds identity, authorization, and audit to Model Context Protocol connections between AI agents and enterprise tools.

​

Protocol Translation

The Orchestrator’s mode determines what protocol your application speaks. The Identity Fabric connector determines what protocol your identity provider speaks. These are completely independent. This means you do not need to match your IdP’s protocol to your application’s protocol. For example:

• An application that only speaks SAML can authenticate against an OIDC-only IdP (using SAML Provider mode with an OIDC connector)
• An application that only speaks OIDC can authenticate against a SAML-only IdP (using OIDC Provider mode with a SAML connector)
• An application behind HTTP Proxy can authenticate against an LDAP directory or any OIDC/SAML provider

The Orchestrator handles all protocol translation transparently. When choosing a mode, focus on what protocol your application requires — the IdP side is handled by the connector, which can speak any supported protocol.

​

Connector Compatibility

Every Orchestrator mode works with every Identity Fabric connector — the Orchestrator handles protocol translation between your identity provider and your application. However, some connectors are more commonly used with certain modes. The table below shows the typical pairings and notes for each combination. Common = frequently used pairing. Possible = works but less typical. Rare = technically possible but uncommon. All connectors work with all modes — the Orchestrator handles protocol translation. Continuity connectors aggregate multiple IdPs for failover and are mode-agnostic.

​

Common Combinations

Modes can run simultaneously on the same Orchestrator instance. Here are the most common combinations and when to use them.

​

OIDC Provider + HTTP Proxy

Use this combination when your organization has both modern and legacy applications. Modern apps consume OIDC tokens directly from the Orchestrator’s OIDC Provider. Legacy apps that cannot be modified receive identity through HTTP headers injected by the proxy. Both share the same upstream identity providers and session infrastructure.

​

HTTP Proxy + LDAP Provider

Use this combination for full legacy stack modernization. Many legacy applications depend on both header-based authentication (for the web tier) and LDAP directory lookups (for user data and group membership). Running both modes on the same Orchestrator provides a complete identity bridge — the proxy handles HTTP traffic while the virtual directory handles LDAP queries, both sourcing identity from modern cloud providers.

​

OIDC Provider + SAML Provider

Use this combination to bridge modern and enterprise authentication protocols. The Orchestrator acts as both an OIDC authorization server and a SAML identity provider simultaneously. This enables protocol translation — upstream OIDC identity providers can feed downstream SAML service providers, or vice versa — making IdP migration possible without changing application configurations on either side.

​

Deployment Topologies

The Common Combinations section above describes modes running together on a single Orchestrator instance. In production, organizations typically deploy multiple separate Orchestrator instances, each named and configured for a specific role. The Console manages all deployments from a single pane of glass. The patterns below are common starting points — many permutations are possible depending on your organization’s needs.

​

Auth Provider

A centralized deployment running OIDC Provider and SAML Provider modes together. This deployment acts as the organization’s identity broker — modern apps connect via OIDC, enterprise apps connect via SAML, and both share the same upstream identity providers and session infrastructure. This is the most common starting point for organizations adopting the Orchestrator.

​

AI Identity Gateway

A standalone deployment running only AI Identity Gateway mode. It secures MCP connections between AI agents and enterprise tools, enforcing identity, authorization, and audit on every tool invocation. Typically deployed alongside (but separate from) the Auth Provider so that AI identity workflows are isolated from traditional authentication traffic.

​

HTTP Proxy

HTTP Proxy deployments follow two common patterns depending on the environment. Centralized proxy — A single HTTP Proxy deployment fronting multiple legacy applications. This is simpler to manage and works well when applications share similar authentication patterns and header requirements. Per-application proxy — A dedicated HTTP Proxy deployment for each legacy application. This provides isolation — each app gets its own configuration, policies, and scaling. Use this pattern when applications have different authentication requirements or when teams manage their own infrastructure.

​

LDAP Provider

LDAP Provider deployments also follow two common patterns. Centralized — A single LDAP Provider deployment serving multiple LDAP-consuming applications across the network. This minimizes the number of deployments to manage and works well when applications share similar directory schemas. Co-located — An LDAP Provider deployed on the same server (or in the same pod) as the LDAP-consuming application. This keeps LDAP traffic local — the application connects to localhost rather than sending LDAP queries across the network. Use this pattern in security-sensitive environments or for applications with high LDAP query volume.

​

Mode-Specific Guides

​

Mode Reference Pages