Glossary

ABAC Engine Glossary

Comprehensive reference of ABAC terminology, concepts, and components.

Core Concepts Architecture Policy Components Evaluation

Core ABAC Concepts

Fundamental concepts and terminology in Attribute-Based Access Control.

ABAC (Attribute-Based Access Control)

An access control model where authorization decisions are based on evaluating attributes of the subject, resource, action, and environment. Unlike RBAC (Role-Based Access Control), ABAC provides fine-grained, dynamic access control by evaluating multiple attributes in combination.

Example: “Allow users from the ‘engineering’ department to read documents classified as ‘internal’ or ‘public’ during business hours.”

Attribute

A characteristic or property of a subject, resource, action, or environment. Attributes are the building blocks of ABAC policies and can be of various types (string, number, boolean, array, etc.).

Subject Attributes

• id, username, email
• role, department, clearanceLevel
• groups, permissions

Resource Attributes

• id, type, classification
• ownerId, department
• status, visibility, tags

Action Attributes

• id (read, write, delete)
• type, category

Environment Attributes

• timestamp, hour, dayOfWeek
• ipAddress, location
• emergencyMode, maintenanceMode

Policy

A rule that defines access control logic. Each policy evaluates to either Permit or Deny based on conditions that check attribute values. Policies can have priorities, targets, obligations, and advice.

interface ABACPolicy {
  id: string;
  version: string;
  effect: 'Permit' | 'Deny';
  condition?: Condition;
  target?: PolicyTarget;
  priority?: number;
  obligations?: Obligation[];
  advice?: Advice[];
  metadata?: PolicyMetadata;
}

Request

A request for authorization containing the subject (who), resource (what), action (how), and environment (when/where) attributes. The ABAC engine evaluates policies against the request to make an access decision.

const request = {
  subject: {
    id: 'user-123',
    role: 'engineer',
    department: 'engineering',
    clearanceLevel: 3
  },
  resource: {
    id: 'doc-456',
    type: 'document',
    classification: 'internal',
    ownerId: 'user-789'
  },
  action: {
    id: 'read'
  },
  environment: {
    timestamp: '2024-01-15T14:30:00Z',
    ipAddress: '192.168.1.100'
  }
};

Decision

The result of policy evaluation. Can be Permit, Deny, or NotApplicable. The decision includes the matched policies, obligations to fulfill, and any advice provided.

Permit

Access is granted based on at least one Permit policy matching.

Deny

Access is denied, either explicitly or by default when no Permit policy matches.

NotApplicable

No policies matched the request.

Architecture Components

Key components of the ABAC architecture based on the XACML reference model.

PDP (Policy Decision Point)

The core component that evaluates authorization requests against policies. The PDP retrieves necessary attributes from PIPs, applies the policies, and returns a decision. In abac-engine, this is the ABACEngine class.

const engine = new ABACEngine({ policies });
const decision = await engine.evaluate(request);

PIP (Policy Information Point)

Provides attribute values to the PDP. PIPs can fetch attributes from databases, APIs, or other sources. They enable dynamic attribute resolution during policy evaluation.

const provider: AttributeProvider = {
  name: 'user-attributes',
  async provide(category, id, attributes) {
    if (category === 'subject') {
      const user = await fetchUser(id);
      return user;
    }
  }
};

const engine = new ABACEngine({
  policies,
  attributeProviders: [provider]
});

PAP (Policy Administration Point)

The interface for creating, updating, and managing policies. In the abac-admin packages, this is provided through the PolicyService and UI components.

PEP (Policy Enforcement Point)

The component that enforces the PDP's decision. Typically implemented as middleware or guards in your application that intercept requests and call the PDP.

async function abacMiddleware(req, res, next) {
  const decision = await engine.evaluate({
    subject: req.user,
    resource: { type: req.path, id: req.params.id },
    action: { id: req.method.toLowerCase() },
    environment: { ip: req.ip }
  });

  if (decision.decision === 'Permit') {
    next();
  } else {
    res.status(403).json({ error: 'Access Denied' });
  }
}

Policy Components

Components that make up ABAC policies.

Effect

The outcome when a policy's condition evaluates to true. Can be either Permit or Deny.

Permit: Grant access when condition is true

Deny: Explicitly deny access when condition is true

Condition

The logic that determines whether a policy matches. Conditions can be comparison operations, logical combinations (AND, OR, NOT), or custom functions.

Comparison

Compare attribute values

equals, notEquals, greaterThan, lessThan, in, contains

Logical

Combine conditions

and, or, not

Function

Custom evaluation logic

function(context) returns boolean

Target

An optional pre-filter that quickly determines if a policy should be evaluated. Targets improve performance by skipping policies that clearly don't apply to a request.

Example: Only evaluate this policy for requests with action.id === ‘read’

Obligation

A required action that must be performed when a policy matches. Obligations are typically used for auditing, logging, notifications, or enforcing additional requirements.

{
  id: 'audit-access',
  type: 'log',
  parameters: {
    action: 'document_access',
    level: 'info',
    message: 'User accessed confidential document'
  }
}

Advice

An optional recommendation that can be provided when a policy matches. Unlike obligations, advice does not have to be followed, but can provide useful information to the application.

Example: “Consider requiring MFA for this action” or “This resource will be archived in 30 days”

Evaluation Concepts

Concepts related to policy evaluation and decision-making.

Combining Algorithm

Determines how multiple policy results are combined into a final decision. Different algorithms prioritize Permit vs Deny differently.

Deny Overrides

Any Deny decision overrides all Permit decisions. Most restrictive.

Permit Overrides

Any Permit decision overrides all Deny decisions. Most permissive.

First Applicable

Returns the decision of the first matching policy (by priority).

Deny Unless Permit

Returns Deny unless at least one policy returns Permit.

Attribute Reference

A pointer to an attribute value in a request. Consists of a category (subject, resource, action, environment) and an attribute key.

// Referencing attributes
AttributeRef.subject('department')
AttributeRef.resource('ownerId')
AttributeRef.action('id')
AttributeRef.environment('timestamp')

Policy Set

A collection of related policies evaluated together. The engine can be configured with multiple policies that are evaluated according to the combining algorithm.

Tenant / Multi-Tenant

A logical grouping of users and resources in a SaaS application. Multi-tenant ABAC ensures that users can only access resources within their tenant by including tenant identifiers in policies.

// Tenant isolation policy
const policy = PolicyBuilder
  .create('tenant-isolation')
  .deny()
  .priority(1000)
  .condition(
    ConditionBuilder.notEquals(
      AttributeRef.subject('tenantId'),
      AttributeRef.resource('tenantId')
    )
  )
  .build();

Quick Reference

Term	Description
ABAC	Attribute-Based Access Control
PDP	Policy Decision Point - Evaluates policies
PEP	Policy Enforcement Point - Enforces decisions
PIP	Policy Information Point - Provides attributes
PAP	Policy Administration Point - Manages policies
XACML	eXtensible Access Control Markup Language
RBAC	Role-Based Access Control (predecessor to ABAC)