Meme motif que les roles de realm, une etape plus loin. groupes-ldap.yml
posait aussi un oidc-group-membership-mapper sur les CLIENTS, alors que
clients-oidc.yml s'execute apres. Invisible tant que les clients existaient
d'un passage precedent.
Extrait dans claim-groupes.yml, place APRES clients-oidc. J'avais d'abord
insere l'appel AVANT — le defaut meme que je corrigeais ; rattrape avant tout
deploiement.
La lecon vaut au-dela du role : un fichier de taches nomme d'apres un SUJET
(« les groupes ») rassemble des etapes aux dependances differentes, et l'ordre
qui en resulte n'est correct que par accident. Ce qui doit gouverner le
decoupage, c'est ce dont chaque etape a BESOIN, pas ce dont elle parle.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`realm-admin` (role du client `realm-management`) est attache au GROUPE sysadmin.
Administrer le realm ne passe plus par le compte local. Portee : CE realm, jamais
`master` — le compte de secours reste hors d'atteinte du groupe, et c'est le sens
meme d'un acces de secours (D-40).
Les roles de CLIENT sont un espace de noms distinct : la declaration gagne
`roles_client`. L'API attend l'UUID du client, pas son clientId — interroger par
le nom rendait une erreur, la verification echouait toujours et la tache se
declarait `changed` a chaque passage. Deux passages consecutifs a changed=0.
La boucle de changement de mot de passe : `pwdMustChange: TRUE` signifie « quand
un ADMINISTRATEUR pose un mot de passe, l'utilisateur doit le changer ». Keycloak
ecrit en tant qu'administrateur — chaque changement relaye etait vu comme une
reinitialisation. Incompatible par construction avec un IdP qui relaie.
La contrainte est deplacee la ou l'utilisateur la voit : pwdMustChange FALSE cote
annuaire, action `UPDATE_PASSWORD` posee par Keycloak. J'avais eprouve pwdReset
au niveau LDAP, ou il marche, sans parcourir le chemin complet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Les deux services n'etaient pas encore deployes : les cabler maintenant vaut
mieux que les corriger apres. `porte_par` passe de `aucun` a `claim-groupe`.
Forgejo recoit --group-claim-name + --admin-group, et sa tache passe de « creer
si absent » a add-oauth OU update-oauth : le meme defaut que la federation
Keycloak — cree une fois, jamais corrige — l'attendait sinon.
Nextcloud recoit --mapping-groups + --group-provisioning, plus une tache qui
verse les membres du groupe d'habilitation dans le groupe interne `admin` : etre
dans un groupe projete ne donne aucun pouvoir en soi.
Le maillon qui manquait aux deux : AUCUN mapper de protocole n'emettait le claim.
Les groupes existaient dans le realm et n'apparaissaient dans aucun jeton — un
cablage correct des deux cotes et rien au milieu. `oidc-group-membership-mapper`
pose sur les trois clients, `full.path=false` pour que le claim porte `sysadmin`
et non `/sysadmin`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La chaine est complete : LDAP cn=sysadmin -> groupe de realm -> role
grafana-admin -> Admin dans Grafana. Ajouter quelqu'un au groupe dans l'annuaire
lui ouvre Grafana sans deploiement et sans que personne ne soit nomme (D-66).
Rejoue : changed=0.
Defaut de fond trouve en chemin : la federation LDAP n'etait JAMAIS reconciliee.
`federation-ldap.yml` creait le provider s'il manquait puis ne le corrigeait
plus — il pointait encore `ldaps://id-ldap-01...`, le nom errone corrige le matin
meme dans `resoudre_annuaire`. La synchronisation echouait sur `UnknownHost`.
C'est le revers de D-67 au mauvais endroit : l'INFRASTRUCTURE se reconcilie,
seules les appartenances ne le sont pas. URL, usersDn et bindDn sont desormais
corriges a chaque passage.
Et j'avais masque l'echec avec `|| true` : le mapper existait, le realm restait
vide, rien ne disait pourquoi. Retire — l'erreur remonte avec son message.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
