Skip to main content
Authorization rules determine whether an authenticated user is allowed to access a resource. These rules apply whether configured via Console UI or Configuration (YAML). Rules support nested and/or conditions with four comparison operators.
Authorization approaches vary by Orchestrator mode. The declarative rules documented on this page (allowAll, rules array, operators) apply to HTTP Proxy, OIDC Provider, and SAML Provider modes. These three modes also support programmatic authorization via Service Extensions (isAuthorizedSE) as an alternative or supplement to declarative rules. AI Identity Gateway uses OPA (Rego) policies for per-tool authorization instead of declarative rules. LDAP Provider handles authorization entirely through Service Extensions — there is no declarative authorization layer. See Per-Mode Authorization Differences for a full comparison.

​
How Authorization Works

Authorization in the Maverics Orchestrator follows a pipeline that evaluates after authentication completes. Understanding this pipeline helps you design effective authorization rules and troubleshoot access issues.
  1. Authentication completes — The user’s identity is established through the configured identity provider(s). At this point, the Orchestrator has the user’s claims and attributes available for evaluation.
  2. Orchestrator evaluates authorization rules — The Orchestrator checks the authorization configuration for the matched application or policy location. If allowAll: true is set, no further evaluation occurs and the user is authorized.
  3. Rules reference connector attributes — Each rule operand uses template syntax {{ connector.attribute }} to reference claims from named connectors (e.g., {{ azure.groups }}, {{ ldap.role }}). The Orchestrator resolves these templates against the authenticated user’s attributes.
  4. Rules are aggregated — Individual rule results are combined according to rulesAggregationMethod. With "and", all rules must pass. With "or", any single rule passing is sufficient.
  5. Service Extension runs (if configured) — If isAuthorizedSE is configured, the Service Extension executes after declarative rule evaluation and can override or supplement the result.
  6. Access decision is applied — If authorized, the request proceeds to the application. If denied, the behavior depends on the mode (see Enforcement Behavior below).

​
Simple Authorization

Allow all authenticated users access to a resource: 
authorization:
  allowAll: true
When allowAll is set to true, any user who has successfully authenticated through the configured identity providers is granted access. No further rule evaluation occurs.

​
Rule-Based Authorization

Rules are defined as an array of conditions. Each rule contains either an and block (all conditions must match) or an or block (any condition may match). 
authorization:
  rules:
    - and:
        - equals: ["{{ ldap.role }}", "admin"]
        - contains: ["{{ ldap.memberOf }}", "cn=managers"]
    - or:
        - equals: ["{{ http.request.method }}", "GET"]
        - notContains: ["{{ ldap.department }}", "restricted"]
  rulesAggregationMethod: "and"
In this example, the first rule requires the user to be an admin AND a member of the managers group. The second rule allows GET requests OR users not in the restricted department. Both rules must pass (rulesAggregationMethod: "and").

​
Operators

OperatorDescriptionOperands
equalsExact string matchExactly 2 operands
notEqualsInverse exact matchExactly 2 operands
containsSubstring or membership checkExactly 2 operands
notContainsInverse substring/membership checkExactly 2 operands

​
Operand Formats

Each operator takes exactly two operands. Operands can be:
  • Template variable: {{ connector.attribute }} — references a claim from a named connector (e.g., {{ azure.groups }}, {{ ldap.role }})
  • HTTP request: {{ http.request.method }} — references the HTTP request method
  • Literal string: "admin" — a static comparison value

​
Rule Aggregation

The rulesAggregationMethod field controls how top-level rules in the array are combined:
  • "and" — All rules must pass for the user to be authorized
  • "or" — Any single rule passing is sufficient for authorization
When not specified, the default behavior treats each top-level rule independently.

​
Example

A complete policy configuration with nested authorization rules:
maverics.yaml
policies:
  - location: "/"
    authentication:
      idps: ["azure", "ldap"]
    authorization:
      rules:
        - and:
            - equals: ["{{ ldap.role }}", "admin"]
            - contains: ["{{ ldap.memberOf }}", "cn=managers"]
        - or:
            - equals: ["{{ http.request.method }}", "GET"]
            - notContains: ["{{ ldap.department }}", "restricted"]
      rulesAggregationMethod: "and"

​
Enforcement Behavior

What happens when authorization denies a request depends on the Orchestrator mode. Understanding denial behavior helps you design appropriate error handling and user experiences.
  • HTTP Proxy mode — Returns a 403 Forbidden response to the client. The request never reaches the upstream application. If unauthorizedPage is configured on the policy, the user is redirected to that URL instead of receiving a 403. Alternatively, handleUnauthorizedSE can provide custom denial handling via a Service Extension.
  • OIDC Provider mode — Authorization rules are evaluated at the policy level. Denial prevents token issuance — the user receives an error response at the authorization endpoint. The client application’s redirect URI is not called with valid tokens.
  • SAML Provider mode — Similar to OIDC — denial prevents SAML assertion generation. The user receives an error at the SSO endpoint. The service provider’s assertion consumer service URL does not receive a valid assertion.
  • AI Identity Gateway — OPA policies evaluate per-tool invocations. Denial returns an error to the AI agent for that specific tool call. Other tools the agent is authorized to use remain accessible.
  • LDAP Provider — Authorization is typically handled within Service Extensions rather than declarative rules. The authenticateSE controls bind success/failure, and the searchSE controls which entries are returned. There is no separate declarative authorization layer.
When allowAll: true is set, no rule evaluation occurs and all authenticated users are authorized. This is the simplest configuration and is useful for applications where authentication alone is sufficient access control.

​
Per-Mode Authorization Differences

Authorization works differently across modes. This table summarizes the key differences to help you configure authorization correctly for your deployment pattern.
AspectHTTP ProxyOIDC ProviderSAML ProviderLDAP ProviderAI Identity Gateway
Rule locationapps[].policies[].authorizationapps[].authorizationapps[].authorizationService Extension (no declarative rules)apps[].authorization.inbound.opa
GranularityLocation-based (per URL path)Per-app (per OIDC client)Per-app (per SAML SP)Per-operation (SE-controlled)Per-tool invocation
Dynamic checksisAuthorizedSE availableisAuthorizedSE availableisAuthorizedSE availableAll logic is SE-drivenOPA policies with rich input context
External policy engineDeclarative rules or SEDeclarative rules or SEDeclarative rules or SESE onlyOPA (Rego-based policies)
Denial behavior403 Forbidden or redirectError at authorization endpointError at SSO endpointBind failure or empty search resultsError on specific tool call

​
Service Extension Hooks

The isAuthorizedSE Service Extension hook provides programmatic authorization control beyond what declarative rules can express. It is available in HTTP Proxy, OIDC Provider, and SAML Provider modes. How it works:
  • Runs after declarative rule evaluation (if rules are also configured)
  • Can override or supplement declarative rule results
  • Has access to the full Orchestrator API through the api parameter — including sessions, caches, connectors, secret providers, and logging
  • Receives the HTTP request context, enabling authorization decisions based on request path, headers, method, or body content
Configuration: 
authorization:
  isAuthorizedSE:
    funcName: CustomAuthorize
    file: /etc/maverics/extensions/authorize.go
For implementation details, function signatures, and the full SDK interface, see Service Extensions.

​
Authorization Patterns

The following examples demonstrate common real-world authorization configurations.

​
Role-Based Access Control (RBAC)

Check user group membership from Azure AD to grant access based on role. This is the most common authorization pattern. 
authorization:
  rules:
    - and:
        - contains: ["{{ azure.groups }}", "app-admins"]

​
Multi-Source Authorization

Combine attributes from multiple identity connectors to make authorization decisions. This is useful when identity data is spread across multiple systems. 
authorization:
  rules:
    - and:
        - equals: ["{{ okta.department }}", "engineering"]
        - contains: ["{{ ldap.memberOf }}", "cn=developers"]
  rulesAggregationMethod: "and"

​
Path-Based Access Tiers (HTTP Proxy)

Apply different authorization rules to different URL paths within the same application. This enables tiered access where public areas require only authentication while sensitive areas require specific roles. 
policies:
  - location: "/"
    authentication:
      idps: ["azure"]
    authorization:
      allowAll: true
  - location: "/admin"
    authentication:
      idps: ["azure"]
    authorization:
      rules:
        - and:
            - equals: ["{{ azure.role }}", "admin"]

Apps & Routes

Application configuration including authentication policies and authorization rules

Identity Fabric

Identity connector configuration referenced in authorization rule operands

Service Extensions

Custom authorization logic via the isAuthorizedSE hook and the SE SDK

Sessions

Session management that works alongside authorization decisions

How Auth Works

Understand the full authentication and authorization flow

Choosing a Mode

Compare all 5 Orchestrator modes and their authorization models