Attribute‐Based Access Control (ABAC) Authentication & Authorization - sonuprajapati15/Authentication-Authorization GitHub Wiki

System Design: Attribute-Based Access Control (ABAC) Authentication & Authorization

1. Overview

Attribute-Based Access Control (ABAC) is an authorization model that makes access decisions based on user attributes, resource attributes, and environment conditions, instead of just predefined roles.

🔹 Example:

  • A Manager in Finance can approve expenses over $1000.
  • A User from the US can access US-based reports but not EU reports.
  • Access to a sensitive document is only granted during office hours (9 AM - 5 PM).

Why ABAC?

Fine-grained access control → More flexible than RBAC.
Dynamic policies → Access changes based on real-time conditions (location, time, device).
Improved security & compliance → Ensures least privilege access.


2. Functional & Non-Functional Requirements

Functional Requirements

✅ Users authenticate and receive a JWT token with attributes.
✅ Policies enforce access control based on user attributes (e.g., department, seniority), resource attributes (e.g., document sensitivity), and environmental attributes (e.g., time, location, IP).
✅ Admins can define and update attribute-based policies dynamically.
✅ Logging and monitoring of access decisions.

Non-Functional Requirements

Security – Prevent unauthorized access using real-time policy evaluation.
Scalability – Efficiently process millions of attribute-based decisions.
Performance – Optimize attribute checks with caching & indexing.
Compliance – Meet GDPR, HIPAA, ISO27001 security standards.
Flexibility – Allow easy addition of new attributes and policies.


3. High-Level Design (HLD)

Architecture Components

  1. Authentication Server – Handles login, assigns user attributes.
  2. ABAC Policy Engine – Evaluates attribute-based rules before granting access.
  3. Resource Server – Hosts protected resources, validates access requests.
  4. Policy Management System – Allows admins to create/update ABAC policies.
  5. Logging & Monitoring – Tracks all access decisions for auditing.

ABAC Workflow

  1. User logs in → Receives a JWT token with attributes (e.g., { "role": "manager", "department": "finance", "location": "US" }).
  2. Client sends API request → Includes JWT in headers (Authorization: Bearer <token>).
  3. ABAC Middleware extracts attributes → Evaluates user, resource, and environment conditions.
  4. ABAC Policy Engine checks rules → If the user’s attributes match the policy, access is granted.
  5. Access granted or denied → If permitted, request proceeds; otherwise, access is denied.

4. Low-Level Design (LLD)

Database Schema

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    username VARCHAR(255) UNIQUE NOT NULL,
    password_hash TEXT NOT NULL,
    department VARCHAR(50),
    location VARCHAR(100),
    clearance_level INT
);

CREATE TABLE abac_policies ( id SERIAL PRIMARY KEY, resource VARCHAR(255) NOT NULL, attribute VARCHAR(50) NOT NULL, operator VARCHAR(10) CHECK (operator IN ('=', '!=', '>', '<', 'IN')), value TEXT NOT NULL );

Example ABAC Policy Rules

Resource Attribute Operator Value Rule Explanation
/finance-reports department = Finance Only Finance users can access reports
/hr-dashboard clearance_level > 2 Only high-clearance employees can access HR data
/sensitive-data location != China Users from China cannot access sensitive data
/admin role = Admin Only Admins can access the admin panel

6. Diagrams

Here is the ABAC Authorization Flowchart:

ABAC Authorization Flow

View or edit this diagram in Whimsical.


7. Code Implementation (Node.js + Express + JWT + ABAC Policy Engine)

1. Install Dependencies

npm install express bcrypt jsonwebtoken dotenv

2. Setup Express Server with ABAC Middleware

require("dotenv").config();
const express = require("express");
const bcrypt = require("bcrypt");
const jwt = require("jsonwebtoken");

const app = express(); app.use(express.json());

// Mock database with attributes const users = [ { id: 1, username: "admin", passwordHash: bcrypt.hashSync("password", 10), department: "IT", clearance_level: 3 }, { id: 2, username: "manager", passwordHash: bcrypt.hashSync("password", 10), department: "Finance", clearance_level: 2 } ];

// ABAC Policies const abacPolicies = [ { resource: "/finance-reports", attribute: "department", operator: "=", value: "Finance" }, { resource: "/admin", attribute: "clearance_level", operator: ">", value: "2" } ];

// ABAC Middleware const authorize = (resource) => (req, res, next) => { const token = req.headers.authorization?.split(" ")[1]; if (!token) return res.status(401).json({ message: "Unauthorized" });

const user = jwt.verify(token, process.env.JWT_SECRET); const policy = abacPolicies.find(p => p.resource === resource);

if (!policy || user[policy.attribute] !== policy.value) { return res.status(403).json({ message: "Access Denied" }); } next(); };

// Protected Route app.get("/finance-reports", authorize("/finance-reports"), (req, res) => res.json({ message: "Accessing Finance Reports" }));

app.listen(3000, () => console.log("ABAC Server running on port 3000"));



5. Trade-offs & Scalability

Factor Trade-off
Security ABAC is highly secure but requires well-defined policies.
Performance Real-time policy evaluation can slow requests; caching helps.
Flexibility More flexible than RBAC but harder to manage manually.
Scalability Works well at scale but may require policy indexing for large datasets.

8. Conclusion

ABAC provides fine-grained, dynamic access control and is ideal for high-security enterprise systems.

⚠️ **GitHub.com Fallback** ⚠️