Glossary
Role-Based Access Control (RBAC)
An authorisation model where permissions belong to roles, and people get their rights by holding a role. It is the standard way to manage who can do what in an admin panel, an API or a chat room.
General definition
Role-Based Access Control (RBAC) is a way of deciding who may do what in a system by grouping permissions into roles and assigning roles to users. Instead of granting a person the right to read a report, edit a record and invite members one by one, an administrator defines a role such as moderator with those rights and assigns the role. The model was formalised by NIST in the 1990s and standardised as ANSI INCITS 359 in 2004.
RBAC has four moving parts:
- Users: people, service accounts or API clients that need access
- Roles: named job functions such as owner, admin, moderator, agent or member
- Permissions: allowed operations on resources, for example delete message or export data
- Sessions: the set of roles a user activates at a given time, which lets one person hold several roles without all of them applying at once
Roles can be arranged in a hierarchy so that a senior role inherits the permissions of a junior one, and constraints such as separation of duties can stop the same person holding two conflicting roles. This is what makes RBAC scale: when a new employee starts, they get one role assignment, not fifty individual grants, and when the policy changes you edit the role once.
RBAC is usually contrasted with an access control list (ACL), which attaches a list of permitted users directly to each object, and with attribute-based access control (ABAC), which evaluates rules over attributes such as department, time of day or data classification. In practice most platforms combine them: RBAC for broad job functions, ACLs or attributes for exceptions on individual rooms, files or records.
In the Ethora ecosystem
Ethora applies RBAC at two levels. In the admin panel, the app owner can invite team members and give them roles with ACL settings that decide which parts of the App they can manage, such as users, rooms, agents, moderation rules or billing, so a support lead and a developer do not share one all-powerful login. Inside the chat itself, rooms and channels carry their own admin and member permissions for tasks such as inviting, removing and moderating participants.
For programmatic access, permissions are tied to credentials rather than people: API tokens are issued at the App level so a token only reaches that App’s data, and end users authenticate with short-lived JWT chat tokens. Role assignments and the actions taken under them are recorded in the compliance audit trail, which is the evidence auditors ask for when they check who could access regulated data.
