Authorization Models and Policy Design

Introduction

Authentication answers the question “Who are you?” Authorization answers a different question: “What may you do, to which resource, under which conditions?” A system can authenticate a user correctly and still authorize an unsafe operation. For example, a legitimate employee may attempt to read another department’s payroll data, or a compromised service account may attempt to delete production records.

Authorization is therefore a central security design activity. It translates organizational rules, legal obligations, and operational needs into enforceable decisions. In a full-stack application, authorization may be implemented in user interfaces, application services, APIs, databases, message brokers, operating systems, and cloud platforms. The user interface can hide an unauthorized button, but the server must enforce the decision because clients are untrusted.

This chapter examines major authorization models and the principles used to design reliable policies. It also considers policy conflicts, delegation, auditability, privacy, and the practical selection of an access-control approach.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish authentication, authorization, and accounting;
• explain discretionary, mandatory, role-based, attribute-based, relationship-based, rule-based, and policy-based access control;
• select an appropriate model for a given application;
• apply least privilege, separation of duties, default denial, and delegation;
• design policy conditions and resolve conflicts safely;
• evaluate authorization implementations for security, maintainability, and usability;
• analyze an authorization problem through a realistic application case.

Authorization as a Security Decision

An authorization decision evaluates a request. A useful abstraction is:

The subject is the actor, such as a user, service, or device. The action is an operation such as read, update, approve, or delete. The resource is the protected object. Environment describes contextual information, including time, network location, device trust, or risk level. Policy contains the rules governing access. The result is commonly permit or deny, although systems may also return obligations such as “permit and record an audit event.”

A typical request path includes a policy enforcement point (PEP), which intercepts a request; a policy decision point (PDP), which evaluates policy; policy information points (PIPs), which provide attributes; and a policy administration point (PAP), where policies are created and maintained. These terms are associated with the XACML policy architecture, but the concepts apply more broadly.

Authorization must be enforced at a trusted boundary. A browser-controlled role value, hidden form field, or client-side route guard is not sufficient. The server should derive identity and authorization context from trusted credentials and authoritative data.

Fundamental Design Principles

Least Privilege

Least privilege grants only the permissions required for an authorized task, for only as long as they are required. A reporting service should normally receive read access to reporting tables rather than unrestricted database administrator privileges. Least privilege reduces the damage caused by mistakes, compromised accounts, and malicious insiders.

Least privilege has both breadth and duration dimensions. Breadth concerns the number and sensitivity of resources; duration concerns how long access remains active. Just-in-time elevation and short-lived credentials address the duration dimension.

Default Denial and Fail-Safe Behavior

A secure authorization system denies access when no rule matches, when identity is absent, when a policy dependency is unavailable, or when policy evaluation produces an error—unless a carefully justified availability requirement dictates otherwise. Explicit exceptions should be documented and monitored. “Permit by absence of a deny rule” is usually unsafe because newly introduced resources may unintentionally become accessible.

Separation of Duties

Separation of duties prevents one person or process from completing a sensitive workflow alone. For example, the employee who creates a supplier should not be able to approve the supplier’s payment. Separation may be static, such as prohibiting a user from holding two conflicting roles, or dynamic, such as requiring two distinct approvers for a particular transaction.

Complete Mediation

Every access to a protected resource should be checked. Authorization only at login, only in a front-end route, or only when a record is first opened allows later requests to bypass protection. APIs, background jobs, exports, administrative tools, and direct object references all require mediation.

Fail Securely and Make Decisions Explicit

Policy code should make permit and deny behavior visible. Ambiguous fall-through logic, duplicated checks, and implicit framework defaults create authorization gaps. Decisions should include a reason or policy identifier in audit logs, without exposing sensitive policy details to attackers.

Major Authorization Models

Discretionary Access Control

In discretionary access control (DAC), the owner of a resource may decide who can access it. Traditional file permissions and access-control lists are common examples. A document owner might grant another user read or edit permission.

DAC is flexible and easy to understand. It works well for personal files, collaborative content, and systems in which resource owners are trusted to share information. Its weakness is uncontrolled propagation: an owner may grant access too broadly, and users may copy information into resources with weaker protection. DAC also provides limited resistance to malicious insiders.

Mandatory Access Control

Mandatory access control (MAC) uses centrally managed security labels and clearance rules. Users do not freely change the security classification of resources. A simplified model may label subjects and objects as Unclassified, Confidential, Secret, or Top Secret. Access depends on formally defined relationships between those labels.

MAC is appropriate when information classification and containment are more important than user convenience, such as defense or highly regulated environments. It offers strong central control but requires accurate classification, administration, and exception handling. A user’s organizational role alone does not determine access; clearance and resource labels are also relevant.

Role-Based Access Control

Role-based access control (RBAC) assigns permissions to roles and roles to users. A permission is generally an operation on a resource type, such as “approve invoice.” A user receives that permission by possessing an appropriate role.

RBAC separates job responsibilities from individual identities and is often effective for enterprise applications. Common concepts include:

• Role hierarchy: a senior role inherits permissions from a junior role;
• Static constraints: a user cannot be assigned conflicting roles;
• Dynamic constraints: conflicting roles cannot be activated in the same session;
• Permission assignment: roles receive permissions, while users receive roles.

RBAC can become difficult to maintain when organizations create many exceptional roles. This is known as role explosion. Roles also express organizational responsibility poorly when access depends on resource ownership, location, transaction amount, or current risk.

Attribute-Based Access Control

Attribute-based access control (ABAC) evaluates attributes of the subject, resource, action, and environment. A policy might state: “A clinician may read a patient record when the clinician is assigned to the patient, the purpose is treatment, and the request occurs through an approved system.”

ABAC is expressive and supports fine-grained, context-sensitive decisions. Subject attributes may include department or clearance; resource attributes may include owner, classification, or region; environmental attributes may include time, device posture, or network location. Its cost is complexity. Attributes must be authoritative, current, consistently named, and available at decision time. Poor attribute governance can produce policies that appear precise but depend on unreliable data.

Relationship-Based Access Control

Relationship-based access control, often called ReBAC, decides access from relationships in a resource graph. A user may edit a document because the user is its owner, belongs to its workspace, or is a member of a project that contains it.

ReBAC is particularly suitable for collaboration platforms, social systems, repositories, and multi-tenant applications. It naturally represents nested ownership and sharing relationships. Its challenges include graph traversal cost, relationship consistency, and the need to prevent unintended access through indirect relationships.

Rule-Based Access Control

Rule-based access control evaluates explicit conditions, often independent of organizational roles. Examples include “deny all access outside approved hours,” “allow only requests from the corporate network,” or “require step-up authentication for payments above a threshold.” Rules may be implemented in gateways, firewalls, application services, or policy engines.

Rules are useful for global constraints and environmental conditions. However, a large collection of disconnected rules can become difficult to reason about. Rule ordering, exceptions, and interactions must be documented and tested.

Policy-Based Access Control

Policy-based access control is a broad approach in which decisions are governed by declarative, centrally managed policies. It may combine RBAC, ABAC, ReBAC, and rule-based conditions. The term emphasizes policy separation from application code and centralized decision logic rather than a single attribute or relationship mechanism.

A policy-based architecture can improve consistency across APIs and services. It also introduces operational requirements: policy versioning, deployment controls, testing, availability, caching, and governance. Centralization is not automatically safer; a flawed central policy can affect many systems at once.

Comparing the Models

These models are not mutually exclusive. A medical application might use RBAC for job function, ABAC for purpose and location, and ReBAC for treatment-team membership. Good design chooses the simplest combination that accurately represents business requirements.

Policy Structure and Evaluation

A practical policy should specify at least the subject, action, resource, conditions, effect, and obligations. For example:

Permit a project member to read a project document when the member belongs to the document’s project, the document is not restricted, and the request is made through an authenticated service. Record the decision.

Policies should use stable identifiers rather than trusting user-supplied labels. A request for /accounts/42 must be checked against the authenticated subject’s relationship to account 42; merely knowing the identifier must not grant access.

Conflict Resolution

Policies may conflict. One policy may permit access to project members while another denies access to confidential documents. A conflict-resolution strategy must be defined before implementation. Common strategies include:

• Deny-overrides: any applicable deny defeats a permit;
• Permit-overrides: any applicable permit defeats a deny;
• First applicable: the first matching policy determines the result;
• Priority-based: policies have explicit precedence;
• Consensus or quorum: multiple authorities must agree.

For security-sensitive systems, deny-overrides is usually safer, especially for emergency, legal, or classification restrictions. However, it can prevent legitimate business exceptions. Priority-based decisions can support exceptions but require strict governance and testing. “First applicable” is easy to implement but fragile when policy ordering changes.

A policy system should distinguish not applicable, indeterminate, permit, and deny. Treating an indeterminate result—such as an unavailable identity attribute—as permit can create a serious vulnerability. A common secure default maps indeterminate to denial while generating an operational alert.

Delegation and Temporary Authority

Delegation allows one subject to exercise authority on behalf of another. A manager may delegate approval authority during leave, or a service may act for a user through an access token. Delegation should be explicit and bounded by:

• delegator and delegate identities;
• permitted actions and resources;
• start and expiry times;
• purpose or transaction scope;
• whether further delegation is allowed;
• audit requirements.

Delegation must not silently grant more authority than the delegator possesses. A useful principle is authority attenuation: delegated authority should be equal to or narrower than the source authority. Temporary delegation should use short-lived credentials or server-side grants and should be revocable.

Impersonation and delegation are different. In impersonation, the system may represent the delegate as the original user, which can reduce accountability. In delegation, the system records both the acting subject and the authority source. The latter is generally preferable for auditability.

Designing Authorization in a Full-Stack Application

Authorization design begins with a resource inventory. Identify business objects, operations, data sensitivity, ownership relationships, and administrative actions. Next, identify subjects: human users, services, scheduled jobs, and external partners. Then specify legitimate workflows and negative cases.

A robust implementation commonly follows these practices:

1. Enforce authorization on the server and at every relevant service boundary.
2. Centralize policy decisions where consistency is important, while keeping policy evaluation available if a policy service is temporarily unavailable.
3. Use object-level checks, not only endpoint-level checks.
4. Separate read, create, update, delete, approve, export, and administrative permissions.
5. Prevent users from changing their own role or tenant identifier through mass assignment.
6. Treat imported data and client-provided attributes as untrusted until validated.
7. Log subject, action, resource, decision, policy version, timestamp, and correlation identifier.
8. Test both allowed and denied paths, including alternate HTTP methods and direct API calls.
9. Review permissions periodically and remove stale accounts, roles, and grants.
10. Protect policy administration itself with strong authentication and separation of duties.

Authorization should be designed alongside the data model. Tenant identifiers, ownership fields, project membership, and classification labels need integrity constraints. A policy cannot compensate for a database that allows a record to be assigned to the wrong tenant.

Worked Example: A Document Collaboration Service

Consider a service with users, workspaces, documents, and memberships. Requirements are:

• workspace members may read ordinary documents;
• editors may update documents;
• owners may delete documents;
• restricted documents require an additional clearance attribute;
• no user may approve their own publication;
• suspended accounts must be denied;
• all decisions must be auditable.

A suitable design combines ReBAC, RBAC, ABAC, and separation of duties. Workspace membership and document ownership are relationships. Editor and publisher are roles. Restriction status and clearance are attributes. The self-approval prohibition is a separation-of-duties constraint.

For an update request, the service obtains the authenticated user, document, workspace membership, role, account status, and document classification. It then evaluates a policy resembling:

Deny if the account is suspended. Deny if the document is restricted and clearance is insufficient. Permit update if the user is an editor in the document’s workspace. Otherwise deny.

For publication approval:

Permit only if the user has publisher authority, is not the document creator, the document has passed required review, and the account is active.

A user interface may hide the approval button for the creator, but the server must enforce the rule because a client can be modified. Tests should include a non-member requesting a document, an editor updating a restricted document, a publisher approving their own document, an expired delegation, and an unavailable clearance service.

Illustrative Case Study: University Research Portal

Background

A fictional university research portal stores grant proposals, participant information, financial records, and published datasets. Researchers collaborate across departments, while ethics officers and finance administrators have specialized responsibilities.

Problem

The initial system used broad roles: Researcher, Administrator, and Manager. Researchers could view records from projects in which they were not involved, and finance staff could both create and approve payments. A role-only design could not express project membership, data classification, or conflict-of-interest restrictions.

Analysis

The portal contains several access dimensions. Project membership is a relationship. Job responsibility is role-based. Participant data requires attributes such as consent status and data classification. Payment approval requires separation of duties. Emergency access may need controlled delegation.

Approach and Solution

The university adopted a hybrid policy design. ReBAC determined whether a researcher belonged to a project. RBAC assigned capabilities such as data steward, finance preparer, and finance approver. ABAC evaluated classification, ethics approval, purpose of use, and device status. A deny-overrides strategy applied to restrictions such as withdrawn consent or suspended accounts.

Payment creation and approval were assigned to mutually exclusive roles, and the system rejected approval when the creator and approver were the same person. Emergency access was time-limited, required a stated purpose, generated an alert, and was reviewed afterward. Policy decisions were logged with policy versions so that investigators could reconstruct historical decisions.

Outcome

The hybrid model reduced unnecessary access and represented project collaboration more accurately than the original role-only design. It also increased administrative work: attributes required ownership, policy changes required testing, and legitimate exceptions needed a formal process.

Learning Points

The case demonstrates that no single model represents every business requirement well. Relationships express collaboration, roles express responsibility, attributes express context, and constraints express risk controls. Combining models is effective only when policy ownership, data quality, testing, and monitoring are also addressed.

Challenges, Ethics, and Governance

Authorization decisions can encode institutional unfairness. A policy that restricts access by location may disadvantage remote workers or users with disabilities. Excessive monitoring may create privacy risks even when audit logs improve security. Data minimization requires collecting only attributes necessary for a decision and retaining logs only as long as justified.

Regulated environments may require demonstrable access control, review of privileged access, records of processing, and incident investigation. Policies should be explainable to administrators and, where appropriate, to affected users. A denial message should avoid revealing sensitive information—for example, it may say “access denied” rather than confirming that a confidential record exists.

Artificial intelligence may assist with anomaly detection or policy analysis, but it should not silently replace accountable authorization governance for high-impact decisions. Machine-learning predictions can be biased, unstable, or difficult to explain. Human review, explicit policies, and audit trails remain important.

Contemporary systems increasingly use zero-trust principles: every request is evaluated according to identity, device, resource, and context rather than trusted network location. Fine-grained authorization services, relationship tuple stores, policy-as-code, and continuous access evaluation support this direction. They also make policy versioning, availability, latency, and change management more important.

Best Practices for Evaluation

An authorization design can be evaluated by asking:

• Can every permission be traced to a business requirement?
• Is the default result denial?
• Are sensitive operations protected by object-level and workflow-level checks?
• Are conflicting roles and self-approval prevented?
• Are resource ownership and tenant boundaries enforced using trusted data?
• Can administrators understand why a decision was made?
• Are policies tested with both positive and negative cases?
• Are stale permissions and delegations removed automatically?
• Does failure of a dependency produce a safe result and an operational alert?
• Can the organization demonstrate who accessed what, when, and under which policy version?

The best model is not necessarily the most expressive one. A simple, well-governed RBAC design may be safer than an elaborate ABAC system with unreliable attributes. Conversely, a highly collaborative application may require relationships that roles cannot represent. Model selection should follow the structure of the authorization problem.

Chapter Summary

Authorization determines whether an authenticated subject may perform an action on a resource under specified conditions. DAC emphasizes resource-owner discretion; MAC uses centrally controlled labels; RBAC uses organizational roles; ABAC uses subject, resource, action, and environmental attributes; ReBAC uses relationships; rule-based control uses explicit conditions; and policy-based control combines these mechanisms through declarative governance.

Secure policy design applies least privilege, default denial, complete mediation, separation of duties, and bounded delegation. Policy conflicts require an explicit algorithm, with deny-overrides often appropriate for security restrictions. Full-stack systems must enforce authorization on trusted server-side boundaries, protect object-level operations, maintain reliable attributes and relationships, and produce useful audit records. Hybrid models are often necessary, but their complexity demands testing, ownership, versioning, and review.

Key Terms

Authentication: Establishing or verifying an identity.

Authorization: Determining whether an identity may perform an action.

Access-control list: A list of subjects and permissions associated with a resource.

DAC: Access control in which resource owners can grant permissions.

MAC: Access control based on centrally managed labels and clearances.

RBAC: Access control based on roles and role permissions.

ABAC: Access control based on subject, resource, action, and environmental attributes.

ReBAC: Access control based on relationships between subjects and resources.

Policy-based access control: Declarative authorization using centrally governed policies.

Least privilege: Granting only the minimum necessary authority.

Separation of duties: Dividing sensitive responsibilities among distinct subjects.

Complete mediation: Checking authorization for every protected access.

Delegation: Allowing one subject to exercise bounded authority for another.

Policy enforcement point: Component that intercepts and enforces a decision.

Policy decision point: Component that evaluates policy and returns a decision.

Deny-overrides: Conflict strategy in which an applicable denial defeats permission.

Role explosion: Excessive growth in roles caused by many exceptional combinations.

Indeterminate decision: An authorization result that cannot be reliably determined.

Policy version: Identifiable revision of a policy used for governance and audit.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization.
2. What is the principle of least privilege?
3. Identify one strength and one limitation of RBAC.
4. What types of information does ABAC evaluate?
5. Why should authorization be enforced on the server?

Long Answer Questions

1. Compare DAC, MAC, RBAC, ABAC, and ReBAC, including a suitable use case for each.
2. Explain how separation of duties can be implemented in a payment workflow.
3. Discuss the benefits and risks of centralizing authorization through a policy decision point.
4. Explain deny-overrides, permit-overrides, first-applicable, and priority-based conflict resolution.
5. Describe how delegation should be bounded and audited.

Analytical / Application Questions

1. Design a hybrid authorization model for a multi-tenant learning platform containing instructors, students, graders, and private submissions. Justify each model used.
2. An employee can read a project document but cannot export it, while a manager can export documents only from the manager’s department. Specify the relevant roles, attributes, relationships, and conflict rules.
3. Analyze an authorization system that permits access when no deny rule matches. Identify the risks and redesign the decision process using default denial and safe handling of indeterminate results.

Multiple Choice Questions with Answers

Question 1

Which statement best describes authorization?

A. Verifying that a password matches an account

B. Determining whether an authenticated subject may perform an action

C. Encrypting data before storage

D. Recording system performance metrics

Correct Answer: B. Determining whether an authenticated subject may perform an action

Question 2

Which model is primarily based on centrally managed labels and security clearances?

A. Discretionary access control

B. Role-based access control

C. Mandatory access control

D. Relationship-based access control

Correct Answer: C. Mandatory access control

Question 3

A user may edit a document because the user belongs to the document’s workspace. Which model most directly represents this decision?

A. Relationship-based access control

B. Mandatory access control

C. Discretionary access control

D. Time-based rule control

Correct Answer: A. Relationship-based access control

Question 4

Which principle requires that access be denied when no applicable permission is found?

A. Default denial

B. Role inheritance

C. Delegation

D. Data replication

Correct Answer: A. Default denial

Question 5

Which control prevents the person who creates a payment from approving the same payment?

A. Complete mediation

B. Separation of duties

C. Role hierarchy

D. Resource labeling

Correct Answer: B. Separation of duties

Question 6

Which is an example of an environmental attribute in ABAC?

A. User department

B. Document owner

C. Current network location

D. Document identifier

Correct Answer: C. Current network location

Question 7

Under a deny-overrides strategy, what happens when one applicable policy permits access and another denies it?

A. Access is permitted because permits always dominate

B. The first policy listed is used

C. Access is denied

D. The request is automatically delegated

Correct Answer: C. Access is denied

Question 8

Which practice best limits the risk of delegated authority?

A. Allowing delegation without an expiry time

B. Allowing the delegate to grant unlimited additional authority

C. Restricting delegation by action, resource, purpose, and time

D. Recording only the original user

Correct Answer: C. Restricting delegation by action, resource, purpose, and time

Question 9

What is role explosion?

A. A failure to authenticate a user

B. Uncontrolled growth in the number of roles and exceptional combinations

C. A policy service becoming unavailable

D. The deletion of all role assignments

Correct Answer: B. Uncontrolled growth in the number of roles and exceptional combinations

Question 10

Why is hiding an administrative button in a browser insufficient authorization?

A. Browsers cannot display buttons reliably

B. The client can be modified and direct requests can bypass the interface

C. Buttons cannot represent roles

D. Servers do not support authorization

Correct Answer: B. The client can be modified and direct requests can bypass the interface