Lesson A13.5
Authorization models help organizations express who or what should access which resources. RBAC organizes permissions around stable responsibilities, while ABAC uses relevant attributes to make more contextual decisions.
This lesson uses fictional roles, attributes, resources, and policy evidence only. It does not require changing real permissions or interacting with any private identity system.
Lesson Progress
High School Advanced • A13: Identity, Zero Trust, and Access Control • Lesson 5 of 10
Readiness Check
0/4 ready
Professional Hook
Suppose every counselor needs the same basic application functions. A role can express that cleanly. But suppose a workload should reach only resources in its own environment, or a partner should retain access only while sponsorship is current. Those decisions may be easier to express with attributes. The goal is not to choose RBAC or ABAC as a winner; the goal is to design authorization that is least-privileged, understandable, maintainable, and reviewable.
Roles explain responsibility. Attributes explain context. Strong designs use each where it adds clarity.
Learning Objectives
Explain role-based access control and attribute-based access control as different ways to model authorization decisions.
Evaluate when roles, attributes, or a hybrid model produce clearer, more maintainable, and more least-privileged access.
Identify role explosion, stale role membership, weak attribute quality, conflicting policy, excessive exception use, and unclear ownership as access-model risks.
Connect RBAC and ABAC to conditional access, federation, workload identity, privileged access, environment separation, lifecycle, and governance.
Build an Access Model Comparison that becomes the fifth artifact in the A13 Enterprise Identity and Zero-Trust Review.
Access Models
Permissions are grouped into roles, and identities receive access by being assigned to those roles.
Strengths
Clear business mapping, easier reviews when roles are well designed, simple explanation, good fit for stable job functions.
Risks
Role explosion, overbroad roles, stale membership, inherited access that no longer matches actual duties.
Good fit
Counselor, teacher, reporting analyst, help-desk operator, application administrator, platform engineer.
Policy evaluates attributes about the identity, resource, action, environment, or context.
Strengths
Flexible and contextual, can express precise conditions, useful when access depends on several properties.
Risks
Complexity, unclear policy logic, stale attributes, poor attribute ownership, difficult troubleshooting if rules are not documented.
Good fit
Environment-aware access, department + data classification decisions, time-bounded project access, workload-to-resource policy.
Roles provide a stable baseline while attributes refine scope or conditions.
Strengths
Balances understandable role structure with contextual precision.
Risks
Can become hard to reason about if roles and attributes overlap, conflict, or lack clear precedence.
Good fit
Production administration, partner support, sensitive reporting, workload access, multi-environment applications.
RBAC Design
A role should represent a recognizable business or technical function rather than a random collection of permissions.
Review: Can a manager or resource owner explain why this role exists?
Roles should not combine unrelated resources simply because the same team sometimes uses both.
Review: Would every member of the role need every permission inside it?
Daily application work should remain distinct from administrative or security-sensitive access.
Review: Can a user perform normal duties without holding standing administrative access?
Development, staging, and production should not automatically share the same access role.
Review: Does a lower-environment role accidentally include production permissions?
A well-designed role can still be risky if the wrong identities remain assigned to it.
Review: Are current members still performing the responsibility the role represents?
Obsolete roles can preserve forgotten permissions and confuse future reviewers.
Review: Is the role still attached to an active business or technical responsibility?
ABAC Design
A policy is only as reliable as the systems that provide department, role, environment, device, project, ownership, or resource attributes.
Review: Who owns the attribute and how current is it?
More attributes do not automatically create stronger security.
Review: Does this attribute meaningfully affect authorization?
Policy can evaluate who the principal is and what kind of resource is being requested.
Review: Are subject and resource attributes clearly distinguished?
Precise ABAC rules should still be readable enough that another reviewer can explain the outcome.
Review: Can the policy decision be explained without reconstructing hidden logic?
An outdated department, project, device, or ownership value can produce the wrong access decision.
Review: What happens when the attribute source is stale or Unknown?
Attributes should be limited to what the authorization decision actually requires.
Review: Is the policy using the minimum relevant metadata?
Decision Dimensions
RBAC view
Often represented as a role such as Counselor or Reporting Analyst.
ABAC view
Could be represented by identity attributes such as department, function, or project.
Decision question: Is the responsibility stable enough to deserve a reusable role?
RBAC view
May require a dedicated sensitive-data or admin role.
ABAC view
Can evaluate resource classification directly.
Decision question: Should the resource itself influence the decision?
RBAC view
Can use separate staging and production roles.
ABAC view
Can compare identity/workload environment against resource environment.
Decision question: Would environment-specific attributes reduce role duplication?
RBAC view
Can assign a temporary role with expiration.
ABAC view
Can evaluate an approved project window or time-bounded attribute.
Decision question: Is the access stable or temporary?
RBAC view
Privileged duties can be grouped into dedicated admin roles.
ABAC view
Additional context can restrict when the role becomes usable.
Decision question: Would a hybrid model better protect high-impact actions?
RBAC view
Partner support can receive a narrow external support role.
ABAC view
Policy can also require sponsor, organization, contract, or expiration attributes.
Decision question: Does external access need both a role and lifecycle attributes?
RBAC view
A workload can receive a service role with approved permissions.
ABAC view
Policy can compare workload, environment, application, and resource attributes.
Decision question: Would workload-to-resource matching benefit from attributes?
RBAC view
Role membership is often easy to review if roles are well named.
ABAC view
Policy may be more precise but harder to explain if attributes and rules are complex.
Decision question: Which model gives reviewers the clearest evidence?
Vocabulary
Role-Based Access Control: permissions are grouped into roles, and identities receive access through role assignment.
Attribute-Based Access Control: policy evaluates attributes about identities, resources, actions, or context.
A named collection of permissions associated with a recognizable business or technical responsibility.
The identities currently assigned to a role.
The uncontrolled growth of many narrowly different roles that become difficult to understand and govern.
A piece of metadata used by policy, such as department, project, environment, resource class, or ownership state.
An attribute describing the requesting identity or workload.
An attribute describing the application, data, service, or object being accessed.
A logical requirement that must be satisfied before a policy produces a specific access outcome.
An authorization design that combines roles with attributes or other contextual policy conditions.
A specific permission, role membership, or access capability granted to an identity.
The structured way an organization represents and decides authorization relationships.
Fictional Access Model Register
Principal
Counselor Workforce Group
Resource
Student Services Portal
Role
Counselor
Attributes
Active workforce state
Decision
Role grants standard counselor workflows; inactive workforce state removes eligibility.
Owner
Student Services Application Owner
Evidence
Role definition + membership review + application authorization logs
Architecture concern
Counselor role must not include unrelated reporting or administrative functions.
Principal
Platform Engineer
Resource
Cloud Management Plane
Role
Platform Administrator Eligible
Attributes
Privileged activation active + production scope
Decision
Role establishes eligibility; contextual attributes control whether privilege is active.
Owner
Platform Engineering
Evidence
Role membership + activation approval + privileged audit
Architecture concern
Eligibility must remain separate from standing active privilege.
Principal
Scheduling Partner Support
Resource
Scheduling Integration Console
Role
External Integration Support
Attributes
Sponsor current + partner organization + review not expired
Decision
Role defines support functions while attributes enforce external lifecycle conditions.
Owner
Integration Owner
Evidence
Role + sponsor + federation + review date + authorization logs
Architecture concern
Partner review is due in 30 days.
Principal
Analytics Staging Workload
Resource
Staging Analytics Dataset
Role
None required
Attributes
workload=analytics; environment=staging; resource.environment=staging
Decision
Allow when workload and resource environment/purpose match.
Owner
Analytics + Data Platform
Evidence
Workload identity + deployment metadata + resource attributes + access logs
Architecture concern
Policy must deny when the same staging workload requests production resources.
Principal
Reporting Analyst
Resource
Sensitive Report Export Function
Role
Reporting Analyst
Attributes
resource.classification=sensitive + approved export purpose
Decision
Base role allows dashboard use; sensitive export requires additional contextual policy.
Owner
Analytics Product Owner
Evidence
Role review + resource class + policy decision log
Architecture concern
The sensitive-export attribute source must remain current.
Principal
Legacy Reporting Account
Resource
Generated Report Storage
Role
Historical local permission set
Attributes
None governed
Decision
Current design cannot be confidently explained as RBAC or ABAC.
Owner
Unknown
Evidence
Partial legacy logs + stale entitlement metadata
Architecture concern
Owner, purpose, permission scope, lifecycle, and modernization path are unresolved.
Principal
Migration Operator
Resource
Migration Console
Role
Migration Operator
Attributes
project=active + expiration=checkpoint
Decision
Role grants migration functions only while project lifecycle attributes remain valid.
Owner
Migration Project Owner
Evidence
Temporary role + project state + expiration + audit
Architecture concern
Role membership must be removed when the project checkpoint closes.
Fake Dashboard
Fictional RBAC, ABAC, hybrid, and legacy model summary
Access models reviewed
7
Workforce, privileged, partner, workload, sensitive reporting, legacy, and temporary access
Pure RBAC
1
Counselor access maps cleanly to a stable business role
Hybrid / ABAC
5
Context adds value for privilege, partner lifecycle, workload, sensitive data, and temporary access
Blocked legacy model
1
Legacy Reporting Account lacks an accountable modern access model
Fake SOC Alert
Source: Fictional Access Model Review • Time: 10:04
Role Explosion
Roles work best when they represent stable responsibilities. Trouble begins when every difference in environment, project, resource classification, time window, or partner state becomes a new role. That can produce dozens of nearly identical roles that are difficult to explain and review.
Counselor vs. Platform Administrator — clearly different responsibilities.
Reporting-Analyst-Prod-Export-ProjectA-UntilJune — too much changing context encoded in the role name.
environment=production or project=Migration-2026 when those values naturally change.
Reporting Analyst role + resource classification + approved export purpose.
Fake Log Panel
[08:06] ACM-01 counselor->portal model=RBAC role=COUNSELOR state=CONFIRMED [08:29] ACM-02 platform-engineer->management model=HYBRID privilege=JIT state=CONFIRMED [08:53] ACM-03 partner->integration model=HYBRID sponsor=CURRENT review_due=30d state=CONDITIONAL [09:17] ACM-04 staging-workload->staging-data model=ABAC env_match=TRUE state=CONFIRMED [09:41] ACM-05 analyst->sensitive-export model=HYBRID attr_source=CURRENT state=CONDITIONAL [10:04] ACM-06 legacy-reporting model=UNGOVERNED owner=UNKNOWN state=BLOCKED [10:31] ACM-07 migration-operator model=HYBRID expires=CHECKPOINT state=CONDITIONAL
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Access Model Anti-Patterns
Why it fails: Many unrelated permissions are bundled together because broad access is easier to administer.
Better approach: Design roles around specific responsibilities and resource groups.
Why it fails: Roles become personalized permission bundles and lose their value as reusable business abstractions.
Better approach: Use roles for common responsibilities and exceptions only when genuinely necessary.
Why it fails: Tiny role variants multiply until nobody understands which one should be used.
Better approach: Use attributes or contextual policy when differences are based on environment, project, resource class, or time.
Why it fails: Policy depends on metadata that nobody is accountable for keeping current.
Better approach: Assign an authoritative source and owner to security-relevant attributes.
Why it fails: Policy becomes so complex that reviewers cannot understand why access is allowed.
Better approach: Keep rules readable, documented, testable through safe review, and tied to clear decisions.
Why it fails: New roles are created for every short project, environment, or exception.
Better approach: Use a hybrid model when stable responsibility and temporary context need to be separated.
Why it fails: A strong role definition still produces excessive access when former members remain assigned.
Better approach: Review membership on role, team, project, and lifecycle changes.
Why it fails: A stale or missing attribute silently removes a protective condition.
Better approach: Use visible fallback behavior such as deny, limit, review, or Unknown.
Scenario Decision Lab
Platform engineers have a stable administrative responsibility, but production privilege should only become active during approved maintenance work.
Scenario Decision Lab
An analytics workload should reach staging resources when it runs in staging, but the same identity should never automatically receive production data access.
Safe Fictional Lab
Use fictional identities, roles, attributes, resources, owners, and policy outcomes only. Do not inspect or change access in a real identity platform.
Create at least twelve fictional access use cases.
Give every record a stable ACM ID.
Record principal and resource.
State business or technical purpose.
Identify whether the need is stable responsibility, changing context, or both.
Propose RBAC, ABAC, or Hybrid.
For RBAC, define role name and responsibility.
For ABAC, define only the minimum relevant subject/resource/context attributes.
For Hybrid, show which part belongs in the role and which part belongs in attributes.
Assign role owner or policy owner.
Assign resource owner.
Record lifecycle or review trigger.
Record decision evidence.
Classify status as Confirmed, Conditional, Unknown, Blocked, or Retired.
Include at least three pure RBAC examples.
Include at least three ABAC examples.
Include at least three hybrid examples.
Include at least one role-explosion problem and redesign it.
Include at least one stale-attribute problem with visible fallback behavior.
Include at least one unowned legacy entitlement and keep it Blocked.
Add change triggers for role, project, environment, resource class, owner, provider, and application changes.
Lab boundary
This is a fictional authorization-design exercise. Do not change live roles, group memberships, identity attributes, permissions, or access policies in any real system.
Analyze the Evidence
Advanced Challenge
A fictional organization has 86 access roles, many of which differ only by environment, project, quarter, or resource classification. Redesign the model conceptually so stable responsibilities remain roles while changing context moves into attributes where that improves clarity.
Identify duplicate role families
Separate stable responsibility from changing context
Consolidate near-duplicate roles
Define authoritative attribute sources
Assign attribute owners
Create environment attributes
Create project/lifecycle attributes
Create resource classification attributes
Keep privileged eligibility as a stable role
Use contextual activation for privilege
Preserve external sponsor conditions
Document hybrid precedence
Define stale-attribute fallback
Create role retirement criteria
Create membership review cadence
Create policy evidence requirements
The objective is not to minimize the number of roles at any cost. The objective is to make each role meaningful and move changing context into policy only when that improves precision and maintainability.
Defender Habits
Skill Check
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create the fifth artifact for your A13 Enterprise Identity and Zero-Trust Review: a fictional Access Model Comparison with at least twelve use cases. Include ACM ID, principal, resource, purpose, stable responsibility, changing context, proposed model, role definition where applicable, relevant attributes where applicable, policy/role owner, resource owner, lifecycle, evidence, status, concern, next action, and change trigger.
Confidence / Readiness Reflection
A13.6 moves into Privileged Access Management Concepts. Before continuing, make sure you can explain why privileged access often benefits from a hybrid model: a stable role or eligibility assignment combined with time-bounded, contextual activation.
I can explain RBAC in terms of roles and membership.
I can explain ABAC in terms of subject, resource, action, and context attributes.
I can identify role explosion.
I can identify attribute-source and attribute-quality risks.
I can explain when a hybrid model improves clarity and least privilege.
Portfolio Build Guide
Describe the real responsibility or context before choosing RBAC, ABAC, or Hybrid.
Do not just label a row RBAC or ABAC; explain what makes that model clearer or more maintainable.
Use stable responsibilities rather than encoding every project, quarter, environment, or exception into role names.
Name the authoritative source, owner, expected freshness, and fallback behavior for important attributes.
Role membership, projects, partners, resources, and workloads all need review or retirement triggers.
Role reviews, policy decisions, workload identity, owner confirmation, and authorization logs should support the design.
Do not force an ungoverned legacy entitlement into a clean model just to make the diagram look complete.
A13.6 will apply these access-model ideas to privileged and administrative identities.
Key Takeaways
Lesson Safety Boundary
Do not alter live roles, group membership, attributes, policies, privileged access, or permissions. Do not attempt access-control bypass or privilege escalation. All identities, roles, attributes, decisions, and logs in this lesson are fictional and defensive.
Lesson Complete
You now have an access-model framework for deciding when roles, attributes, or a hybrid approach best support least privilege, clarity, lifecycle, and reviewability. Next, A13.6 focuses on Privileged Access Management Concepts.