Suivre et corriger les accès depuis la console

Dans l’architecture de référence, Lemniscate ne gère pas d’identités : les accès se suivent et se corrigent dans votre annuaire, et une session ou un utilisateur se révoque depuis la console (livre blanc sécurité V3, sections 4.5 et 6.1). Des comptes locaux n’existent que là où aucun annuaire n’est disponible. Cette page concerne les consoles dont le profil de construction porte un référentiel de comptes local : elle décrit les gestes de correction depuis l’onglet Users, et ce que chacun laisse derrière lui.

La création d’un compte est traitée ailleurs : Donner une clé d’API à une équipe. Les plafonds de dépense le sont aussi : Plafonner la dépense d’un client.

Le profil qui porte cet onglet

L’onglet Users, comme Plans et Usage, n’est présent que dans les consoles construites en profil hébergé. Dans le profil fermé, celui obtenu par défaut, il n’y a pas de référentiel de comptes local : les identités viennent de votre annuaire, les accès s’y gèrent, et les chemins correspondants répondent 404, avec un message qui le dit. Une console qui n’affiche pas cet onglet n’est pas une console mal configurée.

Lire l’écran des comptes

Colonne	Ce qu’elle montre
ID	L’identifiant du compte. Il porte l’attribution des appels facturés.
Username	Le nom du compte.
API Key	Un fragment de la clé la plus récente du compte, jamais la clé. No live key quand plus aucune clé du compte n’est valide.
Plan	Le plan porté, modifiable sur place. Un compte sans plan porte Blocked.
Active	Active ou Inactive.
Created	La date de création.

Les comptes sont listés du plus récent au plus ancien. Il n’y a ni recherche, ni tri, ni pagination.

Le fragment de clé

Une clé d’API est affichée une seule fois : dans l’écran, juste après une création, une émission ou une rotation. Elle n’est ensuite plus lisible, par personne. La base n’en garde qu’un condensat.

La colonne API Key montre un fragment : le préfixe et les quatre derniers caractères. Il sert à distinguer deux clés l’une de l’autre quand quelqu’un vous dit « ma clé finit par… ». Il ne permet pas de retrouver la clé. Un compte peut porter plusieurs clés ; la colonne affiche le fragment de la plus récente et le nombre des autres (+1 more).

Une clé perdue ne se récupère pas : elle se remplace.

Les deux états Blocked et Inactive

Ce que vous voyez	Ce qui se passe	Comment on sort
Blocked dans Plan	Le compte n’a aucun plan. La passerelle refuse ses appels en 403.	Lui attribuer un plan, dans la colonne Plan.
Inactive dans Active	Le compte a été retiré du service. Ses clés n’authentifient plus.	Le réactiver (voir plus bas ; il n’y a pas de bouton).

Faire tourner une clé compromise

Bouton Rotate key sur la ligne du compte, puis confirmation.

Ce que cela produit :

• une clé neuve est émise et affichée une seule fois ;
• toutes les clés que le compte portait cessent d’authentifier immédiatement, sans période de recouvrement ;
• le compte garde son identité, donc ses appels déjà facturés restent portés à son nom.

Prévenez la personne ou l’équipe avant : entre le clic et la remise de la nouvelle clé, son accès est coupé.

Retirer un accès

Bouton Delete, puis confirmation. La console choisit entre deux issues, selon l’historique du compte :

Situation	Ce qui se passe
Aucun appel n’a jamais été journalisé pour lui	Le compte est supprimé.
Des appels ont été journalisés	Le compte est désactivé, sa ligne conservée.

Dans le second cas, supprimer la ligne détruirait l’attribution des appels déjà facturés. Dans les deux cas, la clé cesse d’authentifier.

Réactiver un compte désactivé

Il n’y a pas de bouton pour cela. La colonne Active est un affichage. Le chemin existe côté service ; l’écran ne l’expose pas.

La réactivation se fait par un appel direct, avec l’identifiant du compte lu dans la colonne ID :

curl -X PATCH "$CONSOLE/api/users/42" \
  -H "Content-Type: application/json" \
  -d '{"active": true}'

Posez dans CONSOLE l’adresse de votre console, en https://, et présentez l’identité avec laquelle vous ouvrez l’interface. La réponse rend l’état du compte, fragment de clé compris.

Ce chemin ne rend pas la clé : si elle a été perdue entre-temps, faites-la tourner.

Changer le plan d’un compte

Le sélecteur de la colonne Plan enregistre au moment où vous choisissez, sans confirmation.

L’option No plan retire son plan au compte, ce qui le bloque : la passerelle répond 403 à un compte sans plan. Le refus reçu par l’appelant parle d’un plan manquant, ce qui oriente vers un problème de facturation. Pour couper un accès, utilisez Delete.

Modifier ou supprimer un plan

Dans l’onglet Plans, chaque ligne se modifie sur place (Edit) : son nom et son plafond mensuel. Un champ de plafond vide rend le plan illimité ; ce n’est pas un plafond de zéro.

La colonne Users compte les comptes qui portent le plan, y compris les comptes désactivés. Un plan qui affiche des porteurs alors que plus personne ne travaille avec est porté par des comptes désactivés.

Supprimer un plan est refusé tant qu’un compte le porte, avec le motif : Cannot delete plan: users still carry it. Reassign them to another plan first. Réaffectez d’abord ces comptes ; leur retirer leur plan les bloquerait.

Le journal des actes d’administration

Les attributions de rôle, leurs retraits, les révocations et leurs levées, et tout changement de politique sont journalisés avec leur auteur, dont l’identité vient de votre annuaire. Le journal est en ajout seul, et chaque entrée scelle la précédente (livre blanc sécurité V3, sections 7.1 et 7.2).

Le journal se lit par un chemin réservé au rôle d’auditeur ; un administrateur d’instance ne peut pas le lire, le cumul de l’administration et de l’audit étant refusé. Les chemins et les permissions exacts sont dans la référence de la console d’administration.