A junior nurse should not be able to access every patient record in the hospital. A contractor should not be able to read internal financial reports. An employee logged in from an unrecognized device at 2AM probably should not be editing production configuration files.

Simple role-based systems handle obvious cases well. But as applications grow and access rules become more nuanced, those systems start to crack. You end up creating more and more specific roles, like finance_viewer, finance_viewer_us_only, finance_viewer_us_only_readonly, until the roles themselves become unmanageable.

Attribute-Based Access Control (ABAC) was designed to solve exactly this problem. It shifts from "what role does this user have?" to "what do we know about this user, this resource, and this situation?" and makes access decisions based on all of those factors together.

In this guide, you'll learn how ABAC works, how it evolved from earlier access control models, how policies are structured, how to implement it in code, and when to use it.

Table of Contents

• Prerequisites

• How Access Control Has Evolved

• What is Attribute-Based Access Control?

• The Four Building Blocks of ABAC

• How an ABAC Decision is Made

• How to Write ABAC Policies

• How to Implement ABAC in Code

• ABAC vs RBAC: When to Use Which

• Real-World Use Cases

• Enterprise ABAC Considerations

• Limitations and Challenges

• Conclusion

• Glossary

Prerequisites

To get the most from this article, you should have:

• A basic understanding of web authentication (logins, sessions, tokens)

• Familiarity with how users and resources relate in applications

• Some experience reading JavaScript or pseudocode

No prior knowledge of access control theory is required.

How Access Control Has Evolved

To understand why ABAC exists, it helps to understand what came before it and why each generation fell short.

Discretionary and Mandatory Access Control

Early access control models emerged from Department of Defense applications in the 1960s and 1970s. According to NIST Special Publication 800-162, these were Discretionary Access Control (DAC) and Mandatory Access Control (MAC).

In DAC, the owner of a resource decides who can access it. Think of a file on your computer where you choose who can read or edit it. In MAC, access is governed by a central authority using labels like "Classified" or "Top Secret." The system enforces these labels, not individual owners.

Both worked for their original purposes but didn't scale well to the complexity of modern networked systems.

Identity-Based Access Control and Access Control Lists

As networks grew, identity-based access control (IBAC) became common. The most familiar implementation is the Access Control List (ACL), a list of users or groups attached to a resource, specifying what each can do.

ACLs are simple and transparent, but they create a management burden as systems grow. Every new user needs to be added to every relevant list. Every permission change means hunting through lists across multiple resources. And when someone leaves the organization, you need to find and remove them everywhere.

Failure to do this consistently leads to users accumulating privileges they should no longer have.

Role-Based Access Control

Role-Based Access Control (RBAC) was a major step forward. Instead of assigning permissions directly to users, RBAC assigns them to roles. Users are then assigned roles. A hospital might have roles like nurse, doctor, admin, and billing_staff, each with different permissions.

This made administration much more manageable. Adding a new employee means assigning them appropriate roles. Removing an employee means removing their roles. Changing what nurses can do means updating the nurse role once.

RBAC became widely adopted and is still the right choice for many applications. But it has a structural weakness: as permission requirements become more granular, you have to create more specific roles. A nurse who can only see patients on their floor, only during their shift, or only for certain record types, needs a very specific role, or a combination of roles that interacts in complicated ways.

This proliferation is called "role explosion." The roles multiply until they are as difficult to manage as the individual permissions RBAC was supposed to replace.

Attribute-Based Access Control

ABAC emerged as a response to role explosion. Instead of assigning roles that bundle fixed permissions, ABAC evaluates the actual characteristics of the user, the resource, and the context at the moment of every access request.

A nurse gets access to a patient record not because they have the nurse role, but because their job title is "Nurse Practitioner," the patient is on their assigned floor, it's currently their shift, and the record type is within their scope of care. Change any of those facts, and the access decision changes accordingly.

As NIST SP 800-162 defines it, ABAC is:

"an access control method where subject requests to perform operations on objects are granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies that are specified in terms of those attributes and conditions."

What is Attribute-Based Access Control?

ABAC is a logical access control model where every access decision is made by evaluating a set of rules against the current values of attributes. Nothing is pre-computed or cached in role assignments. Every time a user tries to do something, the system asks: given what we know about this user, this resource, and this moment, should this be allowed?

This makes ABAC highly precise and highly dynamic. Permissions don't accumulate over time. They don't need manual cleanup when someone's role changes. The system simply evaluates the current state of attributes every time.

The model is formally described in NIST's guide to ABAC as being capable of enforcing both Discretionary Access Control and Mandatory Access Control concepts, making it more expressive than models that only support one or the other.

Companies like Axiomatics, major government agencies, and large enterprises managing cross-organizational data sharing all rely on ABAC for its ability to scale security policies across complex environments.

The Four Building Blocks of ABAC

Every ABAC system is built from four types of information. Understanding these clearly is the key to understanding how ABAC works.

1. Subject Attributes

The subject is whoever or whatever is requesting access. This is usually a user, but it can also be a service, an application, or an automated system, what NIST calls a Non-Person Entity (NPE).

Subject attributes describe who the subject is:

user.jobTitle         = "Nurse Practitioner"
user.department       = "Cardiology"
user.clearanceLevel   = "Confidential"
user.employmentStatus = "Active"
user.location         = "Floor 3"
user.shiftActive      = true

These attributes are typically sourced from an identity provider, HR system, or user directory. They're facts about the user that can be used in policies.

2. Object Attributes (Resource Attributes)

The object is whatever the subject is trying to access. This could be a file, a database record, an API endpoint, a service, or any other protected resource.

Object attributes describe what the resource is:

record.type           = "PatientMedical"
record.floor          = "Floor 3"
record.sensitivity    = "High"
record.owner          = "Dr. Williams"
record.department     = "Cardiology"

Object attributes are typically assigned when a resource is created and updated throughout its lifecycle. They're facts about the resource that determine who should be able to access it.

3. Action Attributes

The action is what the subject is trying to do to the object. Common actions include read, write, edit, delete, copy, execute, and share.

In many ABAC implementations, the action itself has attributes:

action.type           = "read"
action.bulk           = false

Policies can restrict which actions are allowed independently of the other attributes. A user might be able to read a document but not delete it, even if all their other attributes match.

4. Environment Conditions

Environment conditions are contextual factors that don't belong to either the subject or the object, but that should influence the access decision. NIST describes these as "dynamic factors, independent of subject and object, that may be used as attributes at decision time to influence an access decision."

Examples include:

environment.time           = "14:30"
environment.dayOfWeek      = "Wednesday"
environment.userLocation   = "Corporate Office"
environment.ipAddress      = "192.168.1.10"
environment.deviceStatus   = "compliant"
environment.threatLevel    = "low"

Environment conditions are what make ABAC truly dynamic. The same user, the same resource, and the same action might be allowed during business hours on a trusted device but denied at midnight from an unknown IP address.

How an ABAC Decision is Made

When a subject tries to perform an action on an object, the ABAC system runs through a specific process:

Step 1: Collect Attributes

The system gathers current attributes for the subject, object, action, and environment. This might involve querying a user directory, reading resource metadata, and checking current time and location.

Step 2: Find Applicable Policies

The system identifies which policies apply to this particular request. A request to read a patient record might have several policies that apply: one about clinical staff access, one about after-hours access, and one about record sensitivity levels.

Step 3: Evaluate Each Policy

Each applicable policy evaluates the collected attributes and returns permit or deny.

Step 4: Reconcile Conflicts

If multiple policies apply and they conflict, the system uses predefined combining rules. Common approaches are "deny overrides" (if any policy says deny, the request is denied) or "permit overrides" (if any policy says permit, the request is permitted).

Step 5: Enforce the Decision

The system grants or denies access based on the final decision.

This process happens every time an access request is made. There's no caching of role assignments or pre-computed permission tables. The decision reflects the current state of all attributes at the moment of the request.

How to Write ABAC Policies

Policies are the logic at the heart of ABAC. They're written as conditional rules that reference attributes. A well-written policy reads like a business rule, because that's exactly what it is.

Simple Boolean Policy

The most basic form evaluates whether certain attributes match:

// Policy: Only active employees can access internal resources
function canAccessInternalResource(user) {
  return user.employmentStatus === "Active";
}

What this does: Checks a single attribute, employment status, before allowing access. Any inactive, suspended, or terminated user is denied, regardless of their roles or past access history.

Multi-Attribute Policy

Real policies typically combine multiple attributes:

// Policy: A nurse can read a patient record
// if the patient is on their assigned floor
// and during their active shift

function canReadPatientRecord(user, record, environment) {
  const isNurse = user.jobTitle === "Nurse Practitioner";
  const isAssignedFloor = user.assignedFloor === record.floor;
  const isActiveDuty = user.shiftActive === true;

  return isNurse && isAssignedFloor && isActiveDuty;
}

What this does: Combines three conditions using AND logic. All three must be true for access to be granted. Change the nurse's floor assignment, and they immediately lose access to records on the previous floor, without any manual intervention.

Environment-Aware Policy

Adding environment conditions makes policies context-sensitive:

// Policy: Users can only access sensitive financial records
// during business hours from the corporate network

function canAccessSensitiveFinancialRecord(user, record, environment) {
  const isFinanceStaff = user.department === "Finance";
  const isHighSensitivity = record.sensitivity === "High";
  
  // If this is a high-sensitivity record, apply time and location controls
  if (isHighSensitivity) {
    const currentHour = new Date(environment.timestamp).getHours();
    const isBusinessHours = currentHour >= 9 && currentHour < 17;
    const isCorporateNetwork = environment.ipRange === "corporate";

    return isFinanceStaff && isBusinessHours && isCorporateNetwork;
  }

  // Lower sensitivity records only require finance department membership
  return isFinanceStaff;
}

What this does: Applies stricter controls to higher-sensitivity resources. The same user gets access to low-sensitivity records at any time, but high-sensitivity records require them to be on the corporate network during business hours. The policy logic mirrors the actual business rule: sensitive data needs more protection.

Ownership-Based Policy

ABAC can also implement discretionary ownership rules:

// Policy: A user can edit a document
// if they own it, or if they have editor permissions
// and the document isn't locked

function canEditDocument(user, document, action) {
  const isOwner = document.ownerId === user.id;
  const hasEditorPermission = user.permissions.includes("document.edit");
  const isUnlocked = document.status !== "locked";

  return (isOwner || hasEditorPermission) && isUnlocked;
}

What this does: Combines ownership (an attribute of the relationship between user and document) with explicit permissions and resource state. An editor can't edit a locked document even if they have the edit permission. An owner can edit their own documents but not locked ones.

How to Implement ABAC in Code

Let's build a simple ABAC evaluation engine that puts these pieces together.

Step 1: Define the Attribute Structure

First, define clear data structures for your attributes:

// A user (subject) requesting access
const user = {
  id: "user-123",
  name: "Sarah Chen",
  department: "Cardiology",
  jobTitle: "Nurse Practitioner",
  clearanceLevel: 2,
  assignedFloor: "Floor 3",
  shiftActive: true,
  employmentStatus: "Active"
};

// A resource (object) being accessed
const patientRecord = {
  id: "record-456",
  type: "PatientMedical",
  floor: "Floor 3",
  sensitivity: 2,
  ownerId: "doctor-789",
  department: "Cardiology"
};

// Environment conditions
const environment = {
  timestamp: new Date().toISOString(),
  ipAddress: "10.0.1.25",
  ipRange: "corporate",
  deviceCompliant: true
};

Step 2: Write Policy Functions

Write individual policies as pure functions that take attributes and return boolean values:

// policies/patientRecord.js

// Policy 1: User must be active and clinical staff
function isClinicalStaff(user) {
  const clinicalTitles = [
    "Nurse Practitioner",
    "Physician",
    "Resident",
    "Medical Assistant"
  ];
  return (
    user.employmentStatus === "Active" &&
    clinicalTitles.includes(user.jobTitle)
  );
}

// Policy 2: Record must be within the user's assigned area
function isAssignedToRecord(user, record) {
  return (
    user.department === record.department &&
    user.assignedFloor === record.floor
  );
}

// Policy 3: User must be on active shift
function isOnActiveShift(user) {
  return user.shiftActive === true;
}

// Policy 4: High-sensitivity records require compliant devices
function meetsDeviceRequirements(record, environment) {
  if (record.sensitivity >= 3) {
    return environment.deviceCompliant === true;
  }
  return true; // No device requirement for lower sensitivity
}

What this does: Each policy is a small, focused function. This makes policies easy to test individually, easy to read, and easy to reuse across different access decisions. A policy for "is this user clinical staff" can be applied to many different resource types.

Step 3: Build an Evaluation Engine

Combine your policies into a decision engine:

// abac/engine.js

function evaluateAccess(user, resource, action, environment, policies) {
  // Collect all policy results
  const results = policies.map(policy => {
    try {
      return policy(user, resource, action, environment);
    } catch (error) {
      console.error(`Policy evaluation error: ${error.message}`);
      return false; // Fail closed: deny on error
    }
  });

  // Deny-overrides: if any policy denies, access is denied
  return results.every(result => result === true);
}

// Assemble policies for reading patient records
const readPatientRecordPolicies = [
  (user) => isClinicalStaff(user),
  (user, record) => isAssignedToRecord(user, record),
  (user) => isOnActiveShift(user),
  (user, record, action, environment) => meetsDeviceRequirements(record, environment)
];

// Make an access decision
const canRead = evaluateAccess(
  user,
  patientRecord,
  "read",
  environment,
  readPatientRecordPolicies
);

console.log(`Access ${canRead ? "granted" : "denied"}`);
// → Access granted (all conditions met)

What this does: The engine loops through each policy function, passing in the relevant attributes. If all policies return true, access is granted. If any returns false, access is denied. This is called "deny-overrides combining". The try-catch ensures that if a policy throws an error, access is denied rather than granted, following the security principle of fail-closed.

Step 4: Add Attribute Collection

In a real application, attributes come from multiple sources:

// attributes/collector.js

async function collectAttributes(userId, resourceId) {
  // Collect in parallel for performance
  const [user, resource, environment] = await Promise.all([
    fetchUserAttributes(userId),      // From identity provider or HR system
    fetchResourceAttributes(resourceId), // From resource metadata store
    collectEnvironmentConditions()    // Time, IP, device status
  ]);

  return { user, resource, environment };
}

async function fetchUserAttributes(userId) {
  // This would query your user directory, LDAP, or identity provider
  const user = await userDirectory.findById(userId);
  const shift = await shiftService.getActiveShift(userId);
  
  return {
    ...user,
    shiftActive: shift !== null,
    assignedFloor: shift?.floor || null
  };
}

async function collectEnvironmentConditions() {
  return {
    timestamp: new Date().toISOString(),
    ipAddress: request.ip,
    ipRange: await networkService.classifyIP(request.ip),
    deviceCompliant: await deviceService.checkCompliance(request.deviceId)
  };
}

What this does: Attribute collection is separated from policy evaluation. This is an important design decision: it means you can test policies with any attribute values without needing real users or resources. It also means you can swap out the source of attributes (say, moving from an on-premise directory to a cloud identity provider) without changing your policies.

Step 5: Integrate with Your API

Use the evaluation engine in your API handlers:

// middleware/abac.js

function requireAccess(action, resourceType) {
  return async (req, res, next) => {
    try {
      const { user, resource, environment } = await collectAttributes(
        req.user.id,
        req.params.id
      );

      const policies = getPoliciesFor(resourceType, action);
      const allowed = evaluateAccess(user, resource, action, environment, policies);

      if (!allowed) {
        // Log the denial for audit purposes
        auditLog.record({
          userId: req.user.id,
          resourceId: req.params.id,
          action,
          decision: "denied",
          timestamp: new Date()
        });

        return res.status(403).json({ error: "Access denied" });
      }

      next();
    } catch (error) {
      // Fail closed: deny access on unexpected errors
      return res.status(403).json({ error: "Access denied" });
    }
  };
}

// Use in route definitions
app.get(
  "/patient-records/:id",
  authenticate(),                               // First verify identity
  requireAccess("read", "patientRecord"),       // Then evaluate ABAC
  patientRecordController.getById               // Then handle the request
);

What this does: The ABAC check lives in middleware that runs between authentication and the route handler. Authentication establishes who the user is. ABAC decides whether that user can do what they're trying to do. This separation keeps authorization logic out of your business logic.

ABAC vs RBAC: When to Use Which

RBAC isn't obsolete. It's genuinely the right choice for many applications. The question is which model fits your specific access requirements.

RBAC Strengths

RBAC is simple to understand, simple to implement, and simple to audit. If you can describe your access requirements as a list of roles with fixed permissions, RBAC works well. Most SaaS applications start with RBAC and it serves them fine for years.

A typical RBAC check looks like:

// Simple RBAC: does the user have the required role?
function canAccess(user, requiredRole) {
  return user.roles.includes(requiredRole);
}

It's fast, clear, and easy to debug. When something goes wrong, you check which roles the user has and which roles the resource requires.

Where RBAC Breaks Down

RBAC struggles when permissions need to depend on factors that aren't captured by a role. If you need to express "finance managers can view financial records, but only for their own region, and only during business hours," you're outside what a role alone can express cleanly.

You either need an extremely specific role (finance_manager_us_east_business_hours) that creates the role explosion problem, or you add conditional logic to your application code that effectively recreates ABAC, just in a less organized way.

RBAC vs ABAC Comparison

Combining Both Models

RBAC and ABAC work well together. A common pattern is to use RBAC for coarse-grained access control (which sections of your application can this user see?) and ABAC for fine-grained control within those sections (which specific records can they access?).

For example, a role might grant access to the patient records section of a hospital system. Within that section, ABAC policies determine which specific records a user can view or edit based on their department, assigned floor, and active shift.

Real-World Use Cases

Healthcare Records Management

Healthcare is one of the clearest examples of why ABAC matters. Patient privacy regulations require precise access control, and patient care requires that the right staff can access records quickly when they need them.

An ABAC policy in a hospital might allow a nurse to view a patient's record only when:

1. the patient is currently admitted to the nurse's assigned floor,

2. the nurse is on an active shift,

3. the access occurs from within the hospital network,

4. and the record type is within the nurse's care scope.

According to WorkOS's ABAC analysis, in emergency situations ABAC systems can automatically expand access rights. For example, an ER doctor automatically gains broader access to patient records to provide immediate care, with this access being time-bound and closely monitored.

All of these rules would require dozens of roles in an RBAC system, and those roles would still struggle to handle the emergency access scenario dynamically.

Corporate Data Access

Large enterprises typically have employees across departments, roles, locations, and clearance levels who need different views of the same underlying data. A document might be accessible to finance managers in the US region during business hours, accessible to executives globally at any time, but inaccessible to contractors entirely.

ABAC expresses all of these rules in policies. As employees change departments, go on leave, or change roles, their attributes update in the identity system and their access changes automatically, with no manual ACL updates required.

Government and Classified Information

The US federal government's adoption of ABAC is described in NIST SP 800-162, which was developed to address the Federal Identity, Credential, and Access Management (FICAM) requirements. Federal agencies deal with information shared across organizational boundaries, with varying classification levels and need-to-know requirements.

ABAC allows an analyst in one agency to access information from another agency without requiring the second agency to pre-provision an account for them. The analyst's clearance attributes, organizational affiliation, and project assignments are evaluated against the resource's classification and access rules at the time of the request.

Multi-Tenant SaaS Applications

SaaS applications that serve multiple organizations need to ensure strict data isolation between tenants while supporting complex permission structures within each tenant.

ABAC handles this naturally. A resource attribute like record.tenantId is evaluated against the user attribute user.tenantId, and no cross-tenant access is possible through policy. Within a tenant, ABAC supports as much complexity as the tenant's policies require.

Enterprise ABAC Considerations

Deploying ABAC at enterprise scale introduces several challenges that don't exist in smaller implementations.

Policy Administration

Policies need to be authored, reviewed, tested, and deployed. According to NIST SP 800-162, this requires a Policy Administration Point (PAP), an interface for creating and managing policies. Without proper tooling, policies become difficult to audit and maintain.

In practice, this means treating policies like code: version control, code review, and automated testing.

Attribute Quality and Freshness

ABAC is only as good as the attributes it evaluates. If user attributes are stale, for example, for a user who changed departments but whose directory entry hasn't been updated, the access decisions will be wrong.

NIST warns that "attributes that are not refreshed as often will ultimately be less secure than attributes that are refreshed in real time." Building reliable attribute pipelines from authoritative sources is often the hardest part of ABAC deployment.

Performance

Evaluating policies on every request has a performance cost. Each evaluation may require fetching attributes from multiple sources. To manage this, many implementations use attribute caching, but caching introduces the staleness problem described above.

The solution is to cache with appropriate TTLs (time-to-live values) based on how quickly each attribute type can change. A user's department changes rarely and can be cached for hours. A user's active shift status might change every 8 hours and needs a shorter cache. Real-time location might not be cacheable at all.

Audit Logging

Because ABAC makes decisions dynamically, auditing requires logging the attributes used in each decision, not just the decision itself. A log entry that says "access denied" is only useful if it also captures why access was denied and which attributes failed to satisfy which policies.

NIST notes that without tracking attribute values at decision time, accountability requirements can't be met.

Limitations and Challenges

ABAC is powerful, but it's not the right solution for every access control problem. It's worth being honest about its limitations before committing to an implementation.

Complexity: According to NIST SP 800-162, "an ABAC system is more complicated, and therefore more costly to implement and maintain, than simpler access control systems." The flexibility that makes ABAC powerful also makes it harder to reason about. A user asking "why can't I access this?" requires examining all the attributes that were evaluated and which conditions weren't met.

Policy Conflicts: In complex systems with many policies, conflicts between policies can occur. Two policies might individually seem correct but together produce unexpected results. Resolving these conflicts requires clear precedence rules and careful policy design.

Attribute Management Overhead: Maintaining accurate attributes across large user populations requires investment in identity infrastructure. Attributes from different systems need to be normalized, validated, and kept synchronized. As NIST describes it, organizations need an entire attribute management infrastructure, not just a policy engine.

Testing is Hard: Because access depends on the combination of potentially dozens of attributes, testing edge cases comprehensively requires thought. A policy that works correctly for typical cases might behave unexpectedly for unusual attribute combinations.

Not Always Worth the Investment: For applications with straightforward access requirements, ABAC introduces unnecessary complexity. If your needs can be expressed cleanly as a set of roles with fixed permissions, RBAC is the better choice.

Conclusion

Attribute-Based Access Control represents a genuine evolution in how applications manage authorization. Rather than maintaining ever-growing lists of roles and permissions, ABAC evaluates the actual characteristics of users, resources, and context at the moment of every request.

It solves the role explosion problem that plagues complex RBAC implementations. It enables access rules that reflect real business policies rather than technical approximations of them. It handles dynamic scenarios, emergencies, time-based restrictions, and cross-organizational access that are difficult or impossible to express with static roles.

But ABAC isn't universally better. It's more complex to build, harder to debug, and requires investment in attribute management infrastructure that simpler models don't need. Many applications are well-served by RBAC, and some use RBAC and ABAC together.

The right question isn't "should I use ABAC?" It's "are my access requirements complex enough that the investment in ABAC pays off?" If your access rules change frequently, depend on resource or environment context, or need to scale across organizational boundaries, ABAC is worth serious consideration.

Start by identifying where your current access control model is breaking down. If you're creating roles to represent every edge case, if you're writing conditional logic inside route handlers that checks specific attribute values, or if users are accumulating permissions they should no longer have, those are signals that a more expressive model would help.

ABAC is the tool for when roles aren't enough.

Glossary

ABAC (Attribute-Based Access Control): An access control method where authorization decisions are made by evaluating policies against the attributes of subjects, objects, actions, and environment conditions. Defined by NIST as the approach where "subject requests to perform operations on objects are granted or denied based on assigned attributes."

Subject: The entity requesting access to a resource. Usually a human user, but can also be a service, automated process, or device. Also called the "requestor."

Object: The resource being protected, such as a file, database record, API endpoint, service, or any system resource whose access is managed by the ABAC system.

Attribute: A characteristic of a subject, object, action, or environment expressed as a name-value pair. For example, user.department = "Finance" or record.sensitivity = "High".

Subject Attributes: Properties describing the user or service making the request, such as job title, department, clearance level, or current location.

Object Attributes: Properties describing the resource being accessed, such as its type, owner, sensitivity level, or department.

Environment Conditions: Contextual factors independent of both subject and object that influence access decisions. Examples include time of day, day of week, IP address, device compliance status, or current threat level.

Policy: A rule or set of rules that evaluates attribute values to determine whether a specific access request should be permitted or denied. ABAC policies are typically written as logical conditions.

Policy Decision Point (PDP): The component of an ABAC system that evaluates policies and attributes to compute an access decision.

Policy Enforcement Point (PEP): The component that intercepts access requests and enforces the decisions made by the PDP.

Policy Information Point (PIP): The component that retrieves attribute values needed by the PDP to make decisions.

Policy Administration Point (PAP): The component that provides an interface for creating, testing, and managing policies.

RBAC (Role-Based Access Control): An access control model that assigns permissions to roles and users to roles. Simpler than ABAC but less expressive for complex, dynamic access requirements.

Role Explosion: The proliferation of increasingly specific roles in an RBAC system as access requirements become more granular, eventually making the roles as difficult to manage as individual permissions.

DAC (Discretionary Access Control): An access control model where resource owners control who can access their resources. Common in file systems.

MAC (Mandatory Access Control): An access control model where access is governed by a central authority using classification labels, independent of resource owner preferences.

ACL (Access Control List): A list associated with a resource that specifies which users or groups have which permissions. Common in identity-based access control systems.

Non-Person Entity (NPE): A subject that is not a human user, such as an automated service, application, or network device, that can request access to resources.

Attribute Caching: Storing previously retrieved attribute values to improve performance, at the cost of potentially using stale data for access decisions.

Deny-Overrides Combining: A policy combining rule where if any applicable policy returns deny, the overall decision is deny, regardless of other policies that may return permit.

Fail-Closed: A security design principle where unexpected errors or missing information result in access being denied rather than granted, reducing the risk of unauthorized access.

Source: Definitions adapted from NIST Special Publication 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations, January 2014 (with updates through August 2019).

In this handbook, we’ll explore various access control mechanisms and walk through two approaches for building a scalable Attribute-Based Access Control solution in React.

First, we'll examine CASL, a popular open-source authorization library. Then, we’ll build a custom solution from scratch to deepen your understanding of how to design a flexible permissions validation system.

This guide includes detailed code walkthroughs for both approaches, covering key concepts such as state management, custom hooks, and caching/conditional queries using Redux Toolkit.

If you plan to implement the code, you should have a basic understanding of how a web app using state management works. But even if you're not coding along, you’ll still gain valuable insights into the design patterns and best practices behind creating a robust permissions validation system.

Let’s dive in!

Table of Contents

• What is access control? How is it different from AuthZ, AuthN and permissions?

• Multi-layered Access Control

  • Hogwarts in Harmony: A Unified Defense

• Access Control Models

• Why ABAC?

• Attribute-Based Access Control In Depth

  • Core Components

  • How does ABAC work?

  • Who defines ABAC policies?

  • Where should you enforce it — back-end or front-end?

  • Where are policies defined?

• 1: Implementing Permissions with CASL

• 2: Build Your Custom Permissions Validation Framework

  • Policy Definition using Policy as Code

  • Workflow Overview

  • Policy Validation

  • Policy Enforcement

• Let’s Summarize

  • Further Scaling Considerations

• Conclusion

What is Access Control? How is it Different from AuthZ, AuthN, and Permissions?

Let me break down these terms using the example of an airport.

When you arrive at the check-in counter, you present your passport to verify your identity. Authentication (Who are you?) is the process of confirming that you are who you say you are.

Once your identity is confirmed, the airline checks if you are authorized to board the flight by verifying your ticket, or if you are authorized to access the lounge by reviewing your membership status, class of travel, or loyalty program tier. Authorization (What are you allowed to do?) is about determining what specific resources you are permitted to access.

Permissions (What specific actions can you take?) are the granular details of what you're allowed to do within the scope of your authorization. If you’re authorized to board the flight and access the lounge, your permissions might include: sitting at the boarding gate, relaxing in the lounge, shopping in duty-free, or if you’re staff, accessing restricted areas.

Access control refers to the measures in place to enforce authorization policies. These are the rules the airport follows to validate boarding passes or lounge access, and to guide you to the correct gate.

Multi-layered Access Control

To ensure comprehensive protection, access control should be enforced at multiple layers, depending on your application architecture.

To understand this, here’s a little something for my fellow Potter-heads:

Hogwarts in Harmony: A Unified Defense

At the very edge of Hogwarts, you’ve got your Perimeter—the outer defenses that keep dark forces at bay. Think of these as the high, enchanted stone walls that surround the castle—acting like a firewall, with winged boar statues perched on the parapets, keeping watch. Only those with proper clearance are allowed through the gates, ensuring that no unwanted guests, like dark wizards, can enter.

When students arrive at Hogwarts, they come by boats or Thestral-pulled carriages, which are the only trusted means of transport. This is like Endpoint Detection and Response (EDR), ensuring that only the right devices (or carriages) are allowed entry.

If a student tries to use a non-compliant device (like a cursed broomstick or Apparition), they won’t be allowed inside. Mobile Device Management (MDM) acts like the magical inspection process—only devices that meet Hogwarts' standards can pass through the gate and connect to the school’s systems.

At Hogwarts, owls are the trusted messengers that carry messages between the school and the outside world. These owls, like API keys and JWTs, carry the seal of approval and only deliver messages to the right recipients. Dark creatures like Dementors are forbidden from delivering messages, ensuring that only the right communications make it through.

The Acceptance Letter from Hogwarts is like an OAuth token. It proves you belong to the magical world and grants you access to the school without needing to show your face or reveal your blood status.

Inside the castle, access to different areas is controlled by who you are and your role at Hogwarts. For example, Role-Based Access Control (RBAC) ensures that only Gryffindors can access their common room, while Slytherins have their own. Prefects get additional privileges, like access to the Prefect's bathroom or other special rooms. These roles define where you can go and what you can do within the castle.

But things get more nuanced with Attribute-Based Access Control (ABAC). For instance, only students enrolled in Care of Magical Creatures have access to the Forbidden Forest, but they’re only allowed in during daylight hours, when it's safer. The forest is too dangerous at night, and only those with the right attributes (like a specific timetable) can enter at the right time.

Within Hogwarts is the Philosopher’s Stone, hidden away in a vault guarded by powerful enchantments. This is your Data Layer – the most precious resources, secured by powerful protections. Just like database permissions, the vault is protected by Fluffy, the three-headed dog, a series of enchantments, and traps. Similarly, row-level and column-level security ensure that only Harry Potter can retrieve the Stone because he is the only one worthy (you can only access what’s meant for you).

To summarize,

1. Network Layer (Infrastructure-level): Firewalls and virtual private networks (VPNs) to control incoming and outgoing network traffic.

2. Endpoint Layer (Device-level): Endpoint Detection and Response (EDR) and Mobile Device Management (MDM) to ensure only compliant device can access your application.

3. API Layer (Service-level): API keys, JSON Web Tokens (JWTs), and API gateways to authenticate and authorize the caller and enforce policies such as rate limiting, IP whitelisting, and so on.

4. Application Layer: Where the core business logic for authorization typically resides (which this guide is all about).

5. Data Layer (Database-level): Database permissions, row/column-level security.

Access Control Models

At the application layer, three primary models of access control are commonly used in software engineering: Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), and the more recent Relationship-Based Access Control (ReBAC).

RBAC (Role-Based Access Control) is a model where access is granted or denied based on the roles assigned to a user.

A role is a collection of permissions or privileges that define what actions a user can perform within a system. Roles simplify access control by assigning users to predefined roles, rather than managing individual permissions for each user.

When a user is assigned a role, they automatically inherit all the permissions associated with that role. Each permission also has a scope, which defines the boundaries or contexts within which the role's permissions apply. Scopes are typically used to restrict access to specific resources or data.

Let me illustrate this (and all concepts throughout this guide) using a blogging application as an example. This app allows users to create, manage, and publish blog posts in multiple categories. It supports a variety of user roles, each with different levels of access to the content and functionality within the platform.

• Admin: Can view, edit, delete, and manage all blog posts and user roles. (Scope: All posts and users)

• Editor: Can edit and approve posts within their assigned categories (for example, Tech, Lifestyle). (Scope: Assigned categories)

• Author: Can create and edit only their own blog posts. (Scope: Own posts)

• Guest User: Can view public, published blog posts but cannot access private posts. (Scope: Public published posts only)

The relationship between users and roles is often many-to-many, and roles may also be hierarchical, allowing for complex permission structures.

ABAC (Attribute-Based Access Control) is a model where access decisions are made based on the attributes of the subject (user), object (resource), and the environment. It dynamically evaluates whether a subject can perform an action on an object based on these attributes and policies that govern them.

ReBAC (Relationship-Based Access Control) is an emerging model that grants access based on the relationships between users and resources. For example, it might allow only the user who created a post to edit it. This model is particularly useful in social networking applications, where access depends on user relationships (such as friends, followers, or content ownership).

Why ABAC?

RBAC provides several benefits, including ease of implementation, reduced administrative overhead by enabling quick onboarding of new users, and simplified auditing, as it makes it easy to review which roles have access to sensitive data.

But, as the platform grows, you introduce more nuanced requirements for access control. These new requirements lead to the creation of new roles to meet specific access needs:

1. Publisher: Can view, edit, approve, publish, and delete posts across all categories, but cannot manage user roles or settings.

2. Junior Author: Can create and edit their own posts within assigned categories.

3. Senior Author: Can create and edit their own posts in any category.

4. User (Subscriber): Can view and comment on private posts in addition to public posts.

5. Premium Subscriber: Has all the permissions of a regular subscriber and access to exclusive posts.

Before long, you may find yourself managing an ever-growing list of roles such as Senior Publisher, Publishing Supervisor, Guest User, Subscriber, Premium Subscriber, Graphic Designer, UX Designer, Photographer, Social Media Manager, US Marketing Specialist, UK Marketing Specialist, Web Developer, Data Analyst, Membership Manager, Ad Manager, Legal Advisor, and Sponsor Manager.

Introducing additional requirements—such as blog category, seniority, and jurisdiction—can quickly lead to role explosion. Just imagine how this would scale in data-intensive enterprise applications like finance or healthcare.

While scopes work well when boundaries are clear and static (for example, department, blog types), they require custom checks for more granular attributes such as seniority, length of service, blog creation time, or publication status. Scopes also struggle to account for attributes that change over time, like the location or timing of access.

Because RBAC relies on roles and fixed scopes to make access decisions, it becomes limited in handling complex and dynamic access needs. That is why, OWASP (Open Worldwide Application Security Project) recommends using ABAC or ReBAC over RBAC, as they are more effective in implementing the principle of least privilege.

Attribute-Based Access Control In Depth

Core Components

The core components of ABAC are:

Attributes: Attributes are key-value pairs used to define the access context. Examples include:

• User attributes: These describe the characteristics of the person requesting access, like role, department, age, clearance level, and so on. 💡 As you can see, role can be one of the attributes based on which access control decision is based. So, ABAC is essentially an extension of RBAC.

• Resource attributes: These describe the characteristics of the resources (such as files, databases, or services) being accessed. For example, owner, category, status, and so on.

• Action attributes: These define what actions are being requested by the user on the resource. For example, read access like view/open, write access like create/modify/delete, execute access like process/run, and so on.

• Environment attributes: These include contextual elements such as time or location that influence the decision-making process.

Policies: Policies are logical rules or statements that define which combinations of attributes allow or deny access. For instance, A publisher can publish approved posts in assigned categories during business hours.

How does ABAC work?

Let’s take Sam, a publisher for our blog, as an example. Sam is authorized to publish posts that have been approved by the editor, but only within the categories she’s been assigned, such as ‘Tech,’ ‘Lifestyle,’ and ‘Health.’ She’s allowed to publish these posts only during specific hours, say from 9 AM to 6 PM.

Sam’s role as a publisher and her assigned categories were set when she joined the team. The resource here is the Post, which is given a category when it’s created. The action she can perform is to publish, and the environmental condition is that it needs to be during business hours.

Since the access control rule is based on Sam’s attributes—her role as a publisher and the categories she’s assigned to—she can publish posts within those categories. If any of her attributes change, like if she moves to a different department, such as Membership Management, or if her assigned categories change to ‘Fashion’ or ‘Travel,’ her access is automatically revoked.

ABAC allows administrators to set access controls without needing to know who specifically will need access. As new members join an organization, there's no need to modify existing rules or object attributes; as long as they have the necessary attributes, they can access the required resources. This ability to automatically accommodate new and unanticipated users without additional adjustments is a key advantage of using ABAC. (Source)

Who defines ABAC policies?

1. Identity and Access Management administrators:

   In many organizations, security administrators or access control administrators define ABAC policies. Their responsibilities include analyzing business needs, risk management, regulatory compliance, and ensuring that users have the right level of access to resources. They translate security requirements into policies based on the different attributes and conditions specific to the organization.

2. Business and resource managers:

   In certain cases, business units or department managers may also have input into defining policies. They understand the operational needs and are best positioned to indicate how data should be accessed by their teams.

   For example, a Membership Manager might define policies governing who can access premium blog posts based on subscription status, user role, or membership level (e.g., Subscriber, Premium Subscriber).

Where should you enforce it — back-end or front-end?

Access control policies should be enforced in both the front-end and the back-end. Here's why:

1. Front-end enforcement

• Instant feedback: When you enforce ABAC policies on the front-end, you can immediately show or hide elements (like buttons, links, or menus) based on the user’s attributes. This makes the interface cleaner and helps users understand what they can or can’t do right away.

• Smarter UI: You can prevent showing options to users that they shouldn’t see. For example, hiding features if the user doesn’t have the correct role or permissions. This makes the UI feel more intuitive and responsive.

• Reduced server load: By enforcing certain access restrictions in the front-end, you reduce unnecessary requests to the back-end, improving app performance and reducing load on your servers.

• Security layer: While the front-end isn’t where sensitive data should live, you can still add an extra layer of security by using it to filter out invalid actions or content before a request is made to the back-end. For instance, you can hide sensitive UI elements (like admin controls) or disable buttons based on user attributes, making it harder for unauthorized users to even attempt to trigger certain actions.

2. Back-end enforcement

• Bypass risk: The downside of relying only on the front-end is that users can easily bypass it. With the right tools, they can manipulate the front-end code or network requests (using browser dev tools or API proxies). This is why back-end enforcement is essential—it ensures that access rules are applied server-side, where they can’t be tampered with.

• Protecting sensitive data: The back-end is where your sensitive data is stored and processed. By enforcing ABAC policies on the server, you ensure that unauthorized users can’t access, modify, or even view sensitive information. To avoid data leaks, you should always filter-out sensitive content based on user permissions and send only relevant content to the client.

Now that you know ABAC policies need to be enforced both in the front-end and the back-end, the next question is: Where do you define these policies?

As a developer, you might think: "If I know the policies defined by the security team, I can just translate them into code for both the front-end and back-end."

For example, if the policy is that only senior authors can approve blogs in specific categories, you might write something like this:

Front-end example (simplified):

if (user.role === 'author' && user.seniority === 'senior' && user.categories.includes('Tech')) {
  showApprovalDashboard();
} else {
  hideApprovalDashboard();
}

Back-end example (simplified):

if (user.role === 'author' && user.seniority === 'senior' && user.categories.includes('Tech')) {
  return res.send(approvalDashboardData);
} else {
  return res.status(403).send('Forbidden: You do not have approval access for this category.');
}

But how do you ensure policy consistency across both layers of your application without duplicating logic?

What happens when you need to introduce additional conditions to this policy, like factoring in other user attributes or combining permissions with feature flags to conditionally enable certain features for specific users?

And, what if your requirement varies for each user like:

• Display certain UI elements only for users with a premium subscription,

• Block an API call for a social media manager based on specific attributes,

• Or hide an entire route for users who are not admins?

Without a structured approach, your app becomes a tangled mess of if-else statements scattered across the codebase.

Read on to find the answers to these questions!

Where are policies defined?

Before we dive into the implementation details, let me briefly revisit the question from the previous section: Where should you define the policies?

When there are multiple ways to access a service – whether through a mobile app, web app, or other platforms – the back-end should serve as the source of truth for policy definitions. Defining ABAC policies in the back-end keeps things consistent and secure across all platforms. This means that all clients interact with the same set of rules, reducing the chances of policy discrepancies.

So, the back-end is where all the policy definitions live, and it makes them available to the front-end when needed. The front-end then enforces these decisions on the user interface. But don't forget, the back-end should always enforce these policies as well.

In the upcoming sections, you will learn two approaches to implementing the ABAC access control model.

1: Implementing Permissions with CASL

CASL is an open-source, isomorphic JavaScript library that makes managing permissions in your app much easier with its simple, declarative API.

What this means is that you can use CASL on both the client-side (front-end) and server-side (back-end). This is especially great for full-stack applications, as it ensures consistency in access control. The same permission logic can be applied across your entire app, no matter where the request is coming from.

With CASL, you get declarative access control, which means you define what is allowed, rather than worrying about how to check permissions. This makes your code cleaner, more readable, and easier to maintain. Whether you're hiding UI elements in the front-end or making sure an API call is authorized in the back-end, CASL helps you enforce permissions consistently across your app.

The best part? You can define permissions using a clear, expressive syntax. This makes it easy to manage even complex permission rules. For example, you can control what a user can (or cannot) do based on their role, the resources they own, and other factors.

And it’s not just for React/React Native – they provide supporting packages for Angular, Vue and Aurelia too.

Step 1: Install CASL

First, install CASL using a package manager. I have used v6 for the code examples.

npm install @casl/react @casl/ability
# or
yarn add @casl/react @casl/ability
# or
pnpm add @casl/react @casl/ability

Step 2: Define the abilities

In CASL, think of "abilities" as a set of rules that define what actions a user can or cannot perform on specific subjects (like "Posts" or "Users"). Let’s use our earlier examples from the blogging application. For simplicity, we’ll consider two types of users: Admins and Authors.

• An Admin can manage everything.

• An Author can create and edit their own posts within assigned categories, but they cannot delete published posts.

Now, create a defineAbilities.ts file to define the abilities in a high-level, declarative manner using DSL.

Start by defining the Actions that a user can perform (for example, create, read, update, delete, manage) and the Subjects (the entities that actions are performed on, such as ‘User’, ‘Post‘, or objects like User or Post).

//defineAbilities.ts

type Actions = 'create' | 'read' | 'update' | 'delete' | 'manage';
type Subjects = 'User' | 'Post' | 'all' | User | Post

Then, create a type representing the structure of your abilities. It combines the Actions and Subjects to create a clear and type-safe ability system.

The PureAbility<[Actions, Subjects]> means that the ability system will know what actions are allowed on which subjects. The createAppAbility function is used to create an ability instance based on your defined actions and subjects. You can use this function to create abilities specific to a user’s role or permissions.

//defineAbilities.ts

import { CreateAbility, PureAbility, AbilityBuilder, createMongoAbility } from '@casl/ability';
// other imports

type Actions = 'create' | 'read' | 'update' | 'delete' | 'manage';
type Subjects = 'User' | 'Post' | 'all' | Post | User

export type AppAbility = PureAbility<[Actions, Subjects]>
export const createAppAbility = createMongoAbility as CreateAbility<AppAbility>

Note that createMongoAbility is only used to support simple operators from MongoDB Query Language, like $in, $lte, $eq that are used to specify conditions for your rules. Don't worry – this doesn't mean your app has to use MongoDB, nor do you need to be familiar with the query language. You can also skip these entirely and create custom operators.

Next, define a function called defineAbilityFor, which takes a user object as its argument and returns an ability instance. The user object is expected to have a role property (such as 'admin' or 'author') that determines the user's permissions.

The userPermissions object maps each user to a function that defines their permissions using the can and cannot methods provided by AbilityBuilder. This approach scales better than a switch case as you add more roles.

//defineAbilities.ts

export default function defineAbilityFor(user: User) {
  const { can, cannot, build } = new AbilityBuilder(createAppAbility);
   const userPermissions = {
    admin: () => {
      // Admin user can manage everything
      can('manage', 'all');
    },
    author: () => {
      // Author can create Posts but cannot delete them
      can('create', 'Post');
      cannot('delete', 'Post');
    },
    // Add more roles
  };

  // Call the permissions associated with the user, or default to no permissions.
  const permissions = userPermissions[user.role] || (() => {});
  permissions(); 

  return build();
}

Note: manage and all are keywords in CASL where manage means any action and all means any subject.

To specify conditions that prevent users from updating posts they haven't created, deleting published posts, and to restrict access to certain fields, you can use conditions and fields. CASL allows you to set specific conditions on permissions via the subject property, which represents the object, and the fields property, which represents the object’s properties that the user is interacting with.

Add conditional rules to the above file.

   author: () => {
      // Author can create posts in the 'Tech' and 'Lifestyle' categories
      can('create', 'Post', { category: { $in: ['Tech', 'Lifestyle'] } });

      // Author can update the title and description of posts authored by the user
      can('update', 'Post', ['title', 'description'], { ownerId: user.id, status: 'draft' });

      // Author cannot delete posts that have a 'Published' status
      cannot('delete', 'Post', { status: 'published' });
    },

In CASL, direct rules (like can) are combined using OR and inverted rules (like cannot) and conditions are combined using AND. The author:

• can create Posts in their assigned categories OR

• can update title/description of the Posts that they own AND are in Draft state

• AND cannot delete published Posts

Remember, for the same action/subject pair, you should define cannot rules after can rules, else they will be overridden.

When dealing with a Post object that has a nested details field (for example, details.author.name, details.metadata.tags), you can use the * and ** wildcards to control access based on the level of nesting.

• The * wildcard matches only the top-level fields within a given object.

  This means it will grant access to fields that are directly inside the details object, but not any nested fields.

• The ** wildcard allows access to all fields, including deeply nested ones, within the object.

  This means it will grant access to every field inside details, regardless of how deep the nesting goes.

// gives access to all nested fields under Post.details, no matter how deep they are
can('read', 'Post', ['details.**']) 

// give access to only the top level fields (such as details.body, details.author)
can('read', 'Post', ['details.*'])

Note that * matches all symbols except dot (.)

The ability instance in defineAbilities.ts can be used to enforce permissions across your app. This file can act as a shared library, so both the front-end (for example: React) and back-end (for example: Node.js) can access and use the same permission logic.

While the AbilityBuilder works for permissions defined inside the system, if your application receives externally defined permissions as a JSON object, like:

[
  {
    action: 'read',
    subject: 'Post'
  },
  {
    inverted: true, // indicates cannot rules
    action: 'delete',
    subject: 'Post',
    conditions: { published: true }
  }
]

you can pass it directly into the Ability constructor as follows:

  const defineAbilityFor = (permissions: (SubjectRawRule<any, any, MongoQuery<AnyObject>>)[]) => {
    return createMongoAbility<[Actions, Subjects]>(permissions);
  }

  export default defineAbilityFor;

Using JSON to define rules also has the added advantage of reducing your app's bundle size since you don't need to include heavy dependencies like AbilityBuilder!

Step 3: Create ability instance for the user

After successful authentication by your Login or Authentication service, you’ll fetch the user data or associated permissions (depending on the approach you choose in step 2) to your app and create an ability instance in your login component (or similar) as follows:

// login.tsx

import defineAbiltyFor from './config/defineAbilities.js'

const LoginComponent = () => {
    // Get user data from API. Then,
    const ability = defineAbilityFor(user)
}

Step 4: Provide ability instance to the entire app

Contexts are used in React to share data across components without having to pass props through the component tree. Add the below code in a can.ts file:

// can.ts

import {createContext} from 'react'
import {createContextualCan} from '@casl/react'

export const AbilityContext = createContext()
export const Can = createContextualCan(AbilityContext.Consumer)

This creates a Can component, which you will use in the next step to determine if a user has permissions to perform an action, based on the abilities passed through AbilityContext.

Next, use the above AbilityContext to wrap your App component and set the ability instance created in step 3 as the value, so that the abilities are available to all the components in the application.

ReactDOM.render(
<AbilityContext.Provider value={ability}>
  <App />
</AbilityContext.Provider>,
  document.getElementById('root')
)

Step 5: Check user permission using abilities

There are two ways to determine if a user has permission to perform an action: using ability.can for programmatic checks and using the Can component for conditional rendering.

Assume this is your post object:

// post.ts

export interface Post {
    ownerId: string;
    category: string;
    title: string;
    description: string;
    status: string;
}
const post: Post = {
    ownerId: 'yourUserName',
    category: 'Lifestyle',
    title: 'My First Post',
    description: 'This is the description for the first post.',
    status: 'published'
};

Both ability.can and the Can component take action, subject, and an optional field and check these parameters against the defined abilities.

// user-profile.tsx

import { useAbility } from '@casl/react';
import { subject } from '@casl/ability';
import { AbilityContext, Can } from '../config/can';
// other imports

export default const UserProfile = () => {
  const ability = useAbility(AbilityContext);

  const canCreatePost = ability.can('create', 'Post'); //==== Example (1) ====
  const canDeletePost = ability.can('delete', post); //==== Example (2) ====

  return (
    <div>
      <h1>User Profile</h1>

      {/* ==== Example (3) ==== */}
      <Can I="delete" a="Post">
        <p>You can delete a Post.</p>
      </Can>

      {/* ==== Example (4) ==== */}
      <Can I="delete" this={subject('Post', post)}>
        {(allowed) =>
          allowed ? <button disabled={!allowed}>Delete Post</button> 
          : <p>Cannot delete post.</p>
        }
      </Can>
    </div>
  );
}

See how readable the permission check is?

Now look at the four examples.

Example (1) returns true because user can create posts.

Example (2) should return true because you can delete your published posts, but it returns false. Why? Because even though post is an instance of Post, CASL cannot detect its subject type (type of post object) as CASL uses object.constructor.modelName or object.constructor.name for subject type detection.

You have two ways to fix this.

• Use a subject helper to specify the type of post instance as shown in example (4) (it returns true)

• Use a custom subject type detection algorithm to state which property CASL needs to use to discern the type. This can be done using detectSubjectType like this:

    // defineAbilities.ts
  
    export default function defineAbilityFor(user: User) {
      const { can, cannot, build } = new AbilityBuilder(createAppAbility);
      // rules defined as explained above
  
      return build({
        detectSubjectType: object => object.__typename
      });
    }
  
     // post.ts
  
     const post: Post = {
        ownerId: 'yourUserName',
        category: 'Lifestyle',
        title: 'My First Post',
        description: 'This is the description for the first post.',
        status: 'published',
        __typename: 'Post'
    };
  

Now, example (2) should return true.

Next, look at example (3). It also returns true because the check is on subject type and not on the subject. Remember, when you check on a

• subject, you ask "can I delete THIS post?"

• subject type, you ask "can I delete SOME article?" (that is, at least one post) (Source)

While CASL offers a powerful approach to granular access control, it doesn’t directly address our requirement to apply conditions based on user attributes.

Although third-party libraries can provide convenience, their documentation is sometimes unclear, outdated, or inaccurate, and there may be vulnerabilities within the components themselves. For complete control over your security processes, implementing custom authorization logic may be necessary.

2: Build Your Custom Permissions Validation Framework

To build a custom validation framework, let’s look into how the policies are defined, validated, and enforced and see how all these pieces come together.

Policy Definition using Policy as Code

You have already learned that your access control policies should reside in the back-end. For the custom implementation, you will be using Policy as Code or PaC. This refers to the practice of defining and managing policies using code or configuration files (like YAML, JSON or DSL) rather than manual processes or documentation. This allows policies to be version-controlled, automatically enforced, and more reliable in dynamic environments. These policies are authored by the security admin and are managed by a Policy Service.

In YAML, your policy may look like this, where the policies list is represented by a sequence (-).

policies:
  - policyId: P001
    resource: Post
    action: view
    effect: allow
    conditions: '(resource.tag != "exclusive") || (resource.tag == "exclusive" && user.role == "premium user")'
  - policyId: P002
    resource: Post
    action: edit
    effect: allow
    conditions: 'resource.ownerId == user.id'
  # other policies

The policyId is a unique identifier for the policy. The resource specifies the type of resource the policy applies to, such as "Post." The action defines what operation is allowed or denied on the resource, like "edit." The effect determines whether the action is allowed or denied, with values like "allow" or "deny." The conditions represent the logical expression that must be satisfied for the policy to apply, such as checking if the resource's owner ID matches the user's ID.

As you can see, the conditions in the policies are in a TypeScript-like, human-readable format. This is because they are written using Google's Common Expression Language (CEL).

CEL is an open-source, platform-independent language that is fast and safe for executing user-defined expressions (unlike eval(), especially on the server-side). Its performance is enhanced because CEL is compiled once into an abstract syntax tree, which is then used to evaluate against multiple inputs in nanoseconds or microseconds.

Let’s redefine the structure as follows:

policies:
  Post:
    view:
      policyId: P001
      resource: Post
      action: view
      effect: allow
      conditions: '(resource.tag != "exclusive") || (resource.tag == "exclusive" && user.role == "premium user")'
    edit:
      policyId: P002
      resource: Post
      action: edit
      effect: allow
      conditions: 'resource.ownerId == user.id'
    publish:
      policyId: P003
      resource: Post
      action: publish
      effect: allow
      conditions: 'user.role == "publisher" && resource.category in ["Tech", "Lifestyle"] && resource.status == "approved" && system.time >= "09:00:00" && system.time <= "18:00:00"'

  Comment:
    create:
      policyId: C001
      resource: Comment
      action: create
      effect: deny
      conditions: 'user.role == "guest"'
    edit:
      policyId: C002
      resource: Comment
      action: edit
      effect: allow
      conditions: 'resource.authorId == user.id'
    delete:
      policyId: C003
      resource: Comment
      action: delete
      effect: allow
      conditions: 'resource.authorId == user.id || user.role in ["moderator", "admin"]'
  # other policies

Here’s why:

1. Improved Structure: By grouping policies by resource and action, you make it much easier to navigate. Adding new policies or actions becomes a breeze, without disrupting the overall setup. For example, if you need to add an archive action for the Post resource, you simply add it under the Post object. This modular approach makes maintaining and extending policies much simpler.

2. Efficient Lookup: When these policies are accessed in your app as JavaScript objects, lookups are efficient and constant in time (O(1)). This is because policies are stored using direct key lookups, where each policy can be accessed instantly by its unique key. This significantly boosts performance compared to searching through a list (which would take O(n) time). As the number of policies grows, your lookup time stays the same, so performance doesn't slow down.

3. Easier Auditing & Version Control: This structure also makes auditing and version control much smoother. You can easily track changes to policies and manage updates without the risk of accidentally disrupting other policies.

Workflow Overview

When the application starts, you fetch policies from the Policy Service using RTK Queries, which automatically caches them in your RTK cache. Once the user is authenticated, their data—like role and department—will also be stored in the cache.

To persist this data for the duration of the session, you'll need to store it in session storage, but be mindful to avoid storing sensitive information. For the purposes of our permission validator, we'll read user data directly from the cache.

At points where policy enforcement is needed, such as in components or routes (let’s call these policy enforcement points), the application will call our custom permission hook. This hook then validates permissions based on the policies, the user, the resource, and the environment attributes to either grant or deny access to the requested action.

Policy Validation

Step 1: Create a permission validator

Begin by defining the types for Action, Resource, and Policy in your code:

// validator.type.ts

export type Action = "view" | "edit" | "create" | "approve" | "publish" | "delete";
export type Resource = Partial<Post> | Partial<User> | Partial<Comment>;

export type PolicyEffect = "allow" | "deny"

export interface Policy {
  policyId: string;
  resource: string;
  action: string;
  effect: PolicyEffect;
  conditions: string;
}

You might be wondering why you need to use Partial here. By using Partial, we’re saying that each field on Post, User, or Comment is not required when performing certain actions. This is particularly useful when you validate create actions, where the object may not be fully formed yet – some fields might still be missing. For example, when creating a new Post, you might only have a title and content, but not the full list of comments or tags.

Then, install cel-js, a CEL evaluator for JavaScript to be used in your validator.

npm i cel-js

Create a validatePermission function to pull the action rules for the given resource from the provided policies object and build a context that includes the user, resource, and system information. Note that you may have to use __typename (or similar) for resource type detection, similar to what you did in CASL.

Using the cel-js library, evaluate the conditions specified in the action rules, which will check if the user meets the required criteria for the action. If the conditions are satisfied, the policy "takes effect," meaning the specified action is enforced according to the defined effect – whether allowing or denying the action. If there are no rules defined or an error occurred during evaluation, deny by default.

// validator.ts

import * as cel from 'cel-js';
// other imports

export const validatePermission = (
  action: Action,  
  resource: Resource,  
  system: System, 
  user: User,
  policies: { [resourceKey: string]: { [actionKey: string]: Policy } }
): boolean => {

  const actionRules = policies[resource.__typename]?.[action];
  if (!actionRules) return false; 

  try {
    const context = {
      user: user,  
      resource: resource,  
      system: system,  
    };

    return cel.evaluate(actionRules.conditions, context) && actionRules.effect === "allow";

  } catch (error) {
    console.error('Error evaluating permission condition:', error);
    return false;
  }
};

Any component that needs to validate a user’s permission for an action requires fetching policies from the cache and retrieving the user from the global state, while also managing loading and error states.

To avoid this code duplication and encapsulate the logic for the above operations, you can create a custom hook that provides a consistent interface for permission validation across components.

Step 2: Create a custom hook to encapsulate reusable logic

Since the policies were already fetched from the policy management service during app startup, the same RTK Query will now retrieve them directly from the cache. Follow the below reference to create a usePermission custom hook.

Notice how the skip: !userId condition is used to ensure that the policies are only fetched if a valid userId is present, preventing unnecessary network requests.

// usePermission.ts

import { useSelector } from 'react-redux';
import { useGetPoliciesQuery } from './services/api'; 
import { validatePermission } from './validator';
// other imports

export const usePermission = (action: Action, resource: Resource, system: System): boolean => {

  const user = useSelector((state: any) => state.user); 

  const { data: policies, isLoading: isPoliciesLoading, isError: isPoliciesError } = useGetPoliciesQuery({
    skip: !userId,
  });

  if (isPoliciesError || !policies) {
    console.error('Failed to fetch policies');
    return false;
  }

  const hasPermission = validatePermission(action, resource, system, user, policies);

  return hasPermission;
};

Step 3: Add contextual action validation

More often than not, even if a user has the required permission to perform an action, they still might not be allowed to do so because of contextual business logic. For example:

• Post approval: An editor may have permission to approve a post, but if they’re in the middle of editing it and there are unsaved changes, the approve button should be hidden.

• Commenting: The comment button should be disabled if a user hasn’t typed anything, even if they have permission to comment.

• Category creation: A user with permission might still be blocked from creating a category if the name is empty or already exists.

These rules depend on the current state of the application and need to be handled dynamically. To handle these contextual actions, the validation rules should be defined based on the current state of the application (for example, the post being edited, content being typed, category name availability).

Before delving into how custom hooks can handle these validations, let’s first lay out the rules for these contextual actions:

// contextualRules.ts

import _ from 'lodash';
// other imports

const contextualActionRules = {
  Post: {
    approve: (state: PostState, resource: Resource) => {
      // Prevent approval if the post is currently being edited
      const postId = resource?.id;
      return postId && !state[postId]?.isEditing;
    },
  },
  Comment: {
    create: (state: CommentState, resource: Resource) => {
      // Prevent creating a comment if the comment content is empty
      return !_.isEmpty(resource?.content);
    },
  },
  Category: {
    create: (state: CategoryState[], resource: Resource) => {
      // Prevent creating a category if the name is empty or already exists
      const categoryName = resource.name?.trim();
      return (
        !_.isEmpty(categoryName) &&
        !state.some(category => category.name === categoryName)
      );
    },
  },
};

Now, update the usePermission hook to incorporate checks for contextualActionRules. If a contextual rule is defined for the specified resource and action, it will be evaluated alongside the policy-based permission using the current application state. If no contextual rule is found, the hook will return the result based solely on the policy-based permission.

// usePermission.ts

export const usePermission = (action: Action, resource: Resource, system: System): boolean => {

  const state = useSelector((state: RootState) => state);

  /**
    This part of the code is same as above
  **/ 

  const hasPermission = validatePermission(action, resource, system, user, policies);
  const validateContextualRule = contextualActionRules[resource?.__typename]?.[action];

  if (validateContextualRule) {
    const contextualActionAllowed = validateContextualRule(state, resource);
    return hasPermission && contextualActionAllowed;
  }

  return hasPermission;
};

There is one thing that most definitely needs to be changed in the above code. Take a guess?

How is usePermission beneficial for contextual validations based on the app state? Because the hook is subscribed to the application state! So, when something changes – like typing into a comment box – the hook re-renders. Since the Comment component relies on this hook to control the comment button’s state, any update in the hook also triggers a re-render of the component. This means that as you type, the button becomes visible, and if the content is cleared, the button gets disabled.

But, we don’t want the usePermission hook to re-render every time the app state changes. Let’s fix that.

Define resourceToStateMap outside the usePermission hook to avoid redundant re-creation for every call. useSelector subscribes only to the relevant slice of state based on the resource type and ID.

// Bad practice: Instead of this,
const state = useSelector((state: RootState) => state);

// Good practice: Do this
const resourceToStateMap: Record<string, (state: RootState, id: string | number) => any> = {
  Post:     (state, id) => state.posts[id],
  Comment:  (state, id) => state.comments[id],
  User:     (state, id) => state.user,
  // Add more 
};

const resourceType = resource?.__typename;
const resourceId = resource?.id;
const stateSlice = useSelector((state: RootState) => {
  if (resourceType && resourceId && resourceToStateMap[resourceType]) {
    return resourceToStateMap[resourceType](state, resourceId);
  }

  return null;
});

This is why it’s important to make selectors as granular as possible.

• Avoid over-fetching: You’re not selecting the entire state anymore, just the piece of it that’s necessary for evaluating the permission and contextual rules. This is much more efficient, especially in large applications.

• Optimized re-renders: With granular state selection, only the relevant state slice will trigger a re-render, improving the performance of the application, especially when many components are using the usePermission hook.

Now that you’ve completed the bulk of the permission validation logic, let’s make it prettier to use.

Step 4: Create a wrapper for conditional rendering

Create a Can component that checks if the user has permission to perform a specific action on a resource using the usePermission hook. If permission is granted, it renders the children or calls it as a function with the permission status (this will be used to disable buttons). If not, it displays a fallback element.

// Can.tsx

import { usePermission } from '../hooks/usePermission';

export interface CanProps {
  I: Action;
  a: Resource;
  context: System;
  fallback?: React.ReactNode; 
  children: React.ReactNode | ((allowed: boolean) => React.ReactNode); 
}

const Can: React.FC<CanProps> = ({
  I,
  a,
  context,
  fallback = null,
  children,
}) => {
  const hasPermission = usePermission(I, a, context);

  // If `children` is a function, call it with `hasPermission`
  if (typeof children === 'function') {
    return <>{children(hasPermission)}</>;
  }

  // Otherwise, render children or fallback
  if (hasPermission) {
    return <>{children}</>;
  }

  return <>{fallback}</>;
};

export default Can;

Policy Enforcement

You can use the usePermission hook for programmatic checks and the Can component for conditional rendering.

1. Using Can to hide/show components

<Can
  I="approve"
  a={post}
  context={system}
  fallback={<p>You do not have access to delete a comment.</p>}
>
  <YourComponent />
</Can>

2. Using Can to disable components

<Can
  I="delete"
  a={comment}
  context={system}
>
  {(allowed) => (
     <button onClick={deleteComment} disabled={!allowed}>
       Delete Comment
     </button>
   )}
</Can>

3. Using usePermission to create protected routes

// ProtectedRoute.tsx

import { Navigate, Outlet } from 'react-router-dom'

export function ProtectedRoute() {
  const hasPermission = usePermission("view", user, context);

  return hasPermission ? <Outlet /> : <Navigate to='/login' />
}

// Route set-up
<Route element={<ProtectedRoute />}>
  <Route path='/' element={<Admin />} />
</Route>

4. Using usePermission to skip API calls

const hasPermission = usePermission("view", user, context);

const { data: user, isLoading: isUserLoading, isError: isUserError } = useUserQuery({
    skip: !hasPermission,
});

That's it! Now, let's wrap up with a quick summary.

Let’s Summarize

In this handbook, you learned how to implement scalable access control using both CASL and a custom solution. We started by diving into different access control models, focusing on ABAC, and explored two ways to enforce ABAC-based rules.

With CASL, you saw how easy it is to define user abilities, whether you’re using a shared library or external permissions. We walked through how to set up access control for various user actions, all with clean, readable code. You also learned how to add advanced features like dynamic conditions and field-level access for even more granular control.

On the other hand, you also learned how to build a custom permission framework tailored to your app’s specific needs. You combined contextual state-based checks with policy-based rules, creating a flexible and scalable access control system. Along the way, you explored concepts like Policy as Code, CEL (Common Expression Language), custom hooks, caching, and conditional fetching using RTK queries. You also saw how to enforce access control on components, protected routes, and more.

Both approaches share some key benefits:

• Dynamic and scalable: Adding new actions or entities is as simple as updating a single file – no code rewrites required.

• Separation of concerns: Keeps validation logic separate from UI components, which makes your code easier to maintain.

• Readable: You can define permissions using simple, conversational language like "Can I read this post?" or "Can I create a comment?"

• Reusable components: You can reuse wrapper components and hooks across your app to reduce duplication.

• State reactivity: Works seamlessly with React state, ensuring that your access control rules are reflected dynamically in your UI.

Further Scaling Considerations

If your policy payload is cumbersome or validation logic is computationally expensive, consider the following optimizations:

• Memoize the output: Use useMemo to cache the result of expensive computations, but be mindful that useMemo itself can be costly if overused.

• Modularize policies: Break down your policies into separate files based on their domain. Fetch only the essential policies at startup and lazy load non-essential ones on demand.

• Offload validation to the backend: Move policy validation logic to the backend and consider server-side rendering. But, keep in mind that some dynamic checks still need to occur on the frontend.

Don’t forget to implement access control on the back-end too and make sure to filter-out sensitive data before sending it to the client!

Conclusion

Whether you choose CASL for its simplicity and power or implement your own custom solution for more flexibility, you now have the tools and knowledge to integrate access control into your React applications, ensuring your users can only access what they’re authorized to.

If you enjoyed reading this (or even if you didn’t ;)), drop me a message on LinkedIn with your feedback.

Happy coding, and may your app's permissions be as scalable as your user base!