Authorization, Permissions and Entitlements

Why This Topic Matters
Authentication proves who a user or process is; authorization decides what that identity is allowed to do. Many of the most damaging real-world breaches are not failures of authentication but failures of authorization: a logged-in user accessing another customer's records by changing an ID in a URL, a service account with far more rights than it needs, or an API that trusts the client to tell it which role it holds. Broken Access Control sits at the very top of the OWASP Top 10 for good reason. For the CSSLP, authorization is part of Domain 1 (Secure Software Concepts) and underpins concepts you will see throughout the exam: least privilege, separation of duties, complete mediation, defense in depth, and secure design principles. Understanding how authorization, permissions and entitlements fit together is essential for both the exam and for building software that enforces the right boundaries.

Core Definitions
Authorization is the process of determining whether an authenticated subject (user, process, service) is permitted to perform a specific action on a specific object (resource). It always follows authentication and is enforced at the point of access.

Permissions are the specific rights granted to a subject on an object, such as read, write, execute, delete, create, or approve. Permissions are typically attached to objects (e.g., file ACLs, database table grants) or to roles.

Entitlements are the overall set of access rights and privileges a subject actually holds across systems, applications and resources. An entitlement is the result of all assignments: roles, group memberships, direct permissions and inherited rights. Entitlement management (reviews, certification, recertification) is about governing that total picture, ensuring users do not accumulate excessive access over time (privilege creep).

A useful way to remember the relationship: permissions are the granular rights, entitlements are what a subject has been granted in aggregate, and authorization is the run-time decision that checks entitlements against the requested action.

Supporting Concepts
Subject, object and action: every authorization decision involves a subject requesting an action on an object. Secure design requires that all three be explicitly identified and validated server-side.

Reference monitor and complete mediation: the reference monitor is the conceptual component that mediates every access attempt. It must be tamper-proof, always invoked (complete mediation) and small enough to be verified. Authorization checks must occur on every request, not just at login or on the first page.

Least privilege: subjects receive only the minimum permissions needed to do their job, for the minimum time required. This limits the blast radius of a compromised account or component.

Separation (segregation) of duties: critical tasks are split so that no single subject can complete a sensitive transaction alone (e.g., the person who creates a payment cannot also approve it). This is enforced through authorization rules that prevent conflicting entitlements.

Need to know: access to information is granted based on a demonstrated requirement, not just clearance level or convenience.

Fail secure (fail closed): if the authorization mechanism cannot make a decision, access should be denied by default.

Access Control Models You Must Know
Discretionary Access Control (DAC): the owner of a resource decides who gets access, typically via Access Control Lists (ACLs). Flexible but prone to inconsistency and over-sharing.

Mandatory Access Control (MAC): access is enforced by the system based on security labels (classifications and clearances). Users cannot override policy. Models such as Bell-LaPadula (confidentiality: no read up, no write down) and Biba (integrity: no read down, no write up) belong here.

Role-Based Access Control (RBAC): permissions are attached to roles, and users are assigned roles. Simplifies administration, supports least privilege and separation of duties, and is the most common model in enterprise applications. Watch for role explosion when too many fine-grained roles are created.

Attribute-Based Access Control (ABAC): decisions are made by evaluating attributes of the subject, object, action and environment (time, location, device risk) against policies. Highly flexible and context-aware; standards such as XACML describe a Policy Enforcement Point (PEP), Policy Decision Point (PDP), Policy Information Point (PIP) and Policy Administration Point (PAP).

Rule-Based Access Control: access determined by predefined rules, such as firewall rules or time-of-day restrictions. Often combined with other models.

Relationship-Based Access Control (ReBAC): access depends on the relationship between subject and object (e.g., owner, friend, manager of). Common in social and collaborative applications.

How Authorization Works in Software
1. The subject authenticates and receives a session or token (e.g., session ID, JWT, SAML assertion, OAuth access token).
2. The subject requests an action on a resource.
3. The Policy Enforcement Point intercepts the request and asks the Policy Decision Point whether the action is allowed, supplying subject identity, resource, action and context.
4. The PDP evaluates entitlements and policy (roles, attributes, ACLs) and returns permit or deny.
5. The PEP enforces the decision and the event is logged for audit.

Key design rules: perform checks server-side; never rely on hidden fields, client-side scripts or obfuscated URLs; check authorization on every object reference (prevent Insecure Direct Object References / IDOR); centralize authorization logic rather than scattering it across code; default to deny; separate authorization data from application data; and make decisions on trusted identity claims, not user-supplied parameters.

Federated and Token-Based Authorization
OAuth 2.0 is an authorization framework that lets a client obtain scoped access to resources on behalf of a resource owner. Scopes define the permissions a token carries. OAuth is not an authentication protocol; OpenID Connect adds the identity layer on top of it. SAML assertions can carry attributes used for authorization in federated enterprise scenarios. Common pitfalls include over-broad scopes, long-lived tokens, trusting unvalidated token claims, and confused-deputy problems where a privileged component acts on behalf of a less privileged caller without re-checking rights.

Entitlement Management and Governance
Entitlements must be provisioned, reviewed and revoked throughout the identity lifecycle (joiner, mover, leaver). Periodic access reviews and certification campaigns detect privilege creep and orphaned accounts. Just-in-time and privileged access management (PAM) reduce standing privilege. Logging and monitoring of authorization decisions support auditing, forensics and compliance (SOX, HIPAA, PCI DSS, GDPR). In the SDLC, authorization requirements should be captured as security requirements, expressed in use and misuse cases, verified in threat modeling (think Elevation of Privilege in STRIDE), and tested through role-based and negative test cases.

Common Authorization Weaknesses
Insecure Direct Object References; missing function-level access control (hidden admin URLs); horizontal privilege escalation (accessing peer data) and vertical privilege escalation (gaining admin rights); privilege creep; hard-coded roles; trusting client-side enforcement; inconsistent checks across API and UI; time-of-check to time-of-use (TOCTOU) race conditions; overly permissive defaults; and excessive OAuth scopes or wildcard cloud IAM policies.

Exam Tips: Answering Questions on Authorization, Permissions and Entitlements
1. Sequence matters. Identification comes first, then authentication, then authorization, then accountability (auditing). If a question asks what happens after a user is authenticated, the answer is authorization. If it asks how to prove identity, that is authentication, not authorization.

2. Match the vocabulary precisely. Permissions = granular rights on objects. Entitlements = the aggregate of what a subject holds. Authorization = the decision/process. Access control model = the framework (DAC, MAC, RBAC, ABAC). Read the question for which of these it actually asks.

3. Recognize the model by its clue words. Owner decides or ACL → DAC. Labels, classifications, clearances, military/government → MAC. Job function, roles, simplified administration → RBAC. Attributes, context, time, location, device, fine-grained dynamic policy, XACML → ABAC. Relationships between users and resources → ReBAC.

4. When in doubt, choose the most restrictive secure principle. The CSSLP favors least privilege, default deny, fail secure, complete mediation and server-side enforcement. An option that trusts the client, grants broad access for convenience, or checks only once at login is almost always wrong.

5. Separation of duties scenarios. If a question describes one person who can both initiate and approve, or a developer who can also deploy to production, the control being violated is separation of duties and the fix is splitting the entitlements across roles.

6. Privilege creep and reviews. Questions about employees who changed roles yet still hold old access point to entitlement review, recertification and lifecycle (mover) processes, not to stronger authentication.

7. OAuth vs OpenID Connect vs SAML. OAuth 2.0 is for delegated authorization (scopes); OpenID Connect is for authentication on top of OAuth; SAML carries assertions for federated SSO. If an option says OAuth authenticates the user, treat it with suspicion.

8. Spot the vulnerability type. Changing an ID in the URL to see another user's data → IDOR / broken object-level authorization. Regular user reaching an admin function → missing function-level access control / vertical escalation. A race between the check and the use → TOCTOU. Map the symptom to the name the exam expects.

9. Think reference monitor. The best answers describe authorization logic that is centralized, always invoked, tamper-resistant and verifiable. Decentralized, duplicated or client-side checks are red flags.

10. Prefer design-phase answers for design-phase questions. If the question is about where to address authorization in the SDLC, the correct response is usually in requirements and design (security requirements, threat modeling, misuse cases), not as a late testing or patching activity. For verification questions, look for role-based testing with both positive and negative test cases.

11. Eliminate distractors systematically. Cross out options that confuse authentication with authorization, that rely on obscurity, that grant permanent elevated rights, or that omit logging. Then choose the remaining option that best reflects least privilege and complete mediation.

Quick Review
Authorization decides what an authenticated subject may do. Permissions are the granular rights; entitlements are the full set of rights a subject holds and must be governed over time. Enforce every access server-side through a centralized reference monitor, default to deny, apply least privilege and separation of duties, pick the access control model that fits the context (DAC, MAC, RBAC, ABAC), use OAuth scopes carefully, and build authorization requirements into design and testing. On the exam, read for the exact term being asked, identify the model by its clue words, and favor the most restrictive, server-enforced, auditable option.