ABAC (Attribute-Based Access Control)

Definition

Traditional access control is pretty simple: you have a role (like “admin” or “editor”), and that role determines what you can do. But what if your access rules are more complex? What if a nurse should only see patient records during their shift, and only for patients in their ward? Or a bank employee can approve loans under $10,000, but only during business hours, and only for their branch? That’s where ABAC comes in.

ABAC (Attribute-Based Access Control) makes access decisions by evaluating multiple attributes about the situation - not just who you are, but also what you’re trying to access, what action you’re taking, and the current context. Instead of simple rules like “admins can edit everything,” ABAC enables rich policies like “users can edit documents if their department matches the document’s department AND they have editor role AND it’s during business hours AND the document isn’t marked confidential unless they have security clearance level 3 or higher.”

Think of ABAC as adding dimensions to your access control. RBAC (Role-Based Access Control) asks “what role do you have?” ABAC asks “what role do you have, AND what department are you in, AND what are you trying to access, AND what are its properties, AND what time is it, AND what’s your location, AND…” It can consider as many attributes as your policy needs, making it incredibly flexible but also more complex to implement and reason about.

Example

Hospital Patient Records: A policy might state: “Medical staff can view patient records if (staff.ward == patient.ward) OR (staff.role == ‘specialist’ AND patient.condition IN staff.specialties) OR (staff.role == ’emergency’ AND current_time is during emergency_shift).” Different staff members see different records based on multiple intersecting criteria.

Financial Document Access: “Employees can approve expense reports if (report.amount < employee.approval_limit) AND (report.submitter.department == employee.managed_departments OR employee.role == ‘finance’) AND (current_time is business_hours OR employee.has_after_hours_access).”

Geographic Content Restrictions: “Users can view content if (content.region == user.country OR content.global_release == true) AND (user.age >= content.minimum_age) AND (user.subscription_level >= content.required_tier).” This is how streaming services like Netflix determine what you can watch.

Government Security Clearance: “Personnel can access documents if (personnel.clearance_level >= document.classification) AND (document.project IN personnel.assigned_projects) AND (personnel.citizenship IN document.allowed_nationalities).”

Multi-Tenant SaaS: “Users can access data if (data.tenant_id == user.tenant_id) AND (user.role IN data.allowed_roles) AND (data.deleted == false OR user.role == ‘admin’).”

Analogy

The Smart Building: Imagine a building where access isn’t just about having a keycard. The security system considers: Who are you (employee, visitor, contractor)? What area are you entering (lobby, lab, executive floor)? What time is it (business hours, after hours, weekend)? What’s your department (R&D can enter labs, HR can enter personnel files room)? What’s your security training status (up to date for hazardous areas)? This multi-factor evaluation is ABAC - the door decides by considering many attributes, not just “is this a valid keycard.”

Airport Security Levels: Getting through an airport involves multiple attribute checks: Your identity (passport verification), your status (passenger, crew, TSA Pre), what you’re accessing (terminal, tarmac, cockpit), current threat level, your citizenship, your ticket class. A pilot can access the cockpit but only on their flight, during their shift, with current medical certification. That’s ABAC in action - many attributes combining to make a decision.

The VIP Club: A sophisticated nightclub doesn’t just have a “VIP list.” The bouncer considers: Is it VIP night (time attribute)? Is the person on the list (user attribute)? Is the VIP section full (resource attribute)? Is there a private event (environmental attribute)? Does their membership tier allow table service (user attribute)? Many factors combine to determine who gets in where.

The Library Study Room: Modern library room booking might check: Are you a student or faculty (user role)? How many hours have you booked this week (usage quota)? Is the room equipped for what you need (resource attributes)? Is it exam period with different rules (environmental context)? Is your library account in good standing (user status)? Multiple attributes, not just “are you registered.”

Code Example

// ABAC Policy Engine Example
const abacPolicy = {
  canEdit: (user, document, context) => {
    // User attributes
    const userDept = user.attributes.department
    const userRole = user.attributes.role

    // [Resource](https://reference.apios.info/terms/resource/) attributes
    const docDept = document.attributes.department
    const docClassification = document.attributes.classification

    // Environment attributes
    const currentHour = context.time.getHours()
    const isBusinessHours = currentHour >= 9 && currentHour <= 17

    // Complex policy evaluation
    return (
      userDept === docDept &&
      userRole === 'editor' &&
      isBusinessHours &&
      (docClassification !== 'confidential' || user.attributes.clearanceLevel >= 3)
    )
  }
}

// Usage in API
app.put('/api/documents/:id', async (req, res) => {
  const user = req.user
  const document = await getDocument(req.params.id)
  const context = { time: new Date() }

  if (!abacPolicy.canEdit(user, document, context)) {
    return res.status(403).json({
      error: 'Access denied',
      reason: 'Policy evaluation failed'
    })
  }

  // Proceed with update
})

Security Notes

Standards & RFCs