Access control for multi-tenant SaaS has quietly split into three competing models, and picking the wrong one shows up as either a security incident or an unmaintainable pile of role definitions. Role-Based Access Control (RBAC) was formalized academically by Ferraiolo and Kuhn at NIST in 1992 and later standardized as ANSI INCITS 359-2004; it's still the default in most admin panels. Attribute-Based Access Control (ABAC) got its own NIST guidance in Special Publication 800-162, "Guide to Attribute Based Access Control (ABAC) Definition and Considerations," first published January 21, 2014 and updated August 2, 2019. The newest entrant, Relationship-Based Access Control (ReBAC), was popularized by Google's 2019 USENIX ATC paper on Zanzibar, the authorization system underpinning Drive, Photos, and YouTube, which reported handling enormous authorization-check volume with strong consistency and sub-10ms latency for the large majority of requests. Each model solves a different shape of problem, and conflating them is how teams end up bolting attribute checks onto a role table or building a permissions graph nobody can audit. This piece breaks down what each model actually does, where it breaks down at scale, and how to decide between them for a multi-tenant cloud product.
What problem does RBAC solve, and where does it break down?
RBAC solves the coarse-grained case: a fixed set of roles (admin, manager, viewer) each carrying a fixed bundle of permissions, assigned to users. It's simple to reason about and simple to audit — a compliance reviewer can list every permission a role has in one query. The failure mode in multi-tenant SaaS is "role explosion": if permissions need to vary per tenant, per project, or per resource owner, teams end up creating tenant-A-admin, tenant-B-admin, project-42-viewer, and so on, multiplying roles faster than the user base grows. RBAC also has no native concept of context — it can't express "only during business hours" or "only if this record belongs to the requesting user" without layering extra logic on top, which is usually where role-based systems quietly grow ABAC-like exceptions bolted onto role checks, undermining the auditability that made RBAC attractive in the first place.
What does ABAC add that RBAC can't express?
ABAC replaces static role membership with a policy evaluated against attributes of the subject, the resource, the action, and the environment — for example, "allow read if user.tenant_id == record.tenant_id AND record.status == 'active' AND request.ip in approved_range." NIST SP 800-162 defines this model explicitly to handle access decisions that depend on runtime context rather than fixed group membership, which is exactly the shape of most real multi-tenant authorization bugs: tenant-isolation failures where a query attribute (tenant ID) was checked inconsistently across endpoints. ABAC is commonly implemented with a dedicated policy engine — XACML historically, or more recently Open Policy Agent (OPA) with its Rego language — so the authorization logic lives in one testable, versioned place instead of scattered if statements. The tradeoff is complexity: a large attribute-and-policy set becomes hard to reason about, and conflicting rules can produce access decisions that are correct on paper but surprising in practice, which is why policy testing and simulation matter as much as the policies themselves.
What is ReBAC, and why did Google build Zanzibar around it?
ReBAC computes permissions by walking a graph of relationship tuples — subject, relation, object — rather than checking a role or evaluating a policy expression. A typical tuple looks like "user:alice is editor of folder:reports," and a document inside that folder inherits "editor" access by walking the parent relationship, without a separate ACL entry per document. Google described this exact design in its 2019 USENIX ATC paper on Zanzibar, built to unify authorization across Drive, Photos, Calendar, and YouTube, where sharing structures are inherently hierarchical and nested. The paper's headline result — very high query volume served with strong consistency and sub-10ms latency for the large majority of checks — is what convinced the industry ReBAC could scale past its academic origins. Open-source implementations following the same tuple-and-graph model include SpiceDB, Ory Keto, and OpenFGA, all of which let application teams model "member of," "parent of," and "owner of" relationships directly instead of encoding them as ad hoc foreign-key checks in application code.
When should a multi-tenant SaaS product choose ReBAC over ABAC or RBAC?
ReBAC is the right fit when permissions genuinely follow a graph — nested folders, org charts, project hierarchies, or any structure where "can I access X" depends on walking a chain of "is this a child of Y" relationships. Modeling that in RBAC means a role per node in the hierarchy; modeling it in ABAC means encoding graph traversal into policy attributes, which policy engines handle awkwardly. The cost of ReBAC is operational: you're now running (or depending on) a relationship-tuple store and rewriting authorization logic as graph queries, which is a bigger lift than adding a role check. Teams without genuinely nested sharing structures — most B2B SaaS admin consoles, for instance — usually don't need it. ReBAC earns its complexity specifically in collaboration products where users share folders with other users who share subfolders with teams, the exact pattern Zanzibar was built to serve at Google's scale.
Can these models be combined in one multi-tenant application?
Yes, and in practice most mature multi-tenant products end up layering more than one model rather than picking a single one. A common pattern is RBAC for the coarse tenant-level tier (admin/manager/viewer, cheap to audit), ABAC for cross-cutting context rules that apply regardless of role (tenant isolation, data classification, time-of-day restrictions), and ReBAC only for the specific subset of resources with genuine sharing hierarchies, such as a "share this project with another team" feature. The risk in combining models is inconsistency: if tenant isolation is enforced via an ABAC-style attribute check on some endpoints but only implicitly assumed on others, that gap is exactly the kind of broken object-level authorization pattern that OWASP's API Security Top 10 has flagged as a leading real-world API vulnerability class for consecutive editions. Whichever combination a team chooses, the authorization decision should be centralized and independently testable rather than re-implemented per endpoint, because that duplication is where multi-tenant isolation bugs actually originate.
How does this compare to what Safeguard's own Portal implements today?
Safeguard's Portal application currently uses a straightforward RBAC model: four built-in roles (Admin, Manager, Contributor, Viewer) plus custom roles built from fixed permission strings like products.edit and sboms.upload, documented in Portal's user-roles reference. That's a deliberate fit for Portal's shape of problem — a bounded set of SBOM- and product-management actions where role-based auditability matters more than fine-grained per-record policy evaluation. It's also a useful illustration of the broader point: RBAC is the right default for coarse, relatively static permission sets, and reaching for ABAC or ReBAC should be driven by an actual requirement — cross-cutting contextual rules or nested sharing graphs — rather than novelty. Teams evaluating their own multi-tenant authorization architecture should audit which of these three problem shapes they actually have before picking a model to solve it.