Authorization
Examples
Description
A component that determines which resources and operations an authenticated entity can use within the system, based on its identity, role, or attributes. Its purpose is to answer the question "what can this user do?" once their identity has already been verified. It operates autonomously and across the whole system: every time an entity attempts to access a resource or perform an operation, the system silently evaluates whether it has the necessary permissions and grants or denies access according to the defined policies.
Mandatory capabilities
Mandatory capabilities
- Evaluates the permissions of an authenticated entity before allowing access to a resource or the execution of an operation
- Applies access policies defined explicitly by the system (not by end users)
- Operates across the system: present at every point where access to functionality or data is restricted
- Is independent of authentication and comes after it
Additional capabilities
Additional capabilities
- Administrative management of roles and permissions: lets authorized administrators create, modify, and assign roles and permissions to users through a specialized interface
- Fine-grained control: controls access not only to operations but also to specific entities or to individual attributes within an entity
- Evaluation caching: temporarily stores access decisions to reduce the system load of repeated evaluations
- Auditing of access decisions: records which users accessed which resources and when, complementing the general Audit Log
Boundaries
What it is not
- Is not Authentication: authentication verifies who the entity is; authorization determines what it can do once authenticated
- Does not intrinsically include the creation or modification of roles or permissions; when that functionality exists, it takes the form of a specialized Data Manager
- Is not visible to the end user as a functionality of its own: it operates in the background, restricting or enabling access to other components of the system
Information flow
Input
Identity or role of the authenticated entity, and the requested resource or operation
→
Output
Access decision (granted or denied), which enables or blocks the interaction with the requested resource
Variants
- Role-based access control (RBAC): permissions are assigned to predefined roles (administrator, editor, reader), and users inherit the permissions of the role assigned to them. It is the most common model in information systems.
- Discretionary access control (DAC): the owner of a resource determines who can access it and with what level of permissions. Common in document management systems and cloud storage.
- Attribute-based access control (ABAC): permissions are evaluated dynamically based on attributes of the user, the resource, and the context (time of day, location). It allows more granular and flexible policies.
Typical dependencies
- An Authentication component, which provides the verified identity against which permissions are evaluated
- A Database where the definitions of roles and permissions, and their assignments to users, are stored
Mapping to the Digital Board
Manual UpdateOptional
Automatic UpdateNo
Data ConceptsAlways
On-Demand OutputsNo
Automatic OutputsNo
Autonomous ProcessesAlways
| Section | Relationship | Notes |
|---|---|---|
| Manual Update | Optional | Assignment and revocation of roles or permissions by administrators, when the administrative management capability is present. |
| Automatic Update | No | — |
| Data Concepts | Always | Role, Permission, and the assignment between users and roles. |
| On-Demand Outputs | No | — |
| Automatic Outputs | No | — |
| Autonomous Processes | Always | Permission evaluation on every attempt to access a resource or operation. |
Digital Board example
Manual Update
Per-Channel Permission Settings
Role Assignment
Data Concepts
Role
User
Permission
On-Demand Outputs
—
Automatic Update
—
Autonomous Processes
Permission Evaluation
Automatic Outputs
—