Skip to main content
Applications represent the services you are protecting with the Maverics Orchestrator. When you set up a deployment, you configure three things: identity providers (where users authenticate), applications (what you are protecting), and the policies that connect them. Applications are the “what” — each one describes a service the Orchestrator manages on behalf of your users.

​
How Applications Fit into a Deployment

A typical Maverics deployment looks like this:
  1. Identity Fabric — connect one or more identity providers (Entra ID, Okta, LDAP, etc.) that authenticate your users
  2. Applications — register the services the Orchestrator protects, each with a type that matches how the service communicates (HTTP, OIDC, SAML, or MCP)
  3. Policies — define who can access what, which identity providers handle authentication, and what identity information flows to each application
The Orchestrator sits between your users and your applications. When a request comes in, the Orchestrator matches it to an application, authenticates the user or agent against the configured identity providers, evaluates authorization policies, and then takes the appropriate action — forwarding the request with injected headers, issuing an OIDC or SAML token, or translating and proxying MCP tool calls to upstream services.

​
Applications, Policies, and Identity Providers

In both the Maverics Console and YAML configuration, an application’s authentication policies, header mappings, and identity provider bindings are configured directly on the application itself — there is no separate object that ties them together. The typical Console workflow is:
  1. Create an Identity Fabric connector (e.g., Entra ID)
  2. Create an Application (e.g., a proxy app for your legacy HR portal)
  3. Configure the application’s authentication policies, header mappings, and identity provider bindings to control sign-on behavior and what identity information reaches the application
In YAML, the same information is configured directly within each application’s policies, headers, and attrProviders blocks.

​
App Types and Orchestrator Modes

Each application has a type that determines which protocol it uses and which Orchestrator mode it connects to. Choose the app type that matches how your service communicates.
App TypeOrchestrator ModeProtocolWhen to Use
ProxyHTTP ProxyHTTPLegacy apps — identity via headers, no code changes
OIDCOIDC ProviderOIDCModern apps with native OpenID Connect support
SAMLSAML ProviderSAML 2.0Enterprise apps requiring SAML assertions
MCP ProxyAI Identity GatewayMCPAI agents accessing upstream MCP servers
MCP BridgeAI Identity GatewayMCP + RESTExpose REST APIs as MCP tools for AI agents
Looking for Custom APIs? Custom API endpoints (the apis[] configuration) are not an application type. They are managed through Service Extensions. In the Console, create and manage APIs from the Service Extensions area in the sidebar.
Not sure which type fits your service? See the Choosing a Mode guide for a decision framework.

​
App Type Pages

Each app type has its own page with Console UI setup steps and configuration reference.

Proxy App

Identity-aware reverse proxy for legacy and header-based applications

OIDC App

Register OIDC clients with the Orchestrator’s built-in OIDC Provider

SAML App

Register SAML Service Providers with the Orchestrator’s SAML Provider

MCP Proxy App

Proxy MCP traffic to upstream MCP servers with identity injection

MCP Bridge App

Expose REST APIs as MCP tools using OpenAPI specifications

Identity Fabric

Configure the identity providers that authenticate users for your applications

Authorization

Authorization rules that control who can access what

Service Extensions

Custom request/response modification and API endpoints

Sessions

Session storage for user authentication state

Transport Layer Security (TLS)

Named TLS profiles for upstream connections and IdP communication

Choosing a Mode

Decision framework for selecting the right Orchestrator mode