I6.4 Access Control Models and Permissions
Learn how defenders evaluate fictional roles, rules, attributes, relationships, ownership, permissions, inheritance, conflicts, and enforcement to calculate effective access.
Lesson Progress
Access Control Models and Permissions
High School Intermediate • I6: Identity and Access Management • Lesson 4 of 8
Readiness Check
Before You Start
0/5 ready
Professional Hook
A Role Name Does Not Reveal the Final Effective Access
A fictional reviewer role may allow viewing, while a direct grant allows export, a resource deny protects one folder, an attribute policy requires a managed device, and an older session still holds earlier claims. Defenders calculate the final decision from every access path and policy condition.
Weak response
“The account has the reviewer role, so we already know all of its permissions.”
Strong response
“Trace roles, groups, direct grants, inheritance, resource rules, attributes, sessions, precedence, and enforcement.”
Objective 1
Explain discretionary, mandatory, role-based, rule-based, attribute-based, relationship-based, and resource-level access-control concepts.
Objective 2
Distinguish identities, subjects, objects, permissions, actions, policies, attributes, conditions, decisions, and enforcement points.
Objective 3
Trace fictional access from direct permissions, groups, roles, resource ownership, policy rules, and inherited permissions.
Objective 4
Identify conflicting policies, broad permissions, unsafe inheritance, stale attributes, missing ownership, and incorrect enforcement.
Objective 5
Create a professional fictional Access-Control Policy Review with evidence, findings, owners, validation, and residual risk.
Why This Matters
Access Decisions Depend on Models, Data Quality, and Enforcement
RBAC, ABAC, DAC, MAC, relationship-based controls, rules, and resource permissions solve different problems. Their strength depends on accurate owners, attributes, mappings, policy versions, inheritance boundaries, session state, and consistent enforcement.
Access-Control Models
Eight Models and Their Defensive Tradeoffs
Discretionary Access Control
A fictional resource owner or authorized user decides who may access a resource.
Fictional example
A teacher shares one fictional lesson-planning document with two reviewers.
Strength
Supports flexible, resource-specific collaboration.
Risk
Owner-managed sharing can become inconsistent, broad, stale, or difficult to recertify.
Review
Confirm owner authority, exact subject, action, resource, duration, inheritance, and removal.
Mandatory Access Control
A fictional system applies centrally controlled labels and rules that ordinary users cannot override.
Fictional example
A training archive allows access only when the subject and resource labels satisfy the configured classification rule.
Strength
Provides consistent centralized control for highly structured information environments.
Risk
Incorrect labels or rigid rules can block required work or expose data if classification is wrong.
Review
Validate label ownership, assignment process, policy version, exceptions, and enforcement behavior.
Role-Based Access Control
Fictional permissions are assigned to roles, and identities receive access through role membership.
Fictional example
The report-reviewer role grants view and comment permissions to approved fictional reviewers.
Strength
Aligns access with defined job or service functions and simplifies consistent assignment.
Risk
Roles can become too broad, overlap, remain after job changes, or hide direct and local exceptions.
Review
Confirm role purpose, owner, permissions, conflicting roles, intended users, duration, and recertification.
Rule-Based Access Control
Fictional access follows centrally defined rules such as network zone, time, application, or action conditions.
Fictional example
A training application allows report viewing only during approved support hours from the managed-school network.
Strength
Applies consistent organization-wide conditions.
Risk
Rules can conflict, become outdated, or deny valid workflows when context changes.
Review
Check rule order, scope, exceptions, version, owner, test cases, and default behavior.
Attribute-Based Access Control
Fictional access is evaluated using subject, resource, action, and environmental attributes.
Fictional example
A managed teacher device may view its assigned class report during the school term when the account department and resource owner match.
Strength
Supports detailed context-aware decisions without creating a separate role for every combination.
Risk
Stale or incorrect attributes can produce inappropriate allows or denials.
Review
Validate attribute source, freshness, owner, meaning, policy logic, missing-value behavior, and enforcement.
Relationship-Based Access Control
Fictional access depends on relationships between subjects, resources, organizations, groups, owners, or projects.
Fictional example
A teacher may view only reports for classes they currently teach.
Strength
Represents ownership, membership, assignment, and collaboration relationships directly.
Risk
Incorrect or stale relationship data can extend access beyond the current responsibility.
Review
Confirm relationship source, lifecycle, owner, direction, resource scope, and removal.
Resource-Level Access Control
A fictional resource stores an access list describing which identities or groups may perform specific actions.
Fictional example
A project folder grants view to project-reviewers and edit to project-leads.
Strength
Provides precise object-level access.
Risk
Large numbers of local access lists can become inconsistent and invisible to central review.
Review
Inspect direct entries, inherited entries, owner, exceptions, shares, expiration, and effective access.
Policy-Based Access Control
Fictional access is governed through reusable policies combining roles, attributes, rules, relationships, and resource conditions.
Fictional example
A reporting policy requires the reviewer role, a managed device, an active project relationship, and fresh MFA before export.
Strength
Combines several control approaches into one governed decision process.
Risk
Complex policies can be difficult to understand, test, troubleshoot, and explain.
Review
Preserve policy versions, identify every input, test expected and denied cases, and document decision reasoning.
Permission Types
Review the Exact Action, Not Just the Role Name
View or read
The fictional subject can display or retrieve the protected resource.
Risk
Viewing can still expose sensitive information or enable copying through screenshots, exports, or connected applications.
Validation
Confirm the exact resource, field, record, class, report, or folder that is visible.
Create
The fictional subject can add a new object, record, request, user-created item, or configuration entry.
Risk
Creation may trigger workflows, consume resources, or establish new sharing and ownership relationships.
Validation
Confirm where new objects appear, who owns them, and which approvals or restrictions apply.
Edit or update
The fictional subject can change existing content or settings.
Risk
Editing may alter records, permissions, calculations, labels, ownership, or operational behavior.
Validation
Verify which fields and objects may change and whether sensitive settings remain protected.
Delete
The fictional subject can remove a protected object or record.
Risk
Deletion can affect availability, evidence, recovery, and business continuity.
Validation
Confirm retention, recovery, approval, audit logging, and whether deletion is soft, reversible, or permanent.
Approve
The fictional subject can authorize a request, workflow step, publication, payment, access grant, or change.
Risk
Approval combined with creation or implementation may weaken separation of duties.
Validation
Confirm approver authority, request ownership, independent review, and evidence preservation.
Export
The fictional subject can move data out of the normal application view into a file, report, or connected destination.
Risk
Export may increase data exposure and reduce downstream control visibility.
Validation
Confirm resource sensitivity, destination, purpose, logging, owner approval, and retention.
Configure
The fictional subject can change application, system, policy, integration, or resource settings.
Risk
Configuration access can affect many users and resources even without full administration.
Validation
Identify exact settings, change approval, rollback, testing, and monitoring.
Administer
The fictional subject can manage users, roles, permissions, settings, integrations, or protected system functions.
Risk
Administrative access can create, change, or remove other identities and controls.
Validation
Require privileged-access controls, temporary elevation, approval, fresh authentication, logging, and post-action review.
Policy Inputs
Eight Inputs That Can Change the Same Access Request
Subject attributes
Fictional department, role, job function, project, account type, owner, employment state, or assurance level.
Risk
Stale or inaccurate subject data can grant access after responsibilities change.
Resource attributes
Fictional owner, sensitivity, class, project, environment, retention state, location, or data category.
Risk
Incorrect resource classification can weaken or overrestrict access.
Action attributes
View, comment, edit, approve, export, configure, administer, or delete.
Risk
Policies that treat all actions equally may overgrant sensitive capabilities.
Device attributes
Managed state, compliance, platform, device owner, certificate, browser, or endpoint health.
Risk
Device attributes can be stale, missing, shared, or misattributed.
Session attributes
Authentication time, MFA method, session age, risk state, step-up result, or revocation status.
Risk
An older session can outlive role, device, account, or policy changes.
Environmental attributes
Fictional time, network zone, source region, application, connection type, emergency state, or maintenance window.
Risk
Context can change quickly and may be approximate or interpreted incorrectly.
Relationship attributes
Owner, manager, assigned teacher, project member, resource reviewer, support team, or sponsoring organization.
Risk
Relationship data can remain after transfers, project completion, or ownership changes.
Policy state
Policy version, rule order, exception, default behavior, approval, effective date, expiration, or emergency override.
Risk
Uncontrolled policy changes or conflicting versions can create inconsistent decisions.
Core Concept
Calculate Effective Access in Five Questions
Subject
Who or what requests access, and which account, role, group, device, and session represent it?
Object
Which exact fictional resource and sensitivity boundary are involved?
Action
Is the request to view, edit, approve, export, configure, delete, or administer?
Policy
Which direct, inherited, role, rule, attribute, relationship, and resource conditions apply?
Enforcement
Which application or service makes and applies the final decision, and which version is active?
Permission Inheritance
Six Inheritance Paths That Affect Effective Access
Folder inheritance
Access path
A fictional parent folder grants project-reviewers view access, and child folders inherit the permission.
Benefit
Consistent access across related resources.
Risk
A sensitive child folder may unintentionally inherit access that is too broad.
Review
Identify parent source, inherited entries, child exceptions, owner, and negative test.
Nested group inheritance
Access path
learning-support is inside application-operators, which receives configuration permission.
Benefit
Structured group reuse can simplify assignment.
Risk
A visible support group may silently inherit operational access.
Review
Trace every group level and calculate effective permissions.
Role hierarchy
Access path
A fictional senior-reviewer role inherits all permissions from reviewer plus export.
Benefit
Related roles can share a controlled permission foundation.
Risk
Inherited permissions can grow as lower roles change.
Review
Review both the child role and every inherited parent permission.
Resource ownership
Access path
A fictional project owner can share project resources with additional reviewers.
Benefit
Supports controlled collaboration.
Risk
Owner-created shares may remain after the project ends.
Review
Confirm owner authority, shared identities, duration, and lifecycle.
Application mapping
Access path
The identity-platform reviewer role maps to editor inside one fictional application.
Benefit
Central roles can drive application access.
Risk
Incorrect mapping can make a narrow central role broader in the application.
Review
Compare central claims, mapping rules, and actual application permissions.
Exception inheritance
Access path
A fictional network exception applies to a group containing multiple service identities.
Benefit
A single approved exception can support a defined integration set.
Risk
New group members may inherit access without separate review.
Review
Check exception scope, group lifecycle, owner, expiration, and new-member behavior.
Policy Conflicts
Six Conflicts That Require Evidence and Testing
Explicit allow and explicit deny
Fictional example
A fictional user receives report-view through a role but a resource-level deny blocks the same report.
Concern
The final outcome depends on policy precedence and enforcement behavior.
Response
Preserve all rules, determine precedence, test the exact subject-resource-action combination, and document the intended result.
Role permission and attribute policy disagree
Fictional example
A fictional reviewer role allows export, but an attribute policy denies export from unmanaged devices.
Concern
A role alone does not reveal the final effective access.
Response
Evaluate the complete context and confirm the enforcement point applies the attribute policy.
Central removal and local permission remain
Fictional example
A fictional user loses the central editor role but remains an editor inside the application.
Concern
Governance records show removal while effective access remains.
Response
Remove the local grant, refresh sessions, validate denial, and add local access to future reviews.
Temporary role expires but session claims remain
Fictional example
A fictional temporary export role ends, but an older application session continues to allow export.
Concern
Current authorization and session state are misaligned.
Response
Revoke or refresh the session and validate the new decision.
Nested group creates duty conflict
Fictional example
A fictional requester group is nested inside an approver group.
Concern
One account can create and approve the same sensitive request.
Response
Separate the memberships, test both workflows, and monitor for recurrence.
Missing attribute uses unsafe default
Fictional example
A fictional resource has no sensitivity label, and the policy treats missing values as low sensitivity.
Concern
Incomplete data produces a permissive decision.
Response
Use a safe missing-value behavior, correct the attribute source, and test unlabeled resources.
Evidence Matrix
What Access-Control Evidence Can and Cannot Prove
Evidence source
Identity and directory record
Can support
The fictional subject, account type, owner, role, group, status, department, project, and lifecycle attributes.
Limitation
Directory data may be stale or may not include application-local access and resource-level sharing.
Evidence source
Role and permission catalog
Can support
The intended fictional role purpose, actions, resources, owner, conflicting roles, duration, and review schedule.
Limitation
The deployed role can differ from documentation, and direct exceptions may exist.
Evidence source
Policy definition
Can support
The fictional rule logic, inputs, conditions, precedence, default behavior, version, owner, and effective date.
Limitation
A documented policy does not prove every enforcement point is using the same version.
Evidence source
Resource access list
Can support
Direct and inherited fictional permissions attached to a file, folder, report, application object, or service.
Limitation
The list may not show external policy conditions, active sessions, or nested-group expansion.
Evidence source
Application decision log
Can support
The fictional subject, resource, action, session, policy result, enforcement point, decision reason, and time.
Limitation
The event may show the final decision without fully explaining every underlying access path.
Evidence source
Attribute source
Can support
The fictional department, project, device, sensitivity, owner, relationship, environment, or risk value used by a policy.
Limitation
Attributes can be delayed, incorrect, missing, ambiguous, or owned by another system.
Evidence source
Access request and approval
Can support
The fictional requester, purpose, resource, action, duration, conditions, approver, and expected outcome.
Limitation
The implemented permission can differ from the approved request.
Evidence source
Validation and owner confirmation
Can support
Whether required fictional actions work, unrelated actions remain denied, and the business owner accepts the result.
Limitation
A single successful test may not cover inheritance, edge cases, session state, or future policy changes.
Effective Access
Calculate the Final Decision from Every Access Path
Direct access
None
Inherited access
attendance-viewers role allows view
Policy condition
Managed device and active teacher relationship
Result: Allow
The role, device, relationship, and resource conditions all match the approved request.
Direct access
None
Inherited access
attendance-viewers does not include administration
Policy condition
No privileged role or approval
Result: Deny
Successful authentication and view permission do not authorize user administration.
Direct access
report-export directly assigned
Inherited access
report-viewers allows view only
Policy condition
Export requires owner approval and managed device
Result: Review
The direct export grant conflicts with the narrower role and lacks matching approval evidence.
Direct access
Service role grants read
Inherited access
None
Policy condition
Approved workload source and production environment required
Result: Allow
The service identity, source workload, environment, owner, and read scope match the policy.
Direct access
None
Inherited access
Service role grants read only
Policy condition
No approved write workflow
Result: Deny
The service requires read access only, and no evidence supports write authorization.
Direct access
Resource-level deny
Inherited access
Parent folder grants view
Policy condition
Child resource sensitivity is restricted
Result: Deny
The child resource requires narrower handling, and the explicit restriction prevents broad inheritance.
Defensive Workflow
Review an Access-Control Decision in Six Steps
Define the request
Identify the fictional subject, object, action, application, environment, time, owner, and business purpose.
Identify the control model
Determine whether the decision uses ownership, labels, roles, rules, attributes, relationships, resource lists, or combined policies.
Trace every permission path
Map direct, inherited, group, role, resource, local, temporary, exception, and session-based access.
Calculate effective access
Evaluate policy precedence, conditions, missing values, conflicts, default behavior, and enforcement.
Correct narrowly
Use owner-approved changes, preserve prior state, prepare rollback, refresh sessions, and communicate impact.
Validate and monitor
Test required actions, denied actions, inherited resources, edge cases, policy logs, owner acceptance, and residual risk.
Key Vocabulary
Access-Control and Permission Terms
Subject
The fictional user, service, application, device, or session requesting access.
Object
The fictional file, folder, report, database, application, system, setting, or other protected resource.
Action
The exact fictional operation requested, such as view, edit, create, delete, approve, export, configure, or administer.
Permission
An allowed or denied fictional action associated with a subject, role, group, policy, or resource.
Access-control policy
A fictional rule or collection of rules that determines whether a requested action should be allowed, denied, challenged, or restricted.
Policy decision point
The fictional component that evaluates subject, object, action, attributes, rules, and context to produce an access decision.
Policy enforcement point
The fictional application, gateway, operating system, service, or resource that applies the access decision.
Inheritance
The process through which fictional permissions flow from a parent resource, group, role, folder, or policy to another object or identity.
Explicit permission
A fictional allow or deny directly assigned to a subject, group, role, or resource.
Effective access
The final fictional access available after direct, inherited, role-based, group-based, resource-level, and policy conditions are evaluated.
Conflict
A condition in which fictional rules, permissions, roles, or inherited settings produce competing or unclear access outcomes.
Default deny
A design principle in which fictional access is denied unless an approved rule explicitly allows the required action.
Fake Dashboard
Fake Access-Control Policy Dashboard
Training dashboard for the fictional Northstar Learning Services environment.
Policies reviewed
18
Role, attribute, relationship, resource, rule, and combined policy decisions.
Access conflicts
7
Two inheritance gaps, two stale attributes, one local permission, one session mismatch, and one rule conflict.
Validated changes
6
Each includes owner approval, rollback, session refresh, allow tests, deny tests, and monitoring.
Fake SOC Alert
Restricted Child Folder Inherits Broad Parent Access
Source: Fake Access-Control Review Console • Time: 11:15 AM
Fake Log Panel
Fake Permission-Inheritance Timeline
11:00:00 REQUEST subject='project-reviewers' resource='project-workspace' action='view' 11:04:00 APPROVAL main_workspace='allow' restricted_folder='exclude' 11:10:00 PARENT_PERMISSION group='project-reviewers' action='view' inheritance='enabled' 11:12:00 CHILD_FOLDER restriction='missing' inherited_view='true' 11:15:00 AUTHZ resource='restricted-investigation' result='allow' 11:20:00 REVIEW finding='scope_mismatch' 11:25:00 OWNER_DECISION child_folder='explicit_restriction' 11:30:00 CHANGE restricted_inheritance='stopped' deny='applied' 11:31:00 SESSION action='refresh' 11:35:00 TEST resource='main-workspace' result='allow' 11:36:00 TEST resource='restricted-investigation' result='deny' DAY7 REVIEW business_workflow='confirmed' closure='approved'
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Which Access-Control Conclusion Is Best Supported?
Which conclusion is strongest?
Common Mistakes
Mistakes That Weaken Access-Control Analysis
Safe Practice Lab
Review a Fictional Access-Control Policy Packet
Fictional Environment
Meadowbrook Effective-Access Review
Review thirty supplied fictional records covering roles, groups, attributes, relationships, resources, direct grants, inheritance, local permissions, policy versions, decisions, sessions, owners, approvals, and validation results.
Required Analysis
- Identify each fictional subject, object, action, owner, policy, and enforcement point.
- Classify DAC, MAC, RBAC, rule, attribute, relationship, resource, and combined controls.
- Trace direct, inherited, role, group, local, temporary, exception, and session access.
- Calculate effective access and identify conflicts, missing attributes, and unsafe defaults.
- Propose narrow owner-approved corrections with preserved versions and rollback.
- Test expected allows, expected denials, boundaries, lifecycle, sessions, and enforcement consistency.
- Document monitoring, evidence gaps, residual risk, and closure criteria.
Scenario Decision Lab
A Sensitive Child Folder Inherits Parent Access
A fictional project group needs the main workspace but must not view one restricted child folder. The child inherits the parent view permission.
Scenario Decision Lab
A Missing Sensitivity Attribute Produces an Allow
A fictional export policy denies sensitive-report exports from unmanaged devices, but one unlabeled report is treated as low sensitivity and allowed.
Defender Habits
Access-Control Models and Permissions Checklist
Check Your Understanding
I6.4 Mini Quiz: Access Control Models and Permissions
Choose your answers first. Explanations appear only after submission.
1. What is role-based access control?
2. What is attribute-based access control?
3. What is effective access?
4. Why is permission inheritance risky?
5. What should happen when a required policy attribute is missing?
6. Why should an access-control change include a session refresh test?
7. Which validation plan is strongest?
Portfolio Prompt
Portfolio Prompt
Create a fictional Access-Control Policy Review containing at least thirty subject, resource, action, role, group, attribute, relationship, direct-permission, inherited-permission, local-access, policy, session, decision, owner, approval, and validation records. Include model classification, effective-access calculations, conflicts, unsafe inheritance, stale or missing attributes, enforcement gaps, narrow recommendations, rollback, allow tests, deny tests, boundary tests, session refresh, monitoring, residual risk, and closure criteria.
Key Takeaways
What You Should Remember
Navigation