Utilisateurs
Un utilisateur dans Liberty est l'identité qui se connecte et porte des rôles. L'onglet Liberty Next → Administrer → Accès → Utilisateurs est l'endroit où créer les utilisateurs locaux, voir les utilisateurs OIDC qui se sont connectés au moins une fois, attribuer les rôles et basculer les drapeaux actif et superutilisateur.
La même interface gère les deux backends d'identité (TOML / DB) et les deux sources d'identité (locale / OIDC). Les différences portent sur les champs modifiables : les utilisateurs OIDC n'ont pas de mot de passe (il est chez l'IdP) et leur champ provider est en lecture seule.
L'onglet Utilisateurs
Chaque carte affiche le nom d'utilisateur (monospace), le nom complet, le courriel, le fournisseur (local / oidc), les pastilles de statut et les rôles attribués.
| Pastille | Signification |
|---|---|
| superutilisateur (orange) | is_superuser = true — passe outre chaque vérification de permission. |
| inactif (rouge) | is_active = false — l'utilisateur ne peut pas se connecter. Ses sessions existantes s'arrêtent au prochain rafraîchissement de jeton. |
| Aucun rôle (atténué) | Aucun rôle attribué et pas de superutilisateur — l'utilisateur se connecte mais ne voit rien. |
| Noms de rôles (violet) | Chaque rôle attribué, une pastille par rôle. |
Ajouter un utilisateur local
Cliquer sur ＋ Ajouter un utilisateur. L'éditeur d'utilisateur s'ouvre avec chaque champ vide.
Champs
| Champ | Requis | Notes |
|---|---|---|
| Nom d'utilisateur | oui | Lettres, chiffres, soulignés, points et tirets. Sert d'identifiant de connexion, de sujet JWT et d'identité d'audit. Immuable après création. |
| Nom complet | non | Le nom d'affichage montré dans les en-têtes et les colonnes d'audit. |
| Courriel | non | Où un lien Mot de passe oublié ? est envoyé (voir plus bas), et l'adresse des notifications. |
| Mot de passe | oui (pour les nouveaux utilisateurs) | Au moins 8 caractères. Enregistré sous forme de hachage Argon2id, jamais relisible. Laisser vide en modification pour conserver le mot de passe actuel. |
| Demander un nouveau mot de passe à la prochaine connexion | coché par défaut pour un nouvel utilisateur | Le mot de passe saisi ici est temporaire : l'utilisateur choisit le sien à la première connexion (voir plus bas). Comptes locaux uniquement. |
| Rôles | non | Sélecteur de pastilles — taper ou choisir dans la liste. La liste contient chaque rôle configuré sous l'onglet Rôles. |
| Actif | oui (activé par défaut) | Désactivé, l'utilisateur ne peut pas se connecter ; les sessions existantes s'arrêtent au prochain rafraîchissement de jeton. |
| Superutilisateur | non | Activé, passe outre chaque vérification de permission et chaque périmètre de données. À utiliser avec parcimonie. |
| Data-scope attributes | non | Paires clé / valeur lues par le périmètre de données des rôles — voir plus bas. |
Cliquer sur Enregistrer — l'utilisateur est créé et la fenêtre se ferme. Le nouvel utilisateur apparaît en tête de liste.
Endpoints en coulisses
| Action | Endpoint |
|---|---|
| Création | POST /admin/access/users |
| Mise à jour | PATCH /admin/access/users/{username} |
| Changement de mot de passe | POST /admin/access/users/{username}/password |
Le backend TOML écrit dans config/auth.toml de façon atomique ; le backend DB commit dans ly2_users / ly2_user_roles. Dans les deux cas, le changement prend effet immédiatement — l'utilisateur peut se connecter tout de suite avec le nouveau mot de passe.
Modifier un utilisateur existant
Cliquer sur n'importe quelle ligne d'utilisateur pour ouvrir l'éditeur avec ses valeurs courantes :
| Champ | Modifiable | Notes |
|---|---|---|
| Nom d'utilisateur | non | Fixé à la création. |
| Nom complet / Courriel | oui | Mise à jour libre. |
| Mot de passe | oui (utilisateurs locaux uniquement) | Laisser vide pour conserver le mot de passe actuel. Saisir un nouveau (8 caractères ou +) le définit à l'enregistrement. |
| Rôles | oui | Ajouter / retirer des pastilles. |
| Actif | oui | Basculer pour désactiver. |
| Superutilisateur | oui | Basculer pour accorder / révoquer le statut superutilisateur. |
| Data-scope attributes | oui | Voir plus bas. |
Les enregistrements passent par PATCH /admin/access/users/{username} pour les mises à jour de propriétés et par POST /admin/access/users/{username}/password si un nouveau mot de passe a été saisi.
Les changements n'interrompent pas la session courante. Les nouveaux rôles / le drapeau de désactivation / le mot de passe prennent effet au prochain rafraîchissement (dans le TTL du jeton d'accès — par défaut 1 heure) ou à la déconnexion + reconnexion.
Un nouveau mot de passe à la première connexion
Un compte créé — ou réinitialisé par un administrateur — avec Demander un nouveau mot de passe à la prochaine connexion s'ouvre sur Choisissez votre mot de passe : le mot de passe temporaire, le nouveau (8 caractères ou plus) et sa confirmation. Tant que ce n'est pas fait, le serveur refuse tout appel sauf le changement lui-même (HTTP 403 password change required) : le mot de passe temporaire ne sert à rien d'autre, ni par la page ni par l'API. Le nouveau mot de passe prend effet aussitôt — sans nouvelle connexion. En ligne de commande : liberty-admin create-user … --must-change, liberty-admin set-password … --must-change. Un compte OIDC n'est jamais concerné (son mot de passe est celui du fournisseur d'identité).
Mot de passe oublié
Quand le SMTP est configuré (Liberty Next → Administrer → App, notifications), la page de connexion affiche Mot de passe oublié ?. L'utilisateur indique son identifiant et l'e-mail du compte ; quand les deux correspondent à un compte local actif, un lien est envoyé à cette adresse. Le lien sert une seule fois et pendant une heure — il est lié au mot de passe pour lequel il a été émis : tout changement de mot de passe, la réinitialisation comprise, l'annule. La page répond la même chose que les deux correspondent ou non : elle ne révèle jamais qui a un compte ; les demandes sont limitées par adresse. Le lien pointe vers Adresse publique (App, [app] public_url) — à renseigner quand les utilisateurs passent par un proxy inverse ou un autre nom ; vide, l'adresse du navigateur est utilisée.
Attributs de périmètre de données
Le périmètre de données d'un rôle peut prendre ses valeurs chez l'utilisateur au lieu de les lister : une règle Company (CO) = user.company permet à un seul rôle de servir toutes les filiales, chaque utilisateur voyant ses propres sociétés.
Dans le formulaire de l'utilisateur, Data-scope attributes contient une ligne par attribut : une clé (company) et une valeur (00001, 00050 — une virgule forme une liste). Add an attribute… propose les clés déjà utilisées par les rôles. Un utilisateur qui n'a pas l'attribut qu'une règle demande ne voit aucune ligne au travers de cette règle.
En ligne de commande : liberty-admin set-attributes alice company=00001,00050.
La liste des utilisateurs affiche les attributs sur chaque carte (company=00001,00050), et l'utilisateur les retrouve, avec son périmètre de données en clair, dans sa fenêtre Profil.
Utilisateurs OIDC — les différences
Les utilisateurs OIDC arrivent dans la liste des Utilisateurs après leur première connexion — Liberty les crée automatiquement avec provider = "oidc". L'éditeur pour un utilisateur OIDC a la même apparence, mais :
| Champ | Modifiable pour OIDC ? | Notes |
|---|---|---|
| Nom d'utilisateur | non | Identique au local. |
| Nom complet / Courriel | techniquement oui, mais… | À chaque connexion OIDC, ces champs sont rafraîchis depuis les claims de l'IdP. Les modifications manuelles sont écrasées. Les modifier au niveau de l'IdP. |
| Mot de passe | non | L'IdP détient le mot de passe. Le champ est désactivé ou rejeté avec HTTP 400. |
| Rôles | oui | C'est la raison principale qui pousse les opérateurs à visiter les utilisateurs OIDC — pour attribuer les rôles. |
| Actif | oui | Désactivé, la connexion est refusée même avec des jetons OIDC valides. |
| Superutilisateur | oui | Basculer pour accorder le contournement. |
La séquence d'onboarding standard :
- La nouvelle recrue se connecte via OIDC pour la première fois.
- Elle arrive avec aucun rôle → elle voit une application vide.
- Elle prévient son administrateur : « je suis entré mais je ne vois rien ».
- L'administrateur ouvre Liberty Next → Administrer → Accès → Utilisateurs, la retrouve, attribue les bons rôles, enregistre.
- L'utilisatrice rafraîchit la page (ou se déconnecte + reconnecte) et dispose alors de ses accès.
Pour les installations qui veulent pré-créer des utilisateurs OIDC avec leurs rôles déjà attachés, des scripts peuvent appeler POST /admin/access/users avec provider = "oidc" et le provider_subject attendu (le claim sub). À la première connexion, le framework retrouve l'utilisateur pré-créé et l'utilise. Les installations standard sautent cette étape et attribuent les rôles après la première connexion.
Désactiver un utilisateur
Les utilisateurs ne se suppriment pas : pour écarter quelqu'un, passer Actif sur off et enregistrer. Il ne peut plus se connecter ; sa session en cours prend fin à l'expiration de son jeton d'accès (une heure au plus), puisque le renouvellement est refusé. Rôles, attributs et historique sont conservés, et repasser Actif sur on rétablit le compte tel quel.
Ce que l'on fait concrètement — flux types
Onboarder une recrue locale
- Liberty Next → Administrer → Accès → Utilisateurs → ＋ Ajouter un utilisateur.
- Nom d'utilisateur = identifiant d'entreprise, mot de passe = une chaîne ponctuelle qu'elle changera, courriel = son adresse.
- Attribuer les rôles selon son équipe (
analyst,reporter, …). - Enregistrer.
- Lui transmettre les identifiants temporaires par le canal habituel de l'entreprise.
- Elle se connecte avec et arrive sur Choisissez votre mot de passe — avec Demander un nouveau mot de passe à la prochaine connexion coché (par défaut), rien d'autre ne s'ouvre tant qu'elle n'a pas défini le sien.
Onboarder une recrue OIDC
- Elle se connecte via OIDC la première fois — Liberty crée automatiquement le compte.
- Elle signale qu'elle n'a aucun accès.
- Liberty Next → Administrer → Accès → Utilisateurs, la retrouver, attribuer les rôles, enregistrer.
- Elle rafraîchit → elle est dedans.
Changer le mot de passe d'un utilisateur (en tant qu'administrateur)
- Liberty Next → Administrer → Accès → Utilisateurs, cliquer sur l'utilisateur.
- Saisir le nouveau mot de passe dans le champ Mot de passe (8 caractères ou +) ; cocher Demander un nouveau mot de passe à la prochaine connexion pour qu'il soit temporaire.
- Enregistrer.
- Le prévenir. Il se connecte avec le nouveau mot de passe (et, s'il est temporaire, choisit le sien) ; sa session existante continue de fonctionner jusqu'à expiration du jeton d'accès.
Avec le SMTP configuré, les utilisateurs peuvent aussi le réinitialiser eux-mêmes — Mot de passe oublié ?.
Révoquer un compte immédiatement
- Basculer Actif sur off et enregistrer.
- Si le délai pouvant aller jusqu'à 1 heure avant l'expiration du jeton d'accès courant est inacceptable, faire tourner le secret de signature JWT (
LIBERTY_JWT_SECRET) et redémarrer. Chaque jeton existant est invalidé — un coup de marteau lourd, mais la seule révocation immédiate offerte par Liberty.
Pièges courants
| Erreur | Symptôme | Correction |
|---|---|---|
| Utilisateur OIDC sans rôles après connexion. | Comportement attendu — l'opérateur n'en a pas encore attribué. | Ouvrir Liberty Next → Administrer → Accès → Utilisateurs, attribuer les rôles. |
| Modifier le courriel d'un utilisateur OIDC revient à la connexion suivante. | Le claim de l'IdP l'emporte ; le framework rafraîchit depuis le dernier jeton. | Modifier le courriel au niveau de l'IdP. |
| Tenter de définir un mot de passe pour un utilisateur OIDC. | Le backend rejette avec 400. | Les utilisateurs OIDC n'ont pas de mot de passe local — ils se connectent via le fournisseur. |
| Changer le rôle d'un utilisateur ne prend pas effet immédiatement. | Le JWT de l'utilisateur contient toujours les anciens rôles. | Il rafraîchit (ou se déconnecte + reconnecte) — dans le TTL du jeton d'accès, les nouveaux rôles s'appliquent. |
| Un utilisateur soumis à un périmètre par attribut ne voit rien. | L'utilisateur n'a pas de valeur pour l'attribut lu par la règle. | L'ajouter dans Data-scope attributes. |
| Passer un utilisateur en superutilisateur pour corriger un manque de permission. | Cela fonctionne, mais cela passe outre chaque vérification — y compris celles qu'il ne devrait pas contourner. | Ajouter plutôt la permission manquante à l'un de ses rôles. |
Suite
- Rôles et permissions — ce qu'il faut attribuer une fois l'utilisateur créé.
- Se connecter — comment les utilisateurs s'authentifient réellement.
- Secrets chiffrés — le switch 🔒 pour les identifiants ailleurs dans le framework.