---
title: "Authorization"
url: "/docs/security/authorization/"
kind: "concept"
summary: "Choose between RBAC rules, Cedar policies, and your own ext_proc or WASM extension for deciding what a caller may do."
---

> Arion site index: [/llms.txt](/llms.txt)

# Authorization

Choose between RBAC rules, Cedar policies, and your own ext_proc or WASM extension for deciding what a caller may do.

Authorization decides what an already-identified caller is allowed to do. Arion offers three ways to make that decision in the request path, and picking the right one is mostly a question of how much context the decision needs.

## The three options

**RBAC** is a set of declarative allow/deny policies evaluated in-process against connection and request properties — source IP, destination port, SNI at the network level; headers, method and path at the HTTP level. It is the fastest option and supports a per-route override, but it cannot reason about anything beyond those properties. Reach for it for IP allowlists, blocking paths, or coarse header-based rules. See [RBAC](@/docs/security/rbac.md).

**Cedar policies** evaluate a real policy language in-process against a richer picture of the request: the JWT principal, the HTTP method, path and query, and the token's claims. Policies are auditable text (`permit`/`forbid` statements) with deny-by-default semantics, so they suit per-user and per-client rules like "this service may only GET under /reports". See [Cedar policies](@/docs/security/cedar-policies.md).

**Your own extension** is the route when the decision needs data Arion does not have — a database lookup, a quota service, an entitlements API. Write it as an [ext_proc](@/docs/extend/ext-proc.md) server that Arion calls over gRPC, or as a [WASM filter](@/docs/extend/wasm-filters.md) running inside the proxy. Both can inspect the request and reply with a direct response (for example a 403) before anything reaches the backend.

## Comparison

| Approach | Decision model | Runs | Per-route control | When to pick |
|---|---|---|---|---|
| RBAC | Allow/deny policies | In-process | Override or disable per route | Fast, coarse rules on IPs, ports, SNI, headers, method and path. |
| Cedar | Policy language | In-process | One policy set per filter chain | Identity-aware rules over JWT claims and request context, kept as reviewable policy text. |
| ext_proc / WASM | Your code | Sidecar gRPC server, or WASM in-process | Per-route override (ext_proc) | Decisions that need external data or logic no built-in filter expresses. |

## What about ext_authz?

Envoy's `ext_authz` filter (HTTP and network) is not supported today — a configuration that references it is refused at startup. The supported path for external authorization is an ext_proc server or a WASM filter, which cover the same "call my service before routing" pattern.

## Layering

The options compose along the filter chain, and each filter only sees what ran before it. A common arrangement: network RBAC drops unwanted sources at accept time, [JWT authentication](@/docs/security/jwt.md) establishes who is calling, then Cedar (or HTTP RBAC) decides what that caller may do. Put authentication before authorization — Cedar reads the claims that the JWT filter validated.

## Key terms

- **Principal** — who is asking: an IP, a header value, or a JWT subject.
- **Policy** — a named rule that permits or denies a (principal, request) pair.
- **Deny by default** — in Cedar, anything not explicitly permitted is forbidden; in RBAC, the `action` decides whether matching means allow or deny.

Continue with [RBAC](@/docs/security/rbac.md) for the declarative rules, [Cedar policies](@/docs/security/cedar-policies.md) for the policy language, or [extending Arion](@/docs/extend/overview.md) to build your own filter.