ReBAC Authorization

Raytio's authorization model uses Relationship-Based Access Control (ReBAC), an approach where access decisions are based on the relationships between subjects and objects rather than static permission lists. Relationship-based access expresses facts such as "Alice owns this document" or "Bob is a member of the CRM User group."

Core concepts

Authorization tuples

A tuple is the fundamental unit of the authorization system. Each tuple expresses a single relationship:

subject → relation → object

For example:

Subject	Relation	Object	Meaning
user:alice	owner	document:42	Alice owns document 42
user:bob	member	group:crm_user	Bob is a member of the CRM User group
group:crm_user	parent	group:tenant_staff	CRM User inherits from Tenant Staff

Each tuple has the following structure:

Attribute	Purpose
subject_type	The type of the subject (e.g. user, group)
subject_id	The identifier of the subject
subject_relation	Optional — used for usersets (e.g. team#member means "members of team")
relation	The relationship (e.g. owner, member, viewer, parent)
object_type	The type of the object (e.g. document, group, contact)
object_id	The identifier of the object
condition_name	Optional — the name of an ABAC condition to evaluate
condition_context	Optional — JSON parameters for the condition

Each tuple is unique within a tenant based on the combination of subject, relation, and object fields.

Authorization models

An authorization model defines the types, relations, and relation rules that the system understands. A model specifies:

• Types — the kinds of objects in the system (e.g. document, group, user)
• Relations — the relationships that can exist for each type (e.g. owner, editor, viewer)
• Relation rules — how relations compose, using union, intersection, and difference operators

For example, a model might define that a document type has owner, editor, and viewer relations, and that viewer is the union of direct viewer tuples and anyone who is an editor (since editors can also view).

Relation hierarchy

Relations can be composed using three operators:

• Union — the subject has the relation if any of the component relations is satisfied. Example: viewer = direct_viewer OR editor OR owner
• Intersection — the subject must satisfy all component relations. Example: can_edit = editor AND NOT blocked
• Difference — the subject has the relation from the base set minus the excluded set. Example: active_viewer = viewer BUT NOT suspended

This allows complex access patterns to be expressed declaratively in the model rather than in application code.

How checks work

When the system needs to determine whether a subject has a relation to an object, the check process:

1. Direct tuples — look for a tuple that directly grants the relation (e.g. user:alice → owner → document:42).
2. Computed relations — if the model defines the relation as a union/intersection/difference of other relations, recursively check each component.
3. Usersets — if a tuple uses a subject_relation (e.g. group:crm_user#member), resolve the userset by checking whether the subject is a member of the referenced group.
4. Transitivity — follow parent relations through the group hierarchy to resolve indirect memberships.
5. Conditions — if a matching tuple has a condition, evaluate the condition with the provided context. The tuple only counts if the condition evaluates to true.

Conditions (ABAC)

Tuples can have conditions attached, adding Attribute-Based Access Control (ABAC) capabilities to the ReBAC model. A condition is a named rule with typed parameters.

Supported parameter types include:

string, int, uint, double, bool, timestamp, duration, list_string, list_int, map_string, map_int, ipaddress

For example, a condition might check that the current time is within a valid access window, or that the user's IP address is in an allowed range. The condition is evaluated at check time with context provided by the caller.

Access enforcement

Relationship-based access is evaluated as part of protected resource access. It is used to decide whether the current user has the required relationship to the target object, such as owner, viewer, editor, member, or parent.

This keeps access decisions consistent across the platform, regardless of which feature or workflow is being used.

Performance

The platform evaluates relationship-based access in batches where possible, so list and search screens can filter accessible objects efficiently without checking each object one at a time.

Automatic relationship management

The platform automatically creates and maintains relationship tuples as users, roles, and resources change:

Event	Relationship represented
User assigned to role	User becomes a member of the role group
Role given parent	Child role inherits from parent role
Record created	User becomes owner of the created resource
Role renamed	Related role relationships stay consistent

This automatic synchronisation ensures relationship-based access reflects the current organisational model without manual coordination.

Relationship to roles and permissions

Relationship-based access works alongside roles and permissions:

• Roles, hierarchy, and assignments are represented as membership and parent relationships.
• Permissions and policies determine which operations are available.
• Relationship checks determine whether a user has the required relationship to a specific object.

For the full picture of how these layers connect, see Authorization Model Overview.