Principe de la synchronisation d’annuaire

Le répertoire d’une organisation regroupe utilisateurs, groupes et les membres qui relient les deux. Chaque changement – création, mise à jour ou suppression – doit être répercuté dans la base de données de l’application afin que les droits d’accès restent cohérents. L’article décrit trois tables classiques : Users (Alice, Bob), Groups (Product, Engineering) et Members qui lie utilisateurs et groupes, parfois de façon récursive.

Pour éviter les requêtes récursives coûteuses, Firezone a choisi de aplatir les appartenances : chaque utilisateur possède une ligne pour chaque groupe, direct ou indirect. Ainsi, la question « Bob appartient‑il à Product ? » se résout par une simple recherche dans la table Members.

Limites du protocole SCIM

SCIM (System for Cross‑domain Identity Management) propose un jeu d’endpoints REST standardisés. Les fournisseurs d’identité (Okta, JumpCloud, Entra, Google) envoient des requêtes GET/POST/PATCH/DELETE vers ces points. Le texte indique que le schéma de données et le timing des appels varient largement d’un fournisseur à l’autre : Okta combine ajouts et suppressions dans un même PATCH, tandis qu’Entra adopte une logique différente.

Deux problèmes majeurs sont soulignés :

  • L’application doit rester disponible en permanence ; une interruption de quelques secondes peut entraîner la perte d’un événement critique, car SCIM ne prévoit pas de mécanisme de re‑synchronisation complet.
  • SCIM ne définit pas le mapping exact entre les événements du fournisseur et les actions internes, ce qui oblige chaque implémentation à gérer des cas spécifiques.

Architecture du moteur propriétaire

Firezone a donc conçu un moteur « from scratch ». Le processus s’articule autour d’un pull périodique depuis les API des fournisseurs, suivi d’une normalisation des réponses en un format interne identique à celui de la base aplatie. Le moteur conserve un journal d’état qui permet de relancer un full sync en cas de perte d’événement, garantissant ainsi la consistance même après une panne.

GET /Users
GET /Users/{id}
POST /Users
PUT /Users/{id}
PATCH /Users/{id}
DELETE /Users/{id}
GET /Groups
GET /Groups/{id}
POST /Groups
PUT /Groups/{id}
PATCH /Groups/{id}
DELETE /Groups/{id}

Ces points d’entrée sont conservés uniquement pour la compatibilité avec les fournisseurs qui les implémentent, mais le moteur ne dépend plus d’eux pour la fiabilité.

Analyse des performances et de la fiabilité

En éliminant la dépendance à un endpoint toujours actif, le moteur réduit le temps d’indisponibilité à zéro : aucune mise à jour n’est perdue, car le pull reprend depuis le dernier jeton de pagination. La complexité de requête passe de O(n × depth) avec des groupes imbriqués à O(1) grâce à la table aplatie. Le coût supplémentaire réside dans le cycle de pull, qui consomme des appels API supplémentaires, mais le volume reste maîtrisable grâce à des intervalles configurables (ex. 30 s à 5 min selon le SLA du fournisseur).

En résumé, Firezone a choisi la robustesse et la prévisibilité d’un moteur propriétaire, au prix d’une implémentation plus lourde mais entièrement contrôlée, ce qui répond aux exigences d’applications où la perte d’un changement d’accès peut être critique.