Basic ReBAC

How Basic ReBAC Works

Basic rebac evaluates a request by looking at the relationship between the requesting subject and the target resource. Instead of asking only “who are you?” or “what role do you have?”, it asks whether a specific link, such as owner, manager, member, approver, or delegate, exists in the access graph.

This makes ReBAC especially useful when access naturally follows business relationships rather than fixed job titles. A person may be allowed to view one record because they own it, another because they manage the account holder, and a third because they are part of the same project team.

Why ReBAC Often Sits Beside IAM and RBAC

Basic ReBAC is usually not a replacement for IAM, RBAC, or ABAC. It is more often a complementary authorization layer that helps express exceptions and real-world connections that roles alone handle poorly. IAM and IGA Basics is a useful reference for understanding how access governance, entitlement review, and relationship-driven permissions fit into broader identity control.

RBAC is efficient when access is tied to stable job functions, while ReBAC is better when access depends on the relationship between two entities. ABAC can add attributes such as region, device trust, or clearance, but ReBAC adds the graph link itself as a first-class decision factor.

Where Basic ReBAC Is a Good Fit

Basic ReBAC works well in systems where access is naturally relational: family accounts, healthcare portals, shared documents, case management tools, collaboration platforms, partner portals, and internal admin workflows. A user may need access because they created an object, were assigned to it, were invited to it, or are linked to it through an organisational chain.

This model is also useful for machine and service relationships when the access decision depends on ownership, delegation, or membership in a controlled graph. The core idea is simple: if the relationship exists, access can be granted; if it does not, access should fail closed.

How Basic ReBAC Changes Authorization Decisions

ReBAC shifts authorization from static identity labels toward contextual relationships. That improves flexibility, but it also means the quality of the relationship graph becomes part of the security model. If ownership, reporting lines, group membership, or delegation links are inaccurate, access decisions can become too broad or too narrow.

For that reason, Basic ReBAC is strongest when the relationship source is authoritative and updated quickly. In practice, the access decision is only as trustworthy as the underlying graph, the rules that interpret it, and the lifecycle process that removes stale links when people move, leave, or change responsibility.

Risk and Threat Considerations

Basic ReBAC can fail when relationship data is stale, overly permissive, or easy to tamper with. If an attacker can alter ownership, membership, or delegation links, they may gain access that looks legitimate because it is granted through an expected business relationship rather than an obvious privilege escalation.

Failure mechanism: Weak graph governance, delayed revocation, or overly broad relationship rules can let unwanted access persist after the real-world relationship has ended.

Impact: The result can be unauthorized data exposure, unintended administrative reach, and harder-to-detect abuse because the access path appears consistent with normal business relationships.

Practitioner Guidance

Governance implication: Treat the relationship source as part of the authorization control, not as a passive data feed. Define who can create, approve, and remove relationship links, and make sure those rules are as carefully governed as roles or entitlements.

What to watch for: Review whether the same object can accumulate too many relationship paths, because graph sprawl can quietly create privilege creep. If a single resource becomes reachable through many loosely controlled links, the model is usually becoming harder to reason about and harder to audit.

Related resources from NHI Mgmt Group

• What is the difference between basic identity management and identity maturity?
• How should security teams choose between basic, predefined, and custom GCP IAM roles?
• What breaks when multi-tenancy is added on top of a basic auth library?
• Why do basic authentication frameworks fall short for B2B SaaS identity needs?