Le Hub · Comptes et connexion unique
Un compte,
toutes les applications.
Les comptes, les rôles et les droits sont tenus au même endroit, pour tous vos programmes. On se connecte une fois ; on retire un accès en un geste.
À quoi ça sert
Dix programmes, c’est souvent dix comptes par personne, dix pages de connexion, dix mots de passe. Quand un collaborateur arrive, on crée dix comptes ; quand il part, on en oublie un. Et chaque programme doit coder sa propre connexion, avec ses propres failles.
Sur le Hub, l’identité est un service commun. Le Hub tient les comptes et les rôles, pose une session valable pour toutes les applications, et transmet à chacune une identité déjà vérifiée. Aucune application n’a de page de connexion à écrire.
Ce qu’on voit à l’écran
L’écran Gestion des rôles, au 2026-09-23. Dans le menu, IAM se déplie en cinq entrées : Utilisateurs, Tenants (les organisations), Rôles, Scopes (les portées) et Clés API.
Le tableau a cinq colonnes : Nom, Description, Scopes, Utilisateurs, Actions. Une flèche à gauche de chaque ligne déplie le détail du rôle ; le bouton Supprimer est à droite ; Créer un rôle est en haut.
Les noms suivent une convention qui se lit d’elle-même :
- admin — « SocleHub administrator with full access » : 20 portées, 1 personne. C’est le seul rôle de la capture qui porte des portées.
- admin:certs, admin:dns, admin:vault — gérer les certificats, le DNS, les secrets. Des rôles d’administration découpés par domaine, aucun attribué ici.
- agentia:runner — un utilisateur technique, pour faire tourner les agents IA de chaque organisation : 4 comptes le portent.
- app:agentia:user, app:appdemo:admin, app:appdemo:user, app:appdemo:viewer — la forme
app:<application>:<rôle>rattache un rôle à une application. - app:bilansocle:beneficiaire, :consultant, :cabinet_admin, :platform_admin — quatre rôles pour une même application de bilans de compétences, une personne sur chacun.
La page de connexion est celle du Hub, et la seule : deux champs, un bouton Se connecter, un lien Mot de passe oublié ?. Une fois connecté, on passe d’une application à l’autre sans se reconnecter.
Comment on s’en sert
On crée le compte
Depuis l’entrée Utilisateurs : une adresse mail, un nom. S’il l’oublie, la personne réinitialise elle-même son mot de passe depuis la page de connexion.
On lui donne un rôle
Administrateur du Hub, administrateur des certificats, utilisateur d’une application… Un rôle regroupe des portées ; l’accès à une application est une portée comme une autre.
On la rattache à une organisation
Si le Hub sert plusieurs organisations, chacune a ses utilisateurs et ses accès. Une personne peut appartenir à plusieurs, et choisit la sienne à la connexion.
On émet des clés d’API si besoin
Pour un programme qui appelle le Hub ou une API. Chaque clé porte une organisation et des portées, et se révoque tout de suite.
Au départ, on ferme un compte
On verrouille le compte : la personne ne peut plus se connecter, à aucune application.
Sous le capot
| Worker | iam_worker |
| Rôles et portées | create_role, delete_role, assign_role, revoke_role, assign_scope_to_role, remove_scope_from_role |
| Comptes | create_user, update_user, lock_user, delete_user, get_my_identity |
| Organisations | create_tenant, grant_tenant_access, revoke_tenant_access, suspend_tenant, restore_tenant, tenant_consistency_audit |
| Accès et clés | grant_app_access, create_api_key, create_my_api_key, revoke_api_key, list_oidc_clients |
| Jetons | JWT RS256, clés publiées en JWKS ; mots de passe en BCrypt ; clés d’API stockées en empreinte SHA-256 |
| OIDC | le Hub est fournisseur OpenID Connect (code d’autorisation, PKCE S256) |
| En-têtes | le proxy transmet X-SSO-User (identifiant numérique), X-SSO-Email, X-SSO-Scopes, X-SSO-Tenant, et retire tout en-tête x-sso-* venu de l’extérieur |
| Console | /hub/login, /hub/iam, /hub/iam/roles, /hub/iam/tenants |
Chaque route du proxy choisit son niveau : ouverte, connexion facultative, connexion obligatoire. L’application ne voit jamais le jeton, seulement l’identité vérifiée.
Les limites d’aujourd’hui
Le Hub dit qui est connecté et à quelles applications il a droit. Il ne transmet pas les rôles métier d’une application (qui administre, qui consulte) : chaque application les tient elle-même, dans sa propre table. C’est ce que nous livrons dans chaque programme. Et chaque Hub a ses propres comptes : deux Hubs ne partagent pas leurs utilisateurs.