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 and User Flows

In the Maverics Console, applications and policies are connected through User Flows. A User Flow is a Console-only concept that ties together an application, its authentication policies, header mappings, and identity provider bindings into a single manageable unit. 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. Create a User Flow that binds the application to the identity provider, defines sign-on policies, and configures what identity information reaches the application
In YAML configuration, there is no separate “User Flow” object — 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
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