Once you know who a user is, you must decide what they can do. That's access control.
Resource owners grant access at their discretion (e.g., file permissions, sharing a doc). Flexible but error-prone at scale.
The system enforces access based on classification labels (e.g., Secret, Top Secret) — users can't override. Used in military/SELinux contexts.
Permissions are assigned to roles; users get roles. The workhorse of enterprise apps.
User → Role(s) → Permissions
Alice → "Editor" → [read, write articles]
Bob → "Admin" → [read, write, delete, manage users]
Benefits: scalable, auditable, easy onboarding/offboarding by role.
Decisions use attributes (user dept, resource sensitivity, time, location, device posture). Most flexible; powers fine-grained and zero-trust policies.
ALLOW if user.dept == resource.dept
AND user.clearance >= resource.level
AND request.time in businessHours
| Practice | Why |
|---|---|
| Joiner-Mover-Leaver | Provision/adjust/revoke access as roles change |
| Access reviews / recertification | Periodically confirm access is still needed |
| Separation of duties | No one person controls a whole critical flow |
| Orphaned account cleanup | Disable accounts of departed users promptly |
Privilege creep — users accumulating access over years — is a major risk. Regular access reviews are the cure.
It's not just humans. Services, containers, and CI pipelines need identities too:
Zero Trust depends on strong identity + fine-grained authorization + continuous verification. RBAC gives you the baseline; ABAC and device posture checks give you the precision Zero Trust requires.