Authorization: RBAC vs ABAC

Moving from rigid roles to dynamic, context-aware attributes.

The idea

RBAC (Role-Based Access Control) grants permissions based on static roles (e.g., "Is an Admin"). But what if you only want Admins to delete files during business hours? RBAC fails here. ABAC (Attribute-Based Access Control) solves this by evaluating dynamic attributes of the User (e.g. title), the Resource (e.g. classification), and the Environment (e.g. time of day).

Step 1: Alice wants to view a document.

How it works

ABAC uses a policy engine that evaluates a boolean rule based on the combined context.

# RBAC (Static)
def rbac_can_view(user):
    return "manager" in user.roles

# ABAC (Dynamic and Context-Aware)
def abac_can_view(user, document, request_context):
    # Rule: Managers can view classified docs, but ONLY from the office IP
    if document.classification == "Top Secret":
        if user.title == "Manager" and request_context.ip.startswith("10.0."):
            return True
        return False
        
    # Rule: Anyone can view public docs
    if document.classification == "Public":
        return True
        
    return False

Cost

ABAC is incredibly flexible but computationally expensive. Checking user.role == 'admin' is an O(1) memory lookup. Evaluating an ABAC policy might require fetching the document metadata from the DB, looking up the user's IP reputation, and parsing a complex JSON ruleset on every single request.

Watch out for