Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Set-OPS-Public/roles/serveur_keycloak/meta/acces.yml

29 lines
1.3 KiB
YAML
Raw Normal View History

acces : les cinq meta/acces.yml, et le mecanisme qui manque a chacun Chaque role web declare le GROUPE qu'il reconnait et ce qu'il lui accorde. Un troisieme champ s'est impose en ecrivant : `porte_par` — le mecanisme qui transporte reellement l'habilitation. Sans lui, les declarations auraient decrit une chaine inexistante. Etat mesure : grafana `role-realm` (reel) ; forgejo, nextcloud et keycloak `aucun` ; icingaweb2 `liste-uid` — il NOMME DES PERSONNES, ce que D-66 interdit. Le maillon manquant est chez Keycloak : `role_assignments` assigne un role a un UTILISATEUR, et son propre commentaire l'admettait (« en prod, preferer l'assignation via groupe d'annuaire »). Sans group-ldap-mapper, les groupes LDAP n'atteignent jamais les services. Sa meta a donc une autre forme, `acces_projection` : Keycloak projette au lieu de consommer (D-65). Defaut corrige : `serveur_icingaweb2_admins` valait "testmail", un compte de test code en dur dans le moteur qu'aucune instance ne surchargeait — le seul administrateur declare de la supervision etait un utilisateur inexistant. Il suit desormais l'uid d'amorcage. Verifie sur mon-01 : users = "sysadmin". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 13:59:33 -04:00
---
# Keycloak n'est pas un CONSOMMATEUR d'habilitations : il les PROJETTE (D-65).
# LDAP porte les groupes, Keycloak les traduit en roles de realm que les services
# lisent dans le jeton. Sa declaration a donc une autre forme.
#
# `projette` decrit la traduction attendue ; `porte_par` dit ce qui la realise.
acces_projection:
keycloak : group-ldap-mapper — le role s'attache au GROUPE 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>
2026-08-07 14:32:47 -04:00
# `group-ldap-mapper` importe les groupes de l'annuaire dans le realm, et le
# ROLE EST ATTACHE AU GROUPE — pas a une personne (D-66). Ajouter quelqu'un a
# `cn=sysadmin,ou=groups` lui ouvre Grafana en Admin, sans deploiement.
# `serveur_keycloak_groupes_roles` declare la correspondance.
acces : les cinq meta/acces.yml, et le mecanisme qui manque a chacun Chaque role web declare le GROUPE qu'il reconnait et ce qu'il lui accorde. Un troisieme champ s'est impose en ecrivant : `porte_par` — le mecanisme qui transporte reellement l'habilitation. Sans lui, les declarations auraient decrit une chaine inexistante. Etat mesure : grafana `role-realm` (reel) ; forgejo, nextcloud et keycloak `aucun` ; icingaweb2 `liste-uid` — il NOMME DES PERSONNES, ce que D-66 interdit. Le maillon manquant est chez Keycloak : `role_assignments` assigne un role a un UTILISATEUR, et son propre commentaire l'admettait (« en prod, preferer l'assignation via groupe d'annuaire »). Sans group-ldap-mapper, les groupes LDAP n'atteignent jamais les services. Sa meta a donc une autre forme, `acces_projection` : Keycloak projette au lieu de consommer (D-65). Defaut corrige : `serveur_icingaweb2_admins` valait "testmail", un compte de test code en dur dans le moteur qu'aucune instance ne surchargeait — le seul administrateur declare de la supervision etait un utilisateur inexistant. Il suit desormais l'uid d'amorcage. Verifie sur mon-01 : users = "sysadmin". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 13:59:33 -04:00
- groupe: sysadmin
projette: [grafana-admin]
keycloak : group-ldap-mapper — le role s'attache au GROUPE 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>
2026-08-07 14:32:47 -04:00
porte_par: group-ldap-mapper
acces : les cinq meta/acces.yml, et le mecanisme qui manque a chacun Chaque role web declare le GROUPE qu'il reconnait et ce qu'il lui accorde. Un troisieme champ s'est impose en ecrivant : `porte_par` — le mecanisme qui transporte reellement l'habilitation. Sans lui, les declarations auraient decrit une chaine inexistante. Etat mesure : grafana `role-realm` (reel) ; forgejo, nextcloud et keycloak `aucun` ; icingaweb2 `liste-uid` — il NOMME DES PERSONNES, ce que D-66 interdit. Le maillon manquant est chez Keycloak : `role_assignments` assigne un role a un UTILISATEUR, et son propre commentaire l'admettait (« en prod, preferer l'assignation via groupe d'annuaire »). Sans group-ldap-mapper, les groupes LDAP n'atteignent jamais les services. Sa meta a donc une autre forme, `acces_projection` : Keycloak projette au lieu de consommer (D-65). Defaut corrige : `serveur_icingaweb2_admins` valait "testmail", un compte de test code en dur dans le moteur qu'aucune instance ne surchargeait — le seul administrateur declare de la supervision etait un utilisateur inexistant. Il suit desormais l'uid d'amorcage. Verifie sur mon-01 : users = "sysadmin". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 13:59:33 -04:00
raison: >-
keycloak : group-ldap-mapper — le role s'attache au GROUPE 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>
2026-08-07 14:32:47 -04:00
Le groupe d'administration devient le role de realm que Grafana lit dans le
claim `roles`.
acces : les cinq meta/acces.yml, et le mecanisme qui manque a chacun Chaque role web declare le GROUPE qu'il reconnait et ce qu'il lui accorde. Un troisieme champ s'est impose en ecrivant : `porte_par` — le mecanisme qui transporte reellement l'habilitation. Sans lui, les declarations auraient decrit une chaine inexistante. Etat mesure : grafana `role-realm` (reel) ; forgejo, nextcloud et keycloak `aucun` ; icingaweb2 `liste-uid` — il NOMME DES PERSONNES, ce que D-66 interdit. Le maillon manquant est chez Keycloak : `role_assignments` assigne un role a un UTILISATEUR, et son propre commentaire l'admettait (« en prod, preferer l'assignation via groupe d'annuaire »). Sans group-ldap-mapper, les groupes LDAP n'atteignent jamais les services. Sa meta a donc une autre forme, `acces_projection` : Keycloak projette au lieu de consommer (D-65). Defaut corrige : `serveur_icingaweb2_admins` valait "testmail", un compte de test code en dur dans le moteur qu'aucune instance ne surchargeait — le seul administrateur declare de la supervision etait un utilisateur inexistant. Il suit desormais l'uid d'amorcage. Verifie sur mon-01 : users = "sysadmin". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 13:59:33 -04:00
# Ce que Keycloak accorde SUR LUI-MEME (sa propre console d'administration).
acces:
- groupe: sysadmin
accorde: realm-admin
keycloak : realm-admin par appartenance, et la boucle de mot de passe `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>
2026-08-07 19:47:10 -04:00
# Role de CLIENT (`realm-management`), attache au GROUPE. Portee : ce realm
# seulement, jamais `master` — le compte de secours reste hors de portee du
# groupe, ce qui est le sens meme d'un acces de secours (D-40).
porte_par: role-client
acces : les cinq meta/acces.yml, et le mecanisme qui manque a chacun Chaque role web declare le GROUPE qu'il reconnait et ce qu'il lui accorde. Un troisieme champ s'est impose en ecrivant : `porte_par` — le mecanisme qui transporte reellement l'habilitation. Sans lui, les declarations auraient decrit une chaine inexistante. Etat mesure : grafana `role-realm` (reel) ; forgejo, nextcloud et keycloak `aucun` ; icingaweb2 `liste-uid` — il NOMME DES PERSONNES, ce que D-66 interdit. Le maillon manquant est chez Keycloak : `role_assignments` assigne un role a un UTILISATEUR, et son propre commentaire l'admettait (« en prod, preferer l'assignation via groupe d'annuaire »). Sans group-ldap-mapper, les groupes LDAP n'atteignent jamais les services. Sa meta a donc une autre forme, `acces_projection` : Keycloak projette au lieu de consommer (D-65). Defaut corrige : `serveur_icingaweb2_admins` valait "testmail", un compte de test code en dur dans le moteur qu'aucune instance ne surchargeait — le seul administrateur declare de la supervision etait un utilisateur inexistant. Il suit desormais l'uid d'amorcage. Verifie sur mon-01 : users = "sysadmin". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 13:59:33 -04:00
raison: >-
keycloak : realm-admin par appartenance, et la boucle de mot de passe `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>
2026-08-07 19:47:10 -04:00
Administration du realm : clients, mappers, politiques, utilisateurs.
Reference in a new issue Copy permalink