Session de console et revocations

Un compte local dont les authorities nomment un role admin se connecte a la console par identifiant et mot de passe ; le serveur lui rend un jeton de session qu’il signe lui-meme.

[auth.methods]
local = { enabled = true, password = true }

[[users]]
username = "eric"
password_hash = "$argon2id$..."
authorities = ["admins"]

[[admin.roles]]
name = "admins"
permissions = ["overview", "sessions", "kick", "bans", "unban", "config", "logs", "audit", "revoke", "grant"]

[admin.ban]
max_failures = 5

[admin.session]
key_file = "/secrets/admin-session.key"   # 32 octets au moins, la meme sur toutes les instances
ttl_secs = 3600
max_age_secs = 43200

La connexion compte ses echecs dans [admin.ban], qu’elle exige (Bans), et passe par la file de hachage des mots de passe (Verification des mots de passe).

Se connecter

Requete	Reponse
`POST /admin/login` `{"username": "...", "password": "..."}`	`token`, a envoyer en `Bearer` ; `username`, `expires_at`, `expires_in`, `auth_time`, `roles`, `permissions`
`GET /admin/login`	`{"password": true}` quand la porte connecte des comptes
`POST /admin/session/renew` (jeton de session)	un nouveau jeton, tant que `max_age_secs` depuis la connexion n’est pas passe
`GET /admin/me` (tout jeton)	nom, methode, permissions, roles admin, `expires_at`, `expires_in`, `auth_time`

Le jeton ne porte que le compte : chaque requete relit le compte en vigueur ([[users]] ou users_file) et recalcule ses permissions. Un rechargement de users_file qui retire un role, change le mot de passe ou retire le compte s’applique a la requete suivante.

La cle de session

La cle qui signe les jetons est la meme sur toutes les instances : key_file, ou sous Kubernetes secret_name (Secrets). Sans l’une ni l’autre, la cle est tiree au demarrage : les sessions vivent avec le processus, sur cette instance seule. Toutes les cles : Reference [admin.session].

Revoquer, se deconnecter

Requete	Effet
`POST /admin/revocations` `{"username": "eric"}` (permission `revoke`)	tout jeton de session du compte emis jusque-la est refuse, sur tous ses onglets et appareils ; une nouvelle connexion passe. La reponse dit `lift` : `held` (l’etat partage porte la revocation) ou `local_only` (cette instance seulement)
`POST /admin/logout`	de meme pour le compte de l’appelant ; sous un JWT du fournisseur ou le jeton statique, rien n’est revoque (`204`) et la console oublie le jeton
`GET /admin/revocations`	les revocations en vigueur ; chacune disparait `max_age_secs` apres son `issued_before`

Les flux ouverts sous un jeton revoque (/admin/events, suivis de journaux) se ferment.

Partager les revocations

[admin.session]
persist_file = "/var/lib/craft-file-gate/admin-revocations.json"  # un fichier a elles
# ou, sous Kubernetes :
# backend = "configmap"                                  # le chart le pose avec le Secret partage
# revocation_configmap_name = "craft-file-gate-access"
reread_interval_secs = 5

Toutes les cles : Reference [admin.session].

Une cle partagee va avec des revocations partagees, et des horloges synchronisees (NTP) : une revocation est datee, et une instance dont l’horloge avance ou retarde l’applique avec cet ecart.

Dans la console

Identifiant et mot de passe quand la porte connecte des comptes ; « Sign in with a token » prend le jeton statique ou un JWT du fournisseur, seul formulaire sinon.
Le jeton vit dans la page : recharger, ouvrir un onglet ou fermer le navigateur redemande la connexion. Le navigateur ne garde que le theme et les vues des tableaux.
La session est renouvelee tant que la page est ouverte, jusqu’a max_age_secs apres la connexion ; un onglet ferme la laisse finir a ttl_secs. L’en-tete dit le compte, ses roles admin et la fin du jeton.
Logout appelle POST /admin/logout : une session deconnecte tous les onglets et appareils du compte.