Skip to Content

Fine-Grained Authorization (Modèle Zanzibar)

Le Role-Based Access Control (RBAC) est suffisant pour de nombreuses applications : les utilisateurs ont des rôles, les rôles ont des permissions, on vérifie si un utilisateur a la bonne permission. Mais RBAC ne suffit pas quand on a besoin d’un contrôle d’accès au niveau ressource — “Alice peut modifier le document 42, mais pas le 43”, ou “Bob peut voir tous les documents de son équipe.”

Auris implémente un moteur FGA compatible Zanzibar (Fine-Grained Authorization) pour gérer ces scénarios.

Qu’est-ce que Zanzibar ?

Zanzibar est le système d’autorisation global de Google, publié dans un paper de recherche en 2019. Il gère le contrôle d’accès pour Gmail, Drive, Docs, Maps et des dizaines d’autres produits Google — traitant des trillions de vérifications d’autorisation par seconde avec une latence milliseconde.

L’intuition centrale de Zanzibar est de modéliser l’autorisation comme des relations entre objets et sujets, stockées comme des tuples. Les questions d’autorisation deviennent des problèmes de traversée de graphe : “Existe-t-il un chemin du sujet user:alice vers l’objet document:readme via la relation viewer ?”

Auris implémente un moteur FGA compatible Zanzibar avec :

  • Un DSL compatible OpenFGA pour définir les modèles d’autorisation
  • Un tuple store sur PostgreSQL (via Prisma)
  • Un algorithme de vérification récursif avec détection de cycles
  • Opérations de requête Expand et list-objects
  • Un débogueur visuel dans la Console Auris

Concepts Core

Objet

Un objet est toute ressource que tu veux protéger. Les objets ont un type et un ID :

document:readme
folder:engineering
organization:acme-corp
report:q4-2024

Le type est défini dans le modèle d’autorisation. L’ID est toute chaîne identifiant l’instance spécifique.

Relation

Une relation est un arc nommé dans le graphe d’autorisation — un type de rapport qu’un objet peut avoir avec les sujets. Les relations sont définies par type d’objet dans le modèle :

  • document peut avoir des relations : owner, editor, viewer
  • folder peut avoir des relations : owner, viewer
  • organization peut avoir des relations : admin, member

Sujet

Un sujet est qui (ou quoi) a une relation avec un objet. Les sujets peuvent être :

  • Un utilisateur : user:alice
  • Un userset (la relation d’un autre objet) : group:engineering#member (tous les membres du groupe engineering)

Tuple

Un tuple est un fait stocké : “ce sujet a cette relation avec cet objet.”

Format : object#relation@subject

Exemples :

document:readme#viewer@user:alice
document:readme#editor@user:bob
document:readme#viewer@group:engineering#member
folder:engineering#owner@user:charlie

L’exemple avant-dernier signifie : “tous les membres du groupe engineering sont viewers du document readme.” C’est un userset — un groupe de sujets défini par une autre relation.

Le DSL Auris

Auris utilise un domain-specific language compatible OpenFGA pour définir les modèles d’autorisation. Le DSL spécifie les types d’objets et leurs relations, incluant comment les relations sont dérivées d’autres relations.

Structure de Base

type user

type group
  relations
    define member: [user]

type folder
  relations
    define owner: [user]
    define viewer: [user, group#member] or owner

type document
  relations
    define parent: [folder]
    define owner: [user] or owner from parent
    define editor: [user, group#member] or owner
    define viewer: [user, group#member] or editor

Chaque bloc type définit un type d’objet. relations liste les relations nommées pour ce type, avec les règles sur comment elles sont dérivées.

Lire les Définitions de Relation

define viewer: [user, group#member] or editor

Cela signifie : “Un sujet est viewer d’un document si :

  • Le sujet est un type user ET il existe un tuple direct document:X#viewer@user:Y, OU
  • Le sujet est un group#member (un membre de quelque groupe) ET il existe un tuple direct document:X#viewer@group:Z, OU
  • Le sujet est un editor du document (calculé récursivement).”

Les Six Types de Réécriture

Le moteur d’autorisation supporte six types de règles de réécriture. Ils peuvent être composés pour modéliser presque tout schéma d’accès.

1. this — Assignation Directe

La règle la plus simple : la relation vaut si un tuple existe directement dans le store.

define owner: [user]

2. computedUserset — Héritage depuis une autre Relation

La relation vaut si le sujet a une relation différente avec le même objet.

define editor: [user] or owner

3. tupleToUserset — Suivre une Relation vers un autre Objet

C’est la règle la plus puissante. Elle suit une relation depuis l’objet courant vers un autre objet, puis vérifie une relation sur cet autre objet.

define owner: [user] or owner from parent

“L’utilisateur Alice est owner de document:X si il existe un tuple owner direct pour elle, OU si il existe un tuple document:X#parent@folder:Y ET Alice est owner de folder:Y.”

C’est le fonctionnement de l’héritage dans Google Drive : les documents héritent les permissions du dossier parent.

4. union — Combinaison OR

Une union de deux règles de réécriture ou plus. La relation vaut si n’importe quelle des sous-règles correspond.

5. intersection — Combinaison AND

Toutes les sous-règles doivent valoir. Utile pour exiger plusieurs conditions simultanément.

define restricted_viewer: [user] and approved

6. exclusion — Différence d’Ensembles (A MAIS PAS B)

La relation vaut pour les sujets dans le premier ensemble mais pas dans le second. Utile pour les deny lists.

define viewer: [user] but not blocked

L’Algorithme de Vérification

Quand on appelle POST /api/fga/check, le moteur évalue si objectType:objectId#relation@subjectType:subjectId vaut.

L’algorithme utilise un set visited pour prévenir les boucles infinies dans les modèles avec des références de relation circulaires. La profondeur maximale de récursion est limitée à 25.

Mode Explain

Quand on passe explain: true à POST /api/fga/check, le moteur retourne un arbre de résolution montrant exactement quelle règle a correspondu (ou échoué), jusqu’au tuple spécifique trouvé (ou non trouvé). C’est précieux pour déboguer les problèmes de contrôle d’accès.

Patterns de Modélisation

Modèle Google Drive

Utilisateurs et groupes ont accès aux documents directement ou en l’héritant du dossier parent :

type user

type group
  relations
    define member: [user]

type folder
  relations
    define owner: [user]
    define editor: [user, group#member] or owner
    define viewer: [user, group#member] or editor

type document
  relations
    define parent: [folder]
    define owner: [user] or owner from parent
    define editor: [user, group#member] or owner or editor from parent
    define viewer: [user, group#member] or editor or viewer from parent

Modèle SaaS Multi-Tenant

type user

type organization
  relations
    define admin: [user]
    define member: [user] or admin

type project
  relations
    define parent_org: [organization]
    define owner: [user] or admin from parent_org
    define contributor: [user, organization#member] or owner
    define viewer: [user, organization#member] or contributor

Migration de RBAC vers FGA

Il n’est pas nécessaire de choisir l’un ou l’autre. Auris supporte l’utilisation conjointe de RBAC et FGA :

  • RBAC gère : Accès coarse-grained aux fonctionnalités (view:invoices, manage:users)
  • FGA gère : Accès fine-grained au niveau ressource (document:X#editor@user:Y)

Débogage avec la Console

La Console Auris fournit un débogueur FGA visuel dans Administration → Fine-Grained Authorization → Débogueur. Il supporte trois opérations :

  • Check : Saisis un objet, relation et sujet — vois si la vérification passe ou échoue, avec l’arbre de résolution complet
  • Expand : Saisis un objet et relation — vois tous les sujets qui ont cette relation
  • List Objects : Saisis un sujet et relation — vois tous les objets d’un certain type accessibles au sujet

L’arbre de résolution visuel utilise un codage couleur :

  • Nœuds verts : règle évaluée comme vraie
  • Nœuds rouges : règle évaluée comme fausse
  • Nœuds bleus : usersets calculés intermédiaires

Concepts Associés

Architecture