ReBAC vs PBAC: should you model relationships or query the right data?
Two ways of answering the same question: is this user allowed, here and now?
ReBAC is appealing because it makes authorization readable: Alice belongs to the team that owns this document, so Alice can read it. PBAC starts elsewhere: the decision is computed from context data, at the moment it is requested. The real issue is not picking a side, but understanding which question your application is actually asking.
Reading time: about 7 minutes
What ReBAC does very well
ReBAC (Relationship-Based Access Control) models authorization as a graph: subjects, objects, and the relationships between them. Authorization becomes a path traversal. If Alice is a member of the Product team, the Product team owns the Atlas project, and the document belongs to Atlas, then Alice inherits read access.
It is the right model when the authorization data is the structure itself: document sharing, collaborative workspaces, folder trees, organization hierarchies, multi-tenant SaaS products where users invite other users. ReBAC also excels at a question that is hard to answer otherwise: “list every document Alice can access”.
- Alicemembre de
- Équipe Financepropriétaire de
- Projet Budgetcontient
- Document Prévisions
Where ReBAC is the right answer
- Collaborative sharing between end users (invitations, folder inheritance).
- Multi-tenant SaaS where organization membership structures every right.
- Reverse lookup needs: enumerating the resources a subject can reach.
- Deep hierarchies where rights naturally propagate from parent to child.
Where relationship modelling hits its limits
Trouble starts when the decision no longer depends only on who is connected to what, but on circumstances. An external consultant may read their client's files, except the confidential ones, except outside business hours, except from a non-compliant device, except when the file is under litigation.
None of those conditions is a relationship: they are attributes, usually owned by an external source (HR, CMDB, MDM, a business system). Fitting them into a graph means creating artificial relationships and keeping them in sync. The graph then models the state of the information system rather than its actual relationships.
Warning signs
- Relationship tuples created purely to represent a status or a sensitivity level.
- Synchronization jobs rewriting the graph on every HR or business change.
- Time-based or location-based rules that still require application code.
- A graph growing faster than the number of real resources.
When you start writing relationships that do not describe a relationship, the model is no longer the right one.
What a policy-driven approach changes
PBAC (Policy-Based Access Control) flips the logic. Instead of pre-computing rights into a structure, you write readable policies and evaluate them at request time, with current data. The application queries a decision point, which fetches the attributes it needs from authoritative sources.
The architecture relies on four roles: the PEP intercepts the request inside the application, the PDP evaluates the policy, PIPs provide context attributes, and the PAP is where policies are authored and governed. The direct consequence: business rules stop being scattered across every application's code.
API gateway, application, microservice ou point le plus proche de la ressource
Évalue la politique applicable
- IAG / annuaireidentité, organisation, habilitations
- Application métierownership, relation au client, état de la ressource
- Référentiel de donnéesclassification
- Sécurité / risqueniveau de risque
- Contexteterminal, lieu, heure
- Relationslorsque le cas d'usage le nécessite
What a decision looks like
subject.department = “Legal”
subject.device_compliant = true
resource.sensitivity = “confidential”
resource.case = “litigation-2481”
context.time = 22:14
→ Permit if subject.department == resource.department
and subject.device_compliant
and (resource.sensitivity != “confidential”
or subject.special_clearance)No relationship was created to carry these conditions: they are read at decision time.
The two models are not competitors
In most mature systems, both coexist. The relationship graph remains the best source of truth for who belongs to which organization, which team owns which project, which file inherits from which workspace. Those relationships then become attributes among others, consumed by the policy.
Put differently: ReBAC answers “what is the link?”, PBAC answers “what do we do with that link, given everything else?”. Treating the graph as a PIP rather than as the decision engine keeps it readable, without forcing it to express business rules it was never designed for.
Model the relationships that genuinely exist. Express everything else as policy.
How to decide in your context
The grid below does not crown a winner. It helps you identify what your application really asks of its authorization layer, which remains the best decision criterion.
| Situation | Tendance Ariovis |
|---|---|
| Partage documentaire, workspaces, ownership et hiérarchies au cœur de l'application | ReBAC est très naturel |
| Quelques relations complétées par des critères contextuels simples | ReBAC enrichi peut suffire |
| Décision croisant identité, ressource, métier, contexte, classification et risque | Approche policy-driven privilégiée |
| Plusieurs applications doivent appliquer des règles cohérentes | Externalisation de l'autorisation à étudier |
| Une relation est utile parmi de nombreux autres critères | La relation peut alimenter une politique |
Quand privilégier ReBAC ou une approche policy-driven ?
Partage documentaire, workspaces, ownership et hiérarchies au cœur de l'application
ReBAC est très naturel
Quelques relations complétées par des critères contextuels simples
ReBAC enrichi peut suffire
Décision croisant identité, ressource, métier, contexte, classification et risque
Approche policy-driven privilégiée
Plusieurs applications doivent appliquer des règles cohérentes
Externalisation de l'autorisation à étudier
Une relation est utile parmi de nombreux autres critères
La relation peut alimenter une politique
Frequently asked questions
The questions we hear most often when a team hesitates between the two approaches.
Should an existing ReBAC be replaced by PBAC?
Almost never. If your graph describes real relationships and it works, keep it. The real topic is externalising the contextual conditions you have started hard-coding or simulating with artificial relationships.
Is PBAC slower, since it evaluates in real time?
Latency mostly depends on attribute access, not on the policy engine. A properly deployed PDP, with caching on stable attributes, sustains response times compatible with a synchronous application call.
How do you list accessible resources with PBAC?
That is the hardest exercise for a purely policy-driven approach. It is exactly the case where relying on a relationship graph as an attribute source, or pre-filtering at the data layer, remains the right answer.
Where do we start concretely?
With one application, one decision, and the attributes it genuinely needs. Externalising a single authorization decision teaches a team more than six months of theoretical modelling.
Can you help us choose?
Yes, and it is often a short conversation. In thirty minutes we look at your real use cases and tell you plainly whether the graph is enough, whether a policy is needed, or whether both should coexist.
Our conviction
Choosing between ReBAC and PBAC is not an engine debate. It is a choice about where the business rule lives: inside a data structure you maintain, or inside a policy you govern.
Our position is simple: model the graph for what it actually represents, and take out of the application everything that belongs to context, sensitivity and risk. That is what later lets you change one rule without redeploying six applications.
Let's discuss your authorization model
A thirty-minute conversation is usually enough to clarify whether your need calls for the graph, the policy, or both.