Role-Based Access Control
Table of Contents
Role-Based Access Control (RBAC) restricts system access to
authorised users based on their job roles, rather than individual
user permissions. By grouping permissions into roles (e.g. admin,
user), the project simplifies access management, enforces least
privilege, and lowers the blast radius of any one compromised
account. RBAC is the model that backs Identity and Access
Management in ORE Studio; the concrete role/permission entities and
their assignments live in ores.iam.core. Return to Knowledge.
1. Key Components of RBAC
- Roles: collections of permissions defining job functions (e.g., "Nurse", "Manager").
- Permissions: specific rights to view, create, or modify data.
- Users: individuals assigned one or more roles.
2. Core Principles
- Role-Based Assignment: users are assigned roles, and permissions are attached to those roles, not the user directly.
- Least Privilege: users receive only the minimum permissions necessary for their role.
- Separation of Duties (SoD): As described in IBM's research, SoD prevents conflicts of interest by requiring multiple people to complete high-risk tasks.
3. Roles in ORE Studio
A role holds explicit permission codes. There is no read wildcard such as
refdata::*:read: a wildcard grants resources that do not exist yet, so an
entity added later would be readable by every role that holds it without
anybody deciding so. * and component::* exist, for the administrator roles
only.
One component is outside *. A code of the installation component, such as
installation::deployment:read, says a session acts on the deployment as a
whole, across every tenant. A tenant's administrator holds *, so * does not
cover an installation code. Only the code itself, or installation::*, grants
one, and the super administrator role holds the code by name.
Every person account holds Member. Member holds the reads every person's screens need and nothing more: the reference data vocabulary, and the furniture every screen uses, such as badges, change reasons, feature flags and pictures. A job role, such as Trading or Operations, holds only what its job adds. An account without Member sees empty screens; that fails closed, and an administrator gives Member back.
A read is classified before it is granted:
| Class | Examples | Granted to |
|---|---|---|
| Vocabulary | Currencies, countries, calendars, day counts, tenors, the status and type lookups | Member |
| Screen furniture | Badge definitions, change reasons, feature flags, pictures | Member |
| Organisation | Names, job titles, pictures and who reports to whom, for the people in your parties and under you | Member, through iam::organisation:read |
| Account | Name, email, job title, picture, status and parties, for the people who work in a party your account works in | Member, through iam::accounts:read. A special case: row-level security limits this read to those accounts. See Multi-Tenancy Architecture, "The accounts exception". |
| Business fact | Parties, counterparties, books, business units, trades | The job roles that need it |
| The reports a party runs | Report definitions and their runs, for the parties the reader works in | Member, through reporting::report_definitions:read, reporting::report_instances:read and reporting::report_error_events:read. A special case: row-level security limits these reads to the parties the reader's session may see, so the code is never a read of the tenant. |
| Personal data | Contact information, sign-ins, sessions | The person, through a self read; administrators |
The reports a party runs are read with two more codes that are not report data.
The health word resolves a run's state to a name, and the state catalogue is
vocabulary, so Member holds dq::fsm_states:read. The schedule cell names the
job the definition runs as, so Member holds scheduler::job_instances:read: a
person who may read a report's runs may read when the scheduler will run it
again.
Which reads are open to every member without any role is decided separately, in Authorised reads. Member is not an exception to that rule: it is a role, stored on the account, that an administrator can see and withhold.
4. Benefits of RBAC
- Simplified Management: reduces the overhead of managing permissions for thousands of users.
- Increased Security: according to the Cloudflare write-up, it limits unauthorised access and reduces the risk of data leaks.
- Compliance: facilitates adherence to data-protection regulations.
5. See also
- Identity and Access — the structure note that orders this cluster, and where to read this page in it.
- Identity and Access Management — the security subsystem that applies this model.
- ores.iam.core — where the role/permission entities live.
- Authorised reads — the rule that every read is guarded unless allowed, and the allow-list.
- Guard every read the security documentation does not allow — the story that adds Member.