Lion Cipher Lab

Build Attribute-Based Access Control (ABAC) — and see where RBAC runs out

• Identity & Access Management
• Intermediate
• ~50 min
• Free · no account required

Why it matters

Almost every access decision that actually bites in the real world is CONDITIONAL: a doctor may read a chart, but only for their own patients; an engineer may deploy, but only during business hours and only to their own team's service; a contractor may view a document, but only if it is not classified above their clearance and only from a corporate IP. Role-Based Access Control — the model most people reach for first — answers 'what can this role do?' and it is excellent for coarse, stable grants. But the moment access depends on the relationship between the person and the specific thing, or…

What you'll learn

• explaining the 'role explosion' problem: why RBAC needs a new role for every combination of context, and how that becomes unmanageable when access depends on relationships and conditions
• defining an attribute-based access decision as Subject × Action × Resource × Environment → Permit/Deny, where attributes — not roles — drive the answer
• building a tiny ABAC engine in ~40 lines of pure-Python standard library: an authorize(subject, action, resource, environment) function evaluated against small policy predicates
• writing policy rules as predicates over attributes (subject.department, subject.clearance, resource.owner, resource.classification, environment.time, environment.mfa) and watching one subject get Permit for one resource and Deny for another
• mapping your engine onto the NIST SP 800-162 model: Policy Decision Point (PDP), Policy Enforcement Point (PEP), Policy Information Point (PIP), and Policy Administration Point (PAP)
• recognizing how the same idea is expressed at scale in Open Policy Agent / Rego, and in AWS IAM with condition keys and tags (aws:PrincipalTag, aws:ResourceTag, Condition blocks)
• judging WHEN ABAC beats RBAC (context- and relationship-dependent access, many fine-grained rules) and WHEN RBAC is still better (small, stable role sets), including ABAC's real cost: harder auditability of 'who can access X?'
• choosing the hybrid most organizations actually run: coarse RBAC grants narrowed by ABAC conditions, and knowing where ReBAC (relationship-based) fits alongside

Steps in this lab

1. Where RBAC runs out — the 'role explosion' problem
2. The ABAC idea: Subject × Action × Resource × Environment → Permit/Deny
3. Set up: confirm Python and make a file (no installs needed)
4. Build the ABAC engine: attributes, predicates, and authorize()
5. Run it: watch the SAME subject flip from Permit to Deny
6. Name the parts: PDP, PEP, PIP, PAP (the NIST model)
7. The real world: OPA / Rego and AWS IAM condition keys
8. The judgment: when ABAC beats RBAC, when RBAC still wins, and the hybrid
9. What you did — and the reflex to keep

Open the full interactive lab →