Getting started Community Training Tutorials Documentation APIs, AI & Tools
- policyRef:
name: graphql-access-control-flex
config:
rules: <array> // REQUIRED, list of Cedar policy statements; can't be empty
Policy Name |
GraphQL Access Control |
Summary |
Authorizes incoming GraphQL requests by evaluating Cedar rules |
Category |
Security |
First Omni Gateway version available |
v1.14.0 |
Release Notes |
|
Returned status codes |
403 Forbidden — No rule authorizes the request. The response body is a JSON object with an |
The GraphQL Access Control policy authorizes each incoming GraphQL request against a set of Cedar rules that you define. Cedar is an open-source policy language that expresses authorization as permit and forbid statements. Omni Gateway allows a request only when at least one permit rule matches it and no forbid rule matches.
Use this policy to enforce fine-grained, attribute-based authorization on GraphQL traffic. For example, you can restrict mutations to privileged clients, allow specific named operations, or gate access by request header, SLA tier, or source IP address.
To make identity-based decisions, apply an upstream authentication policy, such as Basic Authentication, Client ID Enforcement, JWT Validation, OAuth 2.0 Token Introspection, or OpenID Connect, before this policy. The authentication policy populates the principal that the rules evaluate. When no authentication policy runs, Omni Gateway evaluates the request against the Client::"None" principal. For the attributes that each authentication policy provides, see Attributes Available to Cedar Rules.
After Omni Gateway extracts the GraphQL operation text, the policy evaluates your rules against the request. The policy skips persisted queries and passes them to the upstream service without authorization checks, because Omni Gateway doesn’t inspect their operation text. Non-GraphQL requests also pass through.
When you apply the policy via declarative configuration files, Refer to the following policy definition and table of parameters:
- policyRef:
name: graphql-access-control-flex
config:
rules: <array> // REQUIRED, list of Cedar policy statements; can't be empty
| Parameter | Required | Default Value | Description |
|---|---|---|---|
|
Yes |
None |
A list of Cedar policy statements that authorize requests. Each statement must be a valid Cedar |
When you apply the policy from the UI, the following parameters are displayed:
| Field | Description | Default Value | Required |
|---|---|---|---|
Rules |
The list of Cedar policy statements that authorize requests. Add one entry per |
None |
Yes |
Cedar rules authorize a request by matching against attributes of the principal, which is the authenticated client, and the request context. Use these attributes in the when clause of a rule to make fine-grained decisions.
Cedar rules can match requests against these context attributes:
| Attribute | Description |
|---|---|
|
The value of a request header. Use bracket notation to access header names that contain characters such as dashes, for example, |
|
The raw GraphQL operation text. |
|
The name of the resolved operation. If the request provides an |
|
The type of the resolved operation: |
|
The name of the first top-level field in the resolved operation. |
|
The source IP address of the request, when available. |
Cedar rules can also match requests against these principal attributes. You must apply an authentication policy before the GraphQL Access Control policy to populate these values. To learn what policies update which attributes, see Authentication Policies Principal Attributes.
| Attribute | Description |
|---|---|
|
The authenticated principal identifier, such as the Basic Authentication username or the raw token. |
|
The client ID resolved by the upstream authentication policy, when available. |
|
The client application name resolved by the upstream authentication policy, when available. |
|
Additional properties published by the upstream authentication policy. For example, JWT Validation exposes |
|
The SLA tier ID of the client, when an upstream policy publishes it. |
|
The human-readable SLA tier name that corresponds to |
When no authentication policy runs, Omni Gateway evaluates the request against the Client::"None" principal, and these principal attributes are empty.
Apply an authentication policy before this policy to populate the principal attributes that your Cedar rules evaluate.
The authentication policy you apply affects the available Cedar principal bindings:
Multiple policies can validate Client ID:
OAuth 2.0 Token Introspection Policy (If Client ID enforcement is configured)
OpenID Connect OAuth 2.0 Token Enforcement Policy (If Client ID enforcement is configured)
JWT Validation Policy (If Client ID enforcement is configured)
Policies validating Client ID provide these Cedar bindings:
principal.client_name: Name of the contract’s client application
principal.principal: ID of the contract’s client application
principal.properties.slaId: SLA ID assigned to the contract
principal.properties.claims.<claimName>: All claims provided by the JWT
Multiple policies validate basic authentication credentials:
Basic Authentication: LDAP Policy
Policies validating basic authentication credentials provide these Cedar bindings:
principal.principal: Username passed as basic auth user
For custom authentication policies, the custom policy must authenticate by using the Authentication injectable. To configure the Authentication injectable, see Accessing Request Authentication Information.
For the Rust AuthenticationData structure:
pub struct AuthenticationData {
pub principal: Option<String>,
pub client_id: Option<String>,
pub client_name: Option<String>,
pub properties: Value,
}
The AuthenticationData parameters map to these Cedar bindings:
principal: principal.principal
client_name: principal.client_name
properties: principal.properties.*
These examples are valid whether you configure the policy in a Local Mode resource file or through the Omni Gateway UI.
This example permits queries from any client but restricts mutations to clients that authenticate as admin:
- policyRef:
name: graphql-access-control-flex
config:
rules:
- permit(principal, action, resource) when { context.operationType == "query" };
- permit(principal, action, resource) when { principal.principal == "admin" };
This example permits requests only from internal callers that a request header identifies, and blocks introspection-style queries against the __schema root field:
- policyRef:
name: graphql-access-control-flex
config:
rules:
- permit(principal, action, resource) when { context.headers["x-internal"] == "true" };
- forbid(principal, action, resource) when { context.rootField == "__schema" };