Lockatus est le hub d’identité de la suite : la liste partagée des personnes et le portier commun. Il détient les utilisateurs, leurs mots de passe, leur double authentification et leurs rôles par application, et remet à chacun un laissez-passer signé pour entrer dans n’importe quelle application sans se reconnecter.
Authentification unique OIDC
Authorization Code + PKCE. Connectez-vous une seule fois au hub ; chaque application fédérée vous reconnaît et lit votre rôle depuis le jeton. Se connecter une fois ouvre toutes les applications auxquelles vous avez droit.
Vérification hors ligne
Le hub signe les jetons avec RS256 ; les applications les vérifient contre le JWKS public sans rappeler le hub. Si le hub est hors service, les sessions actives continuent de fonctionner.
La matrice d'accès
Une grille qui-par-système. Chaque application déclare son propre catalogue de rôles ; Lockatus les attribue. Aucun rôle pour une application signifie aucun accès — le contrôle se fait au niveau de la matrice.
Double authentification et récupération
Inscrivez le TOTP une seule fois (Google Authenticator ou compatible), avec des codes de récupération à usage unique et une réinitialisation par l’administrateur. Hérité par chaque application. Changer un mot de passe invalide chaque jeton de rafraîchissement.
Les quatre applications mono-utilisateur ne deviennent pas multi-utilisateurs en interne — Lockatus est leur table d’utilisateurs externe. Chaque application déclare les rôles qu’elle comprend ; le hub les attribue depuis la matrice, et l’application contrôle l’accès par rôle. La propriété plus profonde, par utilisateur, ne réside que là où une application possède réellement des ressources par personne (comme Selega).
Toute nouvelle application de la famille rejoint depuis la matrice elle-même, sans redéploiement : déclarez son slug et son catalogue de rôles (et les URI de redirection optionnelles) avec le bouton + App, puis attribuez les rôles aux utilisateurs. Le catalogue de la suite est livré pré-amorcé.
La fédération est optionnelle et non disruptive — chaque application conserve son login autonome
derrière un drapeau AUTH_MODE=federado (désactivé par défaut). En mode fédéré, l’application délègue
/login au hub et, lors du rappel, échange le code, vérifie les jetons RS256 contre le JWKS, et amorce
sa propre session — le reste du contrôle d’accès par rôle de l’application reste inchangé. Des clients
OIDC de référence sont fournis pour Node (node:crypto, sans dépendances supplémentaires) et Python
(cryptography).
