ReBAC vs PBAC : faut-il modéliser les relations ou interroger les bonnes données ?
Deux façons de répondre à la même question : cet utilisateur a-t-il le droit, ici et maintenant ?
Le ReBAC séduit parce qu'il rend l'autorisation lisible : Alice appartient à l'équipe qui possède ce document, donc Alice peut le lire. Le PBAC part d'un autre angle : la décision est calculée à partir des données de contexte, au moment où elle est demandée. Le vrai sujet n'est pas de choisir un camp, mais de savoir quelle question votre application pose réellement.
Lecture : environ 7 minutes
Ce que le ReBAC fait très bien
Le ReBAC (Relationship-Based Access Control) modélise l'autorisation comme un graphe : des sujets, des objets, et des relations entre eux. L'autorisation devient un parcours de chemin dans ce graphe. Si Alice est membre de l'équipe Produit, que l'équipe Produit est propriétaire du projet Atlas, et que le document appartient au projet Atlas, alors Alice hérite d'un droit de lecture.
C'est le bon modèle quand la donnée d'autorisation est la structure elle-même : partage de documents, espaces collaboratifs, arborescences de dossiers, hiérarchies d'organisations, produits SaaS multi-tenants où l'utilisateur invite d'autres utilisateurs. Le ReBAC excelle aussi sur une question difficile à traiter autrement : « liste-moi tous les documents auxquels Alice a accès ».
- Alicemembre de
- Équipe Financepropriétaire de
- Projet Budgetcontient
- Document Prévisions
Les cas où le ReBAC est la bonne réponse
- Partage collaboratif entre utilisateurs finaux (invitations, héritage de dossiers).
- Multi-tenant SaaS où l'appartenance à une organisation structure tous les droits.
- Besoins de « reverse lookup » : énumérer les ressources accessibles à un sujet.
- Hiérarchies profondes où les droits se propagent naturellement de parent à enfant.
Là où la modélisation par relations atteint ses limites
Le problème arrive quand la décision ne dépend plus seulement de qui est relié à quoi, mais de circonstances. Un consultant externe peut lire les dossiers de son client, sauf ceux classés confidentiels, sauf en dehors des heures ouvrées, sauf depuis un poste non conforme, sauf si le dossier est en phase de contentieux.
Chacune de ces conditions n'est pas une relation : c'est un attribut, souvent porté par une source externe (RH, CMDB, MDM, base métier). Pour les intégrer dans un graphe, il faut créer des relations artificielles et les maintenir synchronisées. Le graphe se met alors à modéliser l'état du système d'information plutôt que ses relations réelles.
Les signaux d'alerte
- Des tuples de relation créés uniquement pour représenter un statut ou un niveau de sensibilité.
- Des jobs de synchronisation qui réécrivent le graphe à chaque changement RH ou métier.
- Des règles temporelles ou géographiques impossibles à exprimer sans code applicatif complémentaire.
- Un graphe qui grossit plus vite que le nombre de ressources réelles.
Quand vous commencez à écrire des relations qui ne décrivent pas une relation, c'est que le modèle n'est plus le bon.
Ce que change une approche policy-driven
Le PBAC (Policy-Based Access Control) inverse la logique. Au lieu de pré-calculer les droits dans une structure, on écrit des politiques lisibles, et on les évalue au moment de la demande, avec les données du moment. L'application interroge un point de décision, qui va chercher les attributs nécessaires auprès des sources qui font autorité.
L'architecture repose sur quatre rôles : le PEP intercepte la demande dans l'application, le PDP évalue la politique, les PIP fournissent les attributs de contexte, et le PAP sert à écrire et gouverner les politiques. Cette séparation a une conséquence directe : la règle métier cesse d'être dispersée dans le code de chaque application.
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
À quoi ressemble une décision
sujet.direction = « Juridique »
sujet.poste_conforme = vrai
ressource.sensibilite = « confidentiel »
ressource.dossier = « contentieux-2481 »
contexte.heure = 22h14
→ Permit si sujet.direction == ressource.direction
et sujet.poste_conforme
et (ressource.sensibilite != « confidentiel »
ou sujet.habilitation_speciale)Aucune relation n'a été créée pour porter ces conditions : elles sont lues au moment de la décision.
Les deux modèles ne sont pas concurrents
Dans la plupart des systèmes matures, les deux cohabitent. Le graphe de relations reste la meilleure source de vérité pour dire qui appartient à quelle organisation, quelle équipe possède quel projet, quel dossier hérite de quel espace. Ces relations deviennent alors des attributs parmi d'autres, consommés par la politique.
Autrement dit : le ReBAC répond à « quel est le lien ? », le PBAC répond à « que fait-on de ce lien, compte tenu du reste ? ». Traiter le graphe comme un PIP plutôt que comme le moteur de décision permet de garder sa lisibilité sans lui faire porter des règles métiers qu'il n'est pas conçu pour exprimer.
Modélisez les relations qui existent réellement. Exprimez tout le reste en politique.
Comment trancher pour votre contexte
La grille ci-dessous ne désigne pas un gagnant. Elle vous aide à identifier ce que votre application demande réellement à son autorisation, ce qui reste le meilleur critère de choix.
| 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
Questions fréquentes
Les questions que l'on nous pose le plus souvent quand une équipe hésite entre les deux approches.
Faut-il remplacer un ReBAC existant par du PBAC ?
Presque jamais. Si votre graphe décrit des relations réelles et qu'il fonctionne, gardez-le. Le sujet est plutôt d'externaliser les conditions contextuelles que vous avez commencé à coder en dur ou à simuler par des relations artificielles.
Le PBAC est-il plus lent, puisqu'il évalue en temps réel ?
La latence dépend surtout de l'accès aux attributs, pas du moteur de politique. Un PDP correctement déployé, avec du cache sur les attributs stables, tient des temps de réponse compatibles avec un appel applicatif synchrone.
Comment lister les ressources accessibles avec du PBAC ?
C'est l'exercice le plus difficile pour une approche purement policy-driven. C'est précisément un cas où s'appuyer sur un graphe de relations comme source d'attributs, ou pré-filtrer côté données, reste la bonne réponse.
Par où commencer concrètement ?
Par une application, une décision, et les attributs dont elle a réellement besoin. Externaliser une seule décision d'autorisation apprend plus à une équipe que six mois de modélisation théorique.
Vous pouvez nous aider à choisir ?
Oui, et c'est souvent une conversation courte. En trente minutes, nous regardons vos cas d'usage réels et nous vous disons franchement si le graphe suffit, si une politique s'impose, ou si les deux doivent cohabiter.
Notre conviction
Le choix ReBAC ou PBAC n'est pas un débat de moteurs. C'est un choix sur l'endroit où vit la règle métier : dans une structure de données que l'on maintient, ou dans une politique que l'on gouverne.
Notre position est simple : modélisez le graphe pour ce qu'il représente réellement, et sortez de l'application tout ce qui relève du contexte, de la sensibilité et du risque. C'est ce qui permet, plus tard, de changer une règle sans redéployer six applications.
Discutons de votre modèle d'autorisation
Une conversation de trente minutes suffit souvent à clarifier si votre besoin relève du graphe, de la politique, ou des deux.