Authorization
The fictional decision that determines whether an already identified user or service may perform a specific action on a specific resource under current policy and context.
High School AdvancedModule A10Lesson A10.3Authorization and Access
A10.3 Authorization and Access Control Design
Learn how professional defenders decide which authenticated fictional users and services may perform which actions on which resources. Build least-privilege, deny-by-default access using roles, ownership, attributes, service identities, administrative separation, exceptions, recertification, monitoring, and explicit decision ownership—without privilege escalation, access-control bypass, unauthorized requests, enumeration, or testing against real accounts or objects.
Lesson Progress
Authorization and Access Control Design
High School Advanced • A10: Advanced Web Security Defense • Lesson 3 of 10
30% complete
Readiness Check
Before You Start
0/6 ready
Professional Hook
Knowing Who the User Is Does Not Answer What the User May Do
A fictional Support User signs in successfully and opens Case C-104, which belongs to the user's approved team. That may be an allowed action. The same user then attempts to open Case C-880, which belongs to another department. The identity has not changed, but the authorization decision should.
Professional access control therefore evaluates the complete subject-resource-action-context relationship. Role matters, but so do object ownership, sensitivity, current business purpose, administrative state, service identity, exceptions, and owner decisions.
Weak access thinking
“The user is authenticated and has the Support User role, so all support cases should be accessible.”
Defender access thinking
“Authentication gives identity context. Authorization still checks the exact resource, action, ownership, sensitivity, approved context, exception state, and policy.”
Learning Objectives
Five Objectives for A10.3
Objective 1
Distinguish authentication from authorization and explain why every protected fictional action still requires an independent access decision after identity has been established.
Objective 2
Design fictional least-privilege access using roles, attributes, resource ownership, service identity, administrative separation, deny-by-default thinking, and explicit business purpose.
Objective 3
Evaluate access-control decisions through subject, resource, action, context, ownership, sensitivity, business need, exception status, source health, monitoring, and owner approval.
Objective 4
Review fictional administrative and service-to-service permissions for excessive privilege, unclear ownership, stale access, conflicting duties, exception drift, and weak recertification without teaching bypass or escalation techniques.
Objective 5
Create a professional fictional Authorization and Access Control Review package containing an access matrix, policy questions, exception register, service-identity review, access-review workflow, monitoring plan, validation criteria, and public-safe summary.
Why It Matters
Access Control Turns Identity into Safe Business Capability
Authentication alone cannot protect sensitive case data, administrative settings, identity configuration, reporting exports, APIs, or recovery functions. A fictional system also needs to decide what each subject may do, to which exact resource, under which ownership and business conditions.
Strong access design prevents both accidental over-permission and long-term privilege drift while keeping legitimate work possible. It also makes owner approval, monitoring, exceptions, recertification, privacy, and governance easier to explain.
Advanced Vocabulary
Authorization and Access-Control Language
Subject
The fictional user, administrator, service identity, application component, or automated process requesting an action.
Resource
The fictional object or capability being protected, such as a case record, report, profile, administrative setting, API resource, or service function.
Action
The fictional operation being requested, such as view, create, update, approve, export, configure, or administer.
Least privilege
The principle that a fictional subject receives only the access needed for an approved business purpose and no unnecessary capability.
Deny by default
A fictional access-design approach in which a subject receives no protected capability unless an explicit approved rule allows it.
Role-based access concept
A fictional design that groups permissions around approved job or service responsibilities rather than assigning every permission individually.
Attribute-aware access concept
A fictional design that considers approved context such as department, case assignment, resource sensitivity, owner relationship, time-limited status, or service purpose in addition to role.
Object ownership
A fictional relationship showing which user, team, service, or business owner is responsible for or legitimately associated with a protected resource.
Service identity
A fictional non-human identity used by an application or service to perform approved system-to-system actions under explicit purpose and privilege.
Separation of duties
A fictional control that divides high-impact responsibilities so one subject does not unnecessarily create, approve, review, and conceal the same sensitive action.
Access exception
A fictional temporary or unusual permission granted for a documented business reason with owner approval, scope, duration, monitoring, and expiration.
Access review
A fictional process that compares current permissions with current role, ownership, business need, exceptions, and risk.
Recertification
A fictional owner-driven confirmation that existing access is still required, appropriate, and correctly scoped after time or organizational change.
Policy decision
The fictional result of applying approved access rules to subject, resource, action, and context.
Policy enforcement
The fictional application of the authorization decision at the relevant application or service boundary. A10 studies this conceptually rather than through bypass testing.
Core Framework
Twelve Authorization and Access-Control Principles
1
Authenticate first, authorize every protected action
Knowing who the fictional subject is does not answer whether that subject may view, modify, approve, export, configure, or administer the requested resource.
Defender question
What exact resource and action is being requested after identity is known?
2
Default to no protected access
A fictional subject should receive capability because an approved rule grants it, not because no one remembered to deny it.
Defender question
Which explicit business rule grants this fictional action?
3
Use least privilege
Permissions should match current responsibility, current ownership, and current business purpose instead of broad future convenience.
Defender question
What is the minimum fictional capability needed to complete the approved task?
4
Protect object ownership
Two users may have the same broad role but still need different access to specific fictional cases, reports, or records.
Defender question
Does this subject have the required relationship to this exact resource?
5
Separate administration
Higher-impact configuration, user management, access changes, and security settings should not inherit ordinary user assumptions.
Defender question
Which fictional actions belong only in an approved privileged role or session?
6
Govern service identities
Application-to-application access needs purpose, owner, resource scope, lifecycle, monitoring, and review just like human access.
Defender question
Why does this fictional service identity need this exact action on this exact resource?
7
Use context carefully
Approved context can refine access, but context should not become a vague reason to grant broad permission.
Defender question
Which contextual attribute is necessary, reliable, current, and owned?
8
Time-bound exceptions
Emergency, temporary, project, and support access should expire unless explicitly reviewed and renewed.
Defender question
When does this fictional exception end, who owns it, and what evidence justifies renewal?
9
Review stale access
Role changes, project endings, ownership changes, supplier changes, and service redesign can make old access inappropriate.
Defender question
What changed since the permission was first approved?
10
Monitor decisions, not private behavior
Useful fictional access monitoring focuses on approvals, denials, privilege changes, administrative actions, exception use, service-identity behavior, and source health.
Defender question
Which access event answers a defender or governance question without collecting unnecessary personal information?
11
Keep decisions explainable
Owners should be able to explain why a fictional subject was allowed or denied without relying on hidden assumptions.
Defender question
Can the access decision be traced to role, ownership, context, policy, and owner approval?
12
Treat Unknown as a valid review result
If ownership, resource classification, service purpose, or policy is incomplete, the strongest outcome may be to hold access until the design is clarified.
Defender question
Which missing fictional fact prevents a defensible allow decision?
Professional Workflow
The Ten-Step Authorization Decision Workflow
1. Identify the subject
Determine whether the fictional requester is a standard user, manager, administrator, service identity, support function, or another approved subject class.
Output
Subject class and owner.
2. Identify the resource
Define the exact fictional case, report, profile, setting, API resource, administrative function, or data class being protected.
Output
Resource identity, classification, and owner.
3. Identify the action
State the requested fictional operation precisely: view, create, update, approve, export, configure, assign, administer, or another bounded action.
Output
Action and business purpose.
4. Check authentication state
Confirm that the subject has the appropriate fictional identity/session context for the action without assuming authentication alone grants access.
Output
Bounded identity assurance context.
5. Check role and ownership
Compare the subject role, service purpose, team assignment, object ownership, and current responsibility to the requested resource.
Output
Role/ownership relationship.
6. Check context and sensitivity
Review fictional resource sensitivity, privilege level, administrative status, recovery state, business workflow, and approved time-limited context.
Output
Context and sensitivity decision inputs.
7. Apply deny-by-default policy
Allow only when the fictional policy explicitly supports the subject-resource-action-context combination.
Output
Allow, deny, restrict, or hold-for-review decision.
8. Record and monitor important decisions
Capture fictional access approvals, denials, administrative changes, privilege updates, service-identity actions, exception use, and owner review according to privacy limits.
Output
Audit and monitoring record.
9. Review exceptions and stale access
Compare temporary access, emergency access, supplier access, transferred staff, inactive projects, and changed service responsibilities against current need.
Output
Exception and recertification actions.
10. Validate and improve
Use safe fictional evidence, owner review, expected decisions, monitoring, and change records to confirm the design without bypass testing.
Output
Authorization review package and improvement plan.
Fake Dashboard
Fictional Northbridge Access Governance Dashboard
A10.3 — authorization design review
Subject classes
8
Users, managers, analysts, admins, service identity, recovery, and governance roles
Review cases
8
Allow, deny, temporary allow, stale-access removal, and redesign decisions
Decision model
Subject → Resource → Action → Context
Role alone is not enough for protected access
Default posture
Deny
Protected capability requires an explicit approved rule
Role Design
Eight Fictional Subject Classes
Support User
Create and manage fictional support cases assigned to the user or approved team workflow.
Typical allowed purpose
Create case, view assigned case, update approved fields, add case notes within policy.
Not automatically allowed
Administrative configuration, unrelated case access, role changes, system-wide export, access-policy changes.
Review focus
Assignment, case ownership, department context, session state, and resource sensitivity.
Support Manager
Coordinate fictional team workload and review cases within the manager's approved scope.
Typical allowed purpose
View team cases, approve selected workflow actions, reassign within approved team boundaries.
Not automatically allowed
Global administration, identity-policy changes, unrelated department data, unrestricted export.
Review focus
Team ownership, approval responsibility, case sensitivity, separation of duties.
Reporting Analyst
Produce fictional approved reports using minimized data required for business analysis.
Typical allowed purpose
Access approved reporting views and aggregated data products.
Not automatically allowed
Modify support cases, manage users, change application configuration, access unnecessary personal fields.
Review focus
Reporting purpose, data minimization, aggregation level, export need, retention.
Application Administrator
Perform fictional application configuration and support administration.
Typical allowed purpose
Approved administrative settings and operational support actions.
Not automatically allowed
Automatic access to all case content, identity administration, data-owner decisions, unrestricted reporting.
Review focus
Separate privileged session, least privilege, approval, monitoring, change record, rollback.
Identity Administrator
Manage fictional identity-specific settings and approved account administration.
Typical allowed purpose
Approved identity-management actions.
Not automatically allowed
Application data ownership, support-case content, business-report approval, supplier administration.
Review focus
Identity-specific need, sensitive action verification, monitoring, separation of duties.
Service Identity P
Allow fictional Application Service B to call API Service P for approved case functions.
Typical allowed purpose
Only the bounded API resources and actions required by the application purpose.
Not automatically allowed
Administrative APIs, unrelated data collections, identity-policy changes, human user interfaces.
Review focus
Service owner, caller purpose, resource scope, environment, lifecycle, monitoring, recertification.
Recovery Operator
Support fictional staged recovery and service validation.
Typical allowed purpose
Only approved recovery functions and validation-related service access.
Not automatically allowed
Permanent production administration, ordinary case handling, identity policy changes.
Review focus
Recovery event, time-bound approval, monitoring, dependencies, automatic expiration.
Governance Reviewer
Review fictional policy, privacy, exception, and access-review evidence.
Typical allowed purpose
Read approved governance records and minimized evidence needed for review.
Not automatically allowed
Modify operational data, approve own access, perform application administration.
Review focus
Need-to-know, independence, privacy, retention, separation of duties.
Fake SOC Alert
Fictional Access-Control Design Warning
Source: A10.3 authorization review board • Time: Northbridge access review 13:15
A proposed Application Administrator role would receive unrestricted read access to all support-case content because administrators may need to troubleshoot the service, even though no business requirement for case-content access is documented.
Defensive recommendation: Separate application administration from business-data ownership. Define the exact troubleshooting information administrators need, minimize case-content exposure, require explicit authorization for any sensitive data access, monitor privileged actions, and document owner-approved exceptions when unusual access is truly necessary.
Decision Dimensions
Eight Inputs to a Defensible Authorization Decision
Subject
Who or what is making the fictional request?
Strong evidence
Current role or service identity, approved owner, valid session context.
Weak assumption
The subject is internal, senior, or familiar, so broad access is acceptable.
Resource
What exact fictional object or capability is being protected?
Strong evidence
Resource identifier, data classification, owner, business workflow.
Weak assumption
Everything inside the same application can use one access rule.
Action
What exact operation is requested?
Strong evidence
Bounded view, update, approve, export, configure, or administrative action.
Weak assumption
If a user can view something, they should probably be able to change it.
Ownership
What approved relationship connects the subject to this resource?
Strong evidence
Case assignment, team ownership, business responsibility, service contract.
Weak assumption
Same role means access to every object's data.
Context
Which current fictional conditions matter?
Strong evidence
Sensitive-action state, administrative session, approved project, recovery event, time-bound exception.
Weak assumption
Context should always increase access.
Sensitivity
How important or private is the resource/action?
Strong evidence
Data classification, administrative impact, business criticality, privacy requirement.
Weak assumption
All fields and actions deserve the same access rule.
Exception
Is the access outside normal policy?
Strong evidence
Documented reason, owner, scope, start/end, monitoring, approval, expiration.
Weak assumption
Temporary access can remain until someone remembers to remove it.
Decision owner
Who is accountable for the allow, deny, or exception rule?
Strong evidence
Named application, data, identity, service, governance, or business owner.
Weak assumption
The system can decide everything without owner responsibility.
Fake Log Panel
Fictional Authorization Decision Log
training-log-viewer.log
13:00 | SUBJECT | U-17 | role=SupportUser | session=Standard 13:01 | RESOURCE | C-104 | owner=TeamBlue | sensitivity=Standard 13:01 | DECISION | subject=U-17 | action=view | result=Allow | reason=team-owned-case 13:03 | RESOURCE | C-880 | owner=TeamGold | sensitivity=Standard 13:03 | DECISION | subject=U-17 | action=view | result=Deny | reason=no-approved-ownership 13:07 | ADMIN | A-02 | request=all-case-content | result=Hold | business_need=undocumented 13:10 | SERVICE | P | action=case-status-read | purpose=approved | result=Allow 13:12 | EXCEPTION | R-7 | recovery-access=true | expiry=end-of-recovery-event 13:15 | REVIEW | role=AppAdmin | broad-data-access=true | approval=hold
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Analyze the Cross-Team Case Request
U-17 is successfully authenticated.
U-17 has the Support User role.
Case C-880 belongs to Team Gold.
U-17 has no assignment, approved cross-team purpose, or exception for C-880.
What is the strongest interpretation of AC-02?
Access Decision Cases
Eight Fictional Authorization Decisions
AC-01Allow
A Support User needs to view a fictional case assigned to that user's team.
Subject
Support User U-17
Resource
Case C-104
Action
View
Context
Team assignment verified; standard authenticated session; case sensitivity Standard.
Reason
Role, team ownership, action, and resource context align with normal policy.
Monitoring
Routine access event according to approved privacy-aware audit policy.
AC-02Deny
The same Support User attempts to open a fictional case owned by another department.
Subject
Support User U-17
Resource
Case C-880
Action
View
Context
No assignment, no approved cross-department purpose, no exception.
Reason
Authentication does not replace object/team ownership requirements.
Monitoring
Denied access may be recorded for defender trend questions without assuming malicious intent.
AC-03Allow
A Support Manager needs to approve a team workflow change.
Subject
Manager M-04
Resource
Team Workflow W-3
Action
Approve
Context
Manager owns the team workflow and has approved responsibility.
Reason
Role plus ownership supports the specific approval action.
Monitoring
Approval action recorded with owner and change context.
AC-04Deny / redesign support process
An Application Administrator wants to read all fictional case content while troubleshooting configuration.
Subject
App Admin A-02
Resource
All case content
Action
Read
Context
Admin role exists, but no case-content business purpose is documented.
Reason
Administrative role does not automatically justify unrestricted business-data access.
Monitoring
Record the denied broad request and define a minimized troubleshooting path.
AC-05Allow
Reporting Analyst R-02 needs an approved aggregate service report.
Subject
Reporting Analyst R-02
Resource
Aggregated Support Metrics
Action
View / Export approved report
Context
Reporting purpose approved; minimized data view; no unnecessary case text.
Reason
Reporting need, minimized resource, and approved role align.
Monitoring
Report generation and export according to approved audit/retention policy.
AC-06Allow
Service Identity P needs to call a fictional case-status API.
Subject
Service Identity P
Resource
Case Status API
Action
Read bounded case status
Context
Application purpose documented; owner approved; environment current.
Reason
Service purpose and resource/action scope are explicit and least-privileged.
Monitoring
Service call category, policy decision, error state, source health, and owner review.
AC-07Allow temporarily
Recovery Operator R-7 requests temporary access to recovery validation functions.
Subject
Recovery Operator R-7
Resource
Recovery Validation Functions
Action
Validate staged recovery
Context
Active recovery event; owner approval; time-bound exception; monitoring Healthy.
Reason
Purpose, time bound, owner approval, least privilege, and automatic expiration are documented.
Monitoring
Start/end, approved actions, exception expiration, and post-event review.
AC-08Remove / recertify
A temporary project role ended last week, but its fictional access remains assigned.
Subject
Project User P-19
Resource
Project Reporting View
Action
Current access remains active
Context
Project assignment ended; no renewal approval exists.
Reason
Access no longer has documented current business need.
Monitoring
Recertification action and stale-access finding recorded.
Scenario Decision Lab
Scenario Decision Lab 1: The Helpful Administrator
A fictional Application Administrator says unrestricted read access to every support case would make troubleshooting faster. The current architecture separates application configuration from business-data ownership, and most troubleshooting can be performed with service-health and configuration evidence.
Service Identities
Ten Questions for Non-Human Access
Service Identity Question 1
What fictional application or service owns this service identity?
Service Identity Question 2
Which exact resource and action does the service identity need?
Service Identity Question 3
Which environment or business workflow is the permission for?
Service Identity Question 4
Could the service function with narrower data, fewer actions, or fewer resources?
Service Identity Question 5
Who approves changes to the service identity's access?
Service Identity Question 6
How is access reviewed when the application architecture changes?
Service Identity Question 7
Which fictional events show normal versus unexpected service-identity use?
Service Identity Question 8
What happens if the service identity is no longer needed?
Service Identity Question 9
How do recovery and continuity affect the service identity's permissions?
Service Identity Question 10
Which access decisions should be visible without exposing secrets or private content?
Exception Governance
Eight Requirements for Temporary or Exceptional Access
Business reason
Requirement
State why normal fictional policy is insufficient for the specific task.
Failure pattern
Convenience, seniority, or vague urgency without a bounded purpose.
Scope
Requirement
Limit the fictional exception to exact subject, resource, action, environment, and workflow.
Failure pattern
Broad 'temporary admin' access with unrelated capability.
Owner
Requirement
Name the fictional business/security owner authorized to approve the exception.
Failure pattern
Self-approved access or unclear ownership.
Duration
Requirement
Define start, end, or event-based expiration.
Failure pattern
No expiration because the request is described as temporary.
Monitoring
Requirement
Define which fictional approval, access, change, or termination events need visibility.
Failure pattern
Exception use cannot be distinguished from ordinary activity.
Review
Requirement
Define validation, post-use review, and whether renewal requires fresh justification.
Failure pattern
Exception automatically renews without current need.
Privacy
Requirement
Keep monitoring and evidence limited to what the access-governance purpose needs.
Failure pattern
Collect unrelated personal content because the subject has exceptional access.
Closure
Requirement
Confirm the fictional permission ended and dependent systems reflect the change.
Failure pattern
Exception expires on paper but access remains active elsewhere.
Analyze the Evidence
Analyze the Service Identity
Service Identity P has a documented application purpose.
Its API resource/action scope is documented.
The next recertification owner is missing.
No supplied evidence shows unauthorized service access.
What is the strongest response to AUTHZ-04?
Access Review
Eight Triggers for Rechecking Existing Permission
Role change
Review question
Does the fictional user still need the same permissions after moving to a new responsibility?
Review action
Recalculate role, resource ownership, administrative privilege, and exceptions.
Team or case ownership change
Review question
Should existing object-level access move, remain, or end?
Review action
Update assignment-based access and verify stale permissions are removed.
Project completion
Review question
Which project-specific access no longer has business purpose?
Review action
Expire or recertify temporary roles and exceptions.
Application redesign
Review question
Did trust boundaries, APIs, roles, resources, or service identities change?
Review action
Re-run access design and service-identity review.
Supplier change
Review question
Does the fictional external dependency still need the same data or capability?
Review action
Review purpose limitation, ownership, data scope, and access expiration.
Recovery event
Review question
Which temporary recovery permissions must expire after staged restoration?
Review action
Remove time-bound access and validate normal policy state.
Governance review
Review question
Are privileged, sensitive, and exceptional permissions still current and explainable?
Review action
Recertify, remove, narrow, or document accepted risk.
Monitoring anomaly or policy drift
Review question
Does observed fictional access behavior reveal stale policy, bad ownership, or incorrect role design?
Review action
Review the policy and context without assuming malicious intent.
Scenario Decision Lab
Scenario Decision Lab 2: The Temporary Permission That Never Ended
A fictional project role ended last week, but Project User P-19 still has access to the Project Reporting View. No current project assignment or renewal approval exists.
Fictional Evidence
Northbridge Authorization Evidence Set
AUTHZ-01Current
Fictional role matrix
Observation
Support Users, Managers, Reporting Analysts, Application Administrators, Identity Administrators, Recovery Operators, Governance Reviewers, and Service Identity P have distinct purposes.
Supports
Role separation and least-privilege review.
Limits
Role names alone do not prove individual resource/action decisions are correct.
Review use
Map roles to resources, actions, ownership, and exceptions.
AUTHZ-02Healthy
Fictional case-ownership record
Observation
Case C-104 belongs to Team Blue while Case C-880 belongs to Team Gold.
Supports
Object/team ownership can refine access beyond broad role.
Limits
Ownership alone does not authorize every action on the case.
Review use
Evaluate AC-01 and AC-02.
AUTHZ-03Current
Fictional admin policy
Observation
Application Administrators manage settings but do not automatically own case content.
Supports
Administrative capability is separated from business-data ownership.
Limits
Does not prove all admin permissions are least-privileged.
Review use
Evaluate administrative access and separation of duties.
AUTHZ-04Conditional
Fictional service-identity register
Observation
Service Identity P has a documented API purpose, but the next recertification owner is not recorded.
Supports
Purpose and resource scope are documented.
Limits
Lifecycle governance is incomplete.
Review use
Record an ownership/recertification Unknown rather than a bypass finding.
AUTHZ-05Current
Fictional exception register
Observation
Recovery Operator R-7 has time-bound access that expires at the end of the staged recovery event.
Supports
A governed exception with purpose, duration, owner, and monitoring.
Limits
Does not prove all dependent systems will terminate access correctly.
Review use
Validate exception closure and cross-service consistency.
AUTHZ-06Healthy
Fictional recertification report
Observation
Project User P-19 still has a project permission after the project ended.
Supports
A stale-access finding.
Limits
Does not prove misuse occurred.
Review use
Remove or reapprove access based on current need.
AUTHZ-07Healthy
Fictional monitoring summary
Observation
Important allow/deny decisions, privileged changes, exception use, service-identity actions, and role changes are monitored.
Supports
High-level authorization observability.
Limits
Does not prove every policy decision is correct or every log is independent.
Review use
Monitoring design, source-health review, and recertification support.
AUTHZ-08Current
Fictional architecture change
Observation
A new reporting feature introduces a browser-facing workflow that requests aggregate metrics from API P.
Supports
A new subject-resource-action path exists.
Limits
Does not prove the new feature is over-permissioned.
Review use
Re-run role, service identity, data minimization, API authorization, and monitoring review.
Common Mistakes
Eight Authorization Mistakes to Avoid
Authenticated means authorized
Why it fails
Identity establishes who the fictional subject is, not which exact resource/action is allowed.
Professional correction
Evaluate authorization independently for each protected resource and action.
Role alone decides everything
Why it fails
A broad role may not capture resource ownership, sensitivity, administrative state, exception status, or service purpose.
Professional correction
Combine role with object ownership and relevant approved context.
Administrators get all data
Why it fails
Application administration and business-data ownership are different responsibilities.
Professional correction
Grant only the administrative data/capability required for the approved task.
Temporary access never expires
Why it fails
Project, emergency, support, and recovery permissions can become stale.
Professional correction
Use time bounds, owners, monitoring, automatic expiration, and post-use review.
Service identities are invisible
Why it fails
Non-human access can accumulate privilege and survive architecture changes.
Professional correction
Give service identities purpose, owner, resource/action scope, lifecycle, monitoring, and recertification.
Denied access proves malicious intent
Why it fails
A denial may result from mistake, stale links, workflow confusion, or changing ownership.
Professional correction
Treat the denial as an access event and use context before interpreting intent.
Access review is annual paperwork only
Why it fails
Role, project, resource, supplier, architecture, and recovery changes can make permissions stale much sooner.
Professional correction
Use event-driven review triggers in addition to periodic recertification.
Validate by bypass testing
Why it fails
A10 teaches defensive access design and review without unauthorized testing.
Professional correction
Use fictional expected-decision cases, owner evidence, policy tables, monitoring, and safe validation records.
Safe Fictional Lab
Build the Northbridge Authorization and Access Control Review
Use only the invented roles, resources, actions, access cases, service identities, exception records, and evidence on this page. The goal is defensive policy design, governance, ownership, recertification, privacy, and monitoring—not bypass testing.
Phase 1 — Define subjects and resources
- • Create fictional subject classes for ordinary users, managers, analysts, administrators, service identities, recovery roles, and governance reviewers.
- • Create resource classes for cases, reports, profiles, configuration, identity settings, APIs, recovery functions, and governance records.
- • Assign owners and data/security sensitivity.
Phase 2 — Define actions
- • List bounded fictional actions such as view, create, update, approve, assign, export, configure, administer, or validate.
- • Separate view permission from change permission.
- • Separate ordinary actions from privileged administrative actions.
Phase 3 — Build the access matrix
- • Map subject + resource + action combinations.
- • Add ownership, context, sensitivity, exception status, and decision owner.
- • Start from deny by default and add only explicit approved allows.
Phase 4 — Review object ownership
- • Use fictional Team Blue and Team Gold case ownership examples.
- • Show why the same Support User role can allow one case and deny another.
- • Create at least four ownership-sensitive policy examples.
Phase 5 — Review admin and service identities
- • Separate Application Admin, Identity Admin, Recovery Operator, and Service Identity P.
- • Define exact purpose, resources, actions, session/exception requirements, owners, monitoring, and recertification.
- • Identify where separation of duties matters.
Phase 6 — Build the exception register
- • Create fictional temporary, recovery, emergency, project, and supplier exceptions.
- • For each include business reason, scope, owner, duration, monitoring, privacy, review, and closure.
- • Reject any exception that has no expiration or owner.
Phase 7 — Build the access-review workflow
- • Use role change, project completion, ownership change, architecture change, supplier change, recovery, governance, and monitoring triggers.
- • Create decisions to keep, narrow, remove, or reapprove access.
- • Record Unknowns instead of inventing policy rules.
Phase 8 — Produce the review package
- • Create the final fictional access matrix, service-identity register, exception register, recertification plan, monitoring questions, findings, decision owners, validation cases, leadership summary, and public-safe portfolio summary.
- • Use invented identifiers only.
- • Do not test real accounts, objects, APIs, roles, or access-control boundaries.
Lab boundary
Do not test real authorization boundaries, accounts, roles, objects, URLs, APIs, identifiers, administrative functions, or service identities. Do not enumerate resources, change identifiers, send unauthorized requests, test object-level access, attempt privilege escalation, or bypass access controls. Use only the fictional policy evidence and expected decisions supplied here.
Advanced Challenge
Redesign an Over-Permissive Support Portal
A fictional Northbridge redesign gives every employee one broad “Staff” role. That role can view all support cases, export reports, change application settings, and call internal APIs because the product team wants simple access management. Redesign the model without offensive testing.
Split the broad Staff role into at least six purpose-based subject classes.
Define resource classes and protected actions separately.
Create deny-by-default rules and add only explicit approved allows.
Use case/team ownership to refine ordinary support access.
Separate application administration from business-data ownership.
Create a least-privileged service identity for API calls.
Design temporary recovery and emergency exceptions with automatic expiration.
Create separation-of-duties rules for sensitive approval and administrative actions.
Build event-driven recertification triggers for role, project, supplier, architecture, and recovery changes.
Write a leadership summary explaining how the redesign reduces privilege while preserving legitimate work.
Defender Habits
A10.3 Authorization and Access Control Checklist
Check Your Understanding
A10.3 Mini Quiz: Authorization and Access Control Design
Choose your answers first. Explanations appear only after submission.
1. What does fictional authentication establish?
2. Which access model best demonstrates deny by default?
3. Why can two Support Users with the same role receive different case-access decisions?
4. What is strongest for a temporary fictional recovery permission?
5. Why should service identities receive access review?
6. A user receives a denied access decision. What is the strongest interpretation?
7. What is the strongest response to an incomplete fictional authorization rule?
Portfolio Prompt
Portfolio Prompt: Authorization and Access Control Review
Create a fully fictional A10.3 Authorization and Access Control Review for Northbridge. Include subject classes; roles; service identities; resource classes; actions; object ownership; data sensitivity; business purpose; deny-by-default rules; least-privilege decisions; attribute-aware context; administrative separation; separation of duties; service-to-service access; access matrix; expected allow/deny cases; exception register; project/recovery/emergency access; owner approvals; expiration; access-review triggers; recertification; stale-access findings; monitoring questions; source-health expectations; privacy/minimization; denied-access interpretation; decision owners; validation criteria; residual risk; technical summary; leadership summary; governance summary; and a public-safe access-control diagram. Every user, account, role, resource, case, service identity, policy, exception, event, and decision must be invented.
Model access as subject + resource + action + context.
Use deny by default and least privilege.
Keep role and object ownership as separate decision inputs.
Separate administrative capability from business-data ownership.
Give service identities owners, purpose, lifecycle, and recertification.
Validate with fictional expected decisions rather than bypass testing.
Confidence / Readiness Reflection
Are You Ready for A10.4 Input Handling and Output Safety?
Rate your readiness from 1 to 5 for separating authentication and authorization, applying least privilege and deny by default, modeling object ownership, governing service identities and exceptions, reviewing stale access, and explaining access decisions.
I can explain why successful sign-in does not grant every protected action.
I can model subject, resource, action, ownership, and context.
I can apply deny by default and least privilege.
I can use object ownership to refine a broad role.
I can separate administrative access from ordinary business-data access.
I can govern service identities and temporary exceptions.
I can use access-review triggers and recertification.
I can treat a denied request as a policy event rather than automatic proof of malicious intent.
I can record Unknowns and validate design without bypass testing.
I am ready to focus on safe input contracts, validation, normalization, output handling, errors, logging, and privacy in A10.4.
Portfolio Build Guide
What a Strong A10.3 Artifact Should Show
Portfolio element 1
Clear subject classes and business purposes
Portfolio element 2
Explicit resource classes and protected actions
Portfolio element 3
Deny-by-default policy structure
Portfolio element 4
Least-privilege role design
Portfolio element 5
Object/team ownership rules
Portfolio element 6
Administrative separation
Portfolio element 7
Separation-of-duties decisions
Portfolio element 8
Service-identity purpose, owner, scope, lifecycle, and recertification
Portfolio element 9
Temporary and emergency exception governance
Portfolio element 10
Expected allow/deny decision cases
Portfolio element 11
Event-driven access-review triggers
Portfolio element 12
Stale-access findings and remediation
Portfolio element 13
Privacy-aware authorization monitoring
Portfolio element 14
Decision owners and validation criteria
Portfolio element 15
Technical, leadership, and governance summaries
Portfolio element 16
A public-safe diagram using invented labels only
Key Takeaways
What You Should Remember
1.Authentication establishes identity context; authorization independently decides each protected action.
2.Strong access control evaluates subject, resource, action, ownership, context, sensitivity, and policy.
3.Deny by default and least privilege reduce unnecessary capability and make access easier to explain.
4.Broad role membership does not automatically replace object ownership or business-purpose checks.
5.Administrative capability should be separated from ordinary business-data ownership.
6.Service identities need purpose, resource scope, owners, monitoring, lifecycle, and recertification.
7.Temporary and emergency permissions should be time-bound, monitored, reviewable, and designed to expire.
8.Denied access is a policy result and does not automatically establish malicious intent.
9.Access review should respond to role, project, ownership, supplier, architecture, recovery, and governance changes.
10.A10.3 prepares you for A10.4, where authorization-protected web functions must safely handle incoming data, output, errors, logs, and privacy-sensitive information.
Safety Boundary
Defensive Access Design — No Authorization Bypass Testing
Nothing in A10.3 authorizes testing real accounts, roles, resources, object identifiers, endpoints, APIs, administrative functions, or service identities. Do not enumerate objects, modify identifiers, send unauthorized requests, attempt object-level access, escalate privileges, bypass access checks, or test real authorization weaknesses. Use only fictional policy tables, expected decisions, owner evidence, monitoring records, and safe design review.
Lesson Complete
Continue to Input Handling and Output Safety
A10.3 established subject-resource-action decisions, least privilege, deny by default, object ownership, administrative separation, service identities, exceptions, access review, recertification, monitoring, and owner accountability. A10.4 will focus on how authorized web functions safely accept, validate, normalize, store, display, log, and return fictional data without using attack payloads or exploitation strings.