Authorization

The Authorization module decides what a signed-in user is allowed to do. Its subtitle: "Manage roles, resources, and access control for the selected environment."

Each environment uses exactly one authorization model, and the model you pick changes which tools appear in the rail. Configuration for the other models is preserved when you switch, so experimenting is safe.

Model

?tab=model — "Authorization model": "Choose how access is decided for this environment." Three cards, with a checkmark and "Active model" on the current one:

RBAC — Role-Based Access Control (default)

"Assign roles to users and map CRUD permissions per resource. The right default for most applications."

• Roles & resources
• Groups
• Simple to reason about

ABAC — Attribute-Based Access Control

"Write policies that decide access from user, resource, and environment attributes. Evaluated by a built-in policy engine."

• Rego policies
• Attribute-driven
• Fine control per request

FGA — Fine-Grained Authorization

"Model relationships between users and resources, Zanzibar-style, for relationship-based access at scale."

• Relationship tuples
• Inherited permissions
• Scales to graphs

Click "Use this model" to switch. The rail immediately swaps to that model's tools.

Analytics

?tab=authzAnalytics — how often access checks run and how often they deny, over the selected time range. A rising deny rate after a model change is the signal to look at.

RBAC tools

These three tabs appear when the model is RBAC.

Resources

?tab=resources — "Manage your resources. Create new resources with optional descriptions."

A resource is a thing you protect: invoice, project, vault. The table shows Resource, Slug, Description, and actions. Each resource gets an auto-generated slug (for example vault-5a0e1c) with a copy button — that slug is what your permission checks reference. "Add Resource" creates one; "Migrate selected" moves resources between models.

Roles

?tab=roles — "Define roles and map permissions to roles."

The table has one column per CRUD verb: CREATE, READ, UPDATE, DELETE. Click "Add Role", name the role, then tick the verbs it may perform on each resource. Empty environments read "No roles created yet — click 'Add Role' to create your first role."

Groups

?tab=groups — "Assign users to groups; users inherit the group's permissions."

Groups are the practical unit for assignment: give a group its roles once, then add users to the group. The view has three sub-tabs — Groups, Members, and Permissions — with a count on each. The table lists Name, Slug (with copy button), Members count, Description, and a row menu. "New Group" creates one.

Groups are also the target of SCIM group sync: Users > Provisioning maps an IdP group name onto a role, so directory membership drives permissions automatically.

ABAC tools

Policies

?tab=abac — write and test Rego policies evaluated by the bundled policy engine. A policy receives the user, the resource, the action, and environment attributes, and returns an allow or deny decision. Policies are versioned per environment.

FGA tools

Relationships

?tab=fga — manage relationship tuples of the form (user, relation, object), for example user:ada is editor of doc:budget-2026. Permissions are then derived by walking the graph, including inherited relations.

Checking permissions from your app

Whichever model an environment uses, your application asks the same question through the AuthZEN-compatible policy decision endpoint, or through the SDK helpers. The model is a server-side detail — switching from RBAC to ABAC does not change your call sites.

See Permissions for the client-side API, FGA for relationship modelling, and AuthZEN for the decision endpoint contract.

Related