Authorization Model Overview
Raytio's authorization model combines role-based permissions, relationship-based access, policy exceptions, and menu visibility. Together these controls determine what a user can do, which records they can access, and which actions appear in the interface.
One authorization model
Authorization (HRM) defines what roles exist, who holds them, what each role is allowed to do, and what each role can see in the UI. It includes:
- User roles — named roles with a type (ABSTRACT, JOB, DUTY, or DATA) that classify the kind of access they represent. See User Roles and Role Hierarchy.
- Role hierarchy — parent–child edges between roles that determine which roles inherit from which. See User Roles and Role Hierarchy.
- User role assignments — the link between a user and the roles they hold.
- Permissions — data-driven definitions of what operations are allowed on which resource groups, with a scope that distinguishes between ALL_RECORDS and OWN_RECORDS access. See Permissions.
- Authorization policies — PERMIT/FORBID rules that control whether a principal (user, role, or customer) can perform a specific action on a specific resource. See Authorization Policies.
- Role menus — which menus and menu entries are visible to each role, controlling what appears in the UI. See Role Menus.
- Relationship-based access — subject/relation/object relationships that express ownership, membership, sharing, and inheritance. See ReBAC Authorization.
- Conditions — optional contextual checks such as valid time windows or allowed network ranges.
For a detailed explanation of the ReBAC engine, see ReBAC Authorization.
How the pieces connect
When an administrator creates or modifies roles and assignments, the authorization model automatically keeps relationship-based access in sync:
| Change | Relationship represented |
|---|---|
| User assigned to a role | The user becomes a member of the role group |
| Role given a parent role | The child role inherits from the parent role |
| Resource created with an owner | The creator or assigned person becomes the owner |
Administrators work in terms of roles, permissions, policies, and menus. The platform uses those settings to answer the question "is this user allowed to do this?"
The access control flow
When a user interacts with the platform, the system evaluates access through several layers:
- Tenant context — access is evaluated only within the user's current tenant.
- Relationships — the platform resolves direct assignments, group memberships, role hierarchy, ownership, and sharing relationships.
- Permissions — permissions define which operations are allowed on which resource groups and with what scope.
- Authorization policies — policies provide targeted PERMIT/FORBID rules for specific users, roles, customers, and resources.
- Menu visibility — role menus control what the user sees in the UI, ensuring the interface only shows actions and navigation items the user is authorised to use.
Internal vs external users
The system distinguishes between two broad categories of user:
- Internal users (Tenant staff) — employees and administrators who manage the platform. Their base role is "Tenant staff" and they typically receive ALL_RECORDS scope, meaning they can see all records within their tenant.
- External users — customers, partners, or other external parties who interact with the platform. Their base role is "External user" and they receive OWN_RECORDS scope, meaning they can only see records they own or that have been explicitly shared with them.
This distinction is enforced through the role hierarchy and permission scopes. See Permissions for details on how scope works.
Design principles
The authorization system is built around several key ideas:
- Data-driven — roles, permissions, policies, and menus are all stored as data, not hard-coded. This allows tenants to customise access control without code changes.
- Single management model — administrators manage roles, permissions, policies, relationships, and menus through one authorization model.
- Automatic synchronisation — changes to roles and assignments are reflected in access decisions without manual coordination.
- Defence in depth — access control operates across relationships, permissions, policies, and menus, so visibility and action checks reinforce each other.
- Tenant isolation — authorization checks only operate within a single tenant's data.