Skill Guide

RBAC, ABAC, and ReBAC design for both human and non-human principals

The design of authorization systems that govern access control for both human users and non-human entities (services, applications, APIs) using Role-Based (RBAC), Attribute-Based (ABAC), and Relationship-Based (ReBAC) models.

It is critical for securing modern distributed architectures (microservices, cloud, IoT) and enabling zero-trust security postures. Proper design prevents unauthorized access, reduces breach impact, and ensures compliance while enabling secure interoperability between automated systems.

1 Careers

1 Categories

9.1 Avg Demand

15% Avg AI Risk

How to Learn RBAC, ABAC, and ReBAC design for both human and non-human principals

1. Master core authorization models: RBAC (roles, permissions), ABAC (attributes, policies), ReBAC (relationships, graph traversal). 2. Understand the principal types: human identities (users) vs. non-human identities (NHIs) like service accounts, APIs, and machine identities. 3. Study the principle of least privilege and policy-as-code concepts.

1. Apply models to hybrid scenarios: e.g., designing an ABAC policy that evaluates both a user's department AND a service's API key scope. 2. Integrate with identity providers (IdP) and directory services (LDAP, Azure AD). 3. Avoid common pitfalls like role explosion in RBAC, overly complex ABAC policies, and performance issues in recursive ReBAC checks.

1. Architect cross-domain authorization systems for multi-cloud or partner ecosystems. 2. Design for policy lifecycle management (testing, deployment, auditing) at scale. 3. Implement real-time, context-aware authorization for high-throughput systems (e.g., financial transactions, real-time bidding). 4. Mentor teams on shifting security left via policy-as-code in CI/CD.

Practice Projects

Beginner

Project

Implement a Hybrid RBAC/ABAC System for a Simple API

Scenario

You have an API that serves both human users (via a frontend) and internal services (via service accounts). Define access control for reading/writing user data.

How to Execute

1. Define roles for humans (Admin, Viewer) and a service account role. 2. Write ABAC policies that add conditions, e.g., a Viewer can only read their own data (user_id attribute matches). 3. Use an open-source policy engine like Open Policy Agent (OPA) to enforce the rules. 4. Test with both a user JWT and a service account token.

Intermediate

Case Study/Exercise

Design a ReBAC System for a Multi-Tenant SaaS Platform

Scenario

A SaaS platform where tenants are organizations. Resources (documents, projects) are owned by users within a tenant. Access is based on organizational hierarchy and explicit sharing (e.g., 'editor' relationship).

How to Execute

1. Model the relationship graph: User -> belongs_to -> Org, User -> owner_of -> Doc, Org -> parent_of -> SubOrg. 2. Define permissions using Zanzibar-style tuples (e.g., `doc:123#editor@user:456`). 3. Implement a ReBAC engine (e.g., Google Zanzibar open-source implementations like SpiceDB or Ory Keto). 4. Write authorization checks for scenarios like 'Can user X view doc Y?' and test recursive permission inheritance.

Advanced

Project

Architect a Zero-Trust Authorization Layer for a Microservices Mesh

Scenario

Design an authorization system where every service-to-service call requires fine-grained policy evaluation. Policies must consider the caller's identity (service or user), the target resource, request context (time, location, threat score), and dynamic relationships (e.g., data ownership).

How to Execute

1. Deploy a sidecar authorization service (e.g., using OPA as a sidecar). 2. Define a unified policy language (e.g., Rego) that combines RBAC, ABAC, and ReBAC attributes. 3. Integrate with a centralized identity plane (SPIFFE/SPIRE for non-human identities). 4. Implement policy versioning, rollback, and real-time auditing. 5. Conduct chaos engineering tests to validate policy enforcement under failure.

Tools & Frameworks

Policy Engines & Languages

Open Policy Agent (OPA) / RegoAWS CedarGoogle Zanzibar (SpiceDB, Ory Keto, AuthZed)

Use OPA/Cedar for ABAC-heavy or hybrid policies. Use Zanzibar implementations (SpiceDB, Keto) for large-scale, relationship-driven (ReBAC) systems like social graphs or multi-tenant SaaS.

Identity & Standards

SPIFFE/SPIRE (for NHIs)OAuth 2.0 / OIDCSCIM (User Provisioning)

SPIFFE/SPIRE provides a universal identity for services (NHIs). OAuth/OIDC handle human user authentication and token-based authorization. SCIM automates user lifecycle management.

Architectural Patterns

Policy-as-CodeAuthorization Sidecar PatternAttribute-Based Access Control (ABAC) NIST model

Policy-as-Code (store policies in Git, test in CI/CD) is foundational. The sidecar pattern decouples policy enforcement from business logic. The NIST ABAC model provides a rigorous framework for attribute definition.

Interview Questions

Answer Strategy

Structure the answer around the three models: RBAC for base human/bot roles, ABAC for dynamic conditions (market conditions, risk score), and potentially ReBAC for bot-to-user ownership. Emphasize policy engine selection, real-time evaluation, and fail-safe mechanisms. Sample: 'I'd start with RBAC to define base permissions for Customer and Bot roles. Then, layer ABAC policies using attributes like user_tier, bot_risk_score, and market_volatility_index. For bot-human relationships, a ReBAC model could enforce that a bot can only trade on behalf of its owner. The policy engine would be OPA or Cedar for low-latency evaluation, integrated directly into the trading service's decision point.'

Answer Strategy

Tests debugging and incident response skills in a policy-as-code system. The candidate should show systematic thinking: logs, policy audit, identity verification. Sample: 'First, I'd check the authorization logs from the policy enforcement point (PEP) to see the exact policy decision and the attributes (caller identity, target resource, context) that were evaluated. This would reveal if the service's identity (SPIFFE ID) was incorrect, if the policy was misconfigured, or if a context attribute was missing. I'd then review the policy's Git history for recent changes, revert if necessary, and add a targeted unit test for that specific service-to-service call to prevent regression.'