Authorization

Mental model

ReBAC stores tuples and resolves permissions from a resource definition:

ResourceDefinition "Document"
  relations: { owner: [User, Team], editor: [User, Team] }
  permissions: { read: [editor, owner, owner->read], edit: [editor, owner] }

Tuple:   Team:abc#owner@Document:xyz
Format:  subject#relation@resource

Check:   can(Team:abc, edit, Document:xyz) → true via team inheritance

Every tuple is persisted as a Relationship document with a unique computedTuple (User:uid#owner@Document:id). Creating or deleting a tuple updates ActorIndex and ObjectIndex rows so can checks avoid graph walks at request time.

Three layers (do not confuse)

This page covers document ReBAC.

Resource definitions

A resource is a named type (e.g. Document, Team) with two JSON maps:

Example:

{
  "name": "Document",
  "relations": {
    "owner": ["User", "Team"],
    "editor": ["User", "Team"]
  },
  "permissions": {
    "read": ["editor", "owner", "owner->read"],
    "edit": ["editor", "owner"],
    "delete": ["owner"]
  },
  "version": 0
}

When a resource definition changes, Conduit schedules a re-index for all tuples involving that type. Schemas with conduitOptions.authorization.enabled automatically register a resource definition matching the schema name.

Relation tuples

Grant access by writing tuples — not by copying permission logic into app code.

Validation on create:

• subject, relation, and resource must be Type:id identifiers
• The target resource's definition must declare the relation
• The subject's type must appear in that relation's allowed list (unless *)

Single-tuple create builds indexes synchronously. Bulk create writes all tuples, then enqueues async index jobs per tuple.

Inheritance (->)

owner->read in a permission rule means: a subject holding owner on this resource inherits the read permission defined on the owner subject's type. For teams, Authentication registers Team with member, owner, and permissions like read, edit, delete — so Team:tid#owner@Document:doc lets team members read via owner->read.

Ownership on create

When scope=Team:tid is set on POST /database/{Schema}:

1. Pre-check: user must have edit on the scope resource
2. Tuple created: Team:tid#owner@{Schema}:{docId} — not a direct User owner tuple

When scope is omitted, the authenticated user becomes User:uid#owner@{Schema}:{docId}.

Built-in Team resource

Authentication registers Team with relations member, owner, readAll, editAll and permissions read, edit, delete, invite, manageMembers, etc. Use these action names — do not invent new ones without extending the definition.

Permission resolution

can(subject, action, resource) resolves in order:

1. Self-access — subject equals resource → allowed
2. Direct permission tuple — explicit subject#action@resource grant
3. Index lookup — ObjectIndex + ActorIndex graph for relation-derived permissions

The Admin /permissions/evaluate endpoint returns the same decision plus the resolution path (assigned direct grant vs inherited index chain) for debugging.

Index reconstruction

Indexes can drift after bulk imports, manual DB edits, or rare worker failures. Operators can rebuild them:

POST ADMIN_BASE_URL/authorization/indexer/reconstruct
Body: { "soft": true | false }   // default false

The endpoint returns "ok" immediately; reconstruction runs in the background (batched, 1000 relations per resource type at a time). During hard rebuild, permission checks may temporarily fail until workers finish — schedule maintenance windows for soft: false.

Surfaces