Daniel Allaire
6f2acafdb6
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>
30 lines
1.3 KiB
YAML
30 lines
1.3 KiB
YAML
---
|
|
# 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:
|
|
# /!\ LA PROJECTION N'EXISTE PAS. `serveur_keycloak_role_assignments` assigne
|
|
# un role a un UTILISATEUR, nommement — ce que D-66 interdit. Le commentaire du
|
|
# role l'admettait deja : « En prod, preferer l'assignation via groupe
|
|
# d'annuaire ; ici, explicite pour la preuve. »
|
|
#
|
|
# Sans mapper `group-ldap-mapper` + politique role<-groupe, la chaine s'arrete
|
|
# ici : les groupes LDAP n'atteignent jamais les services. Constate le
|
|
# 2026-08-07, au moment d'ecrire les meta/acces.yml des cinq roles web.
|
|
- groupe: sysadmin
|
|
projette: [grafana-admin]
|
|
porte_par: aucun
|
|
raison: >-
|
|
Le groupe d'administration doit devenir le role de realm que Grafana lit
|
|
dans le claim `roles`.
|
|
|
|
# Ce que Keycloak accorde SUR LUI-MEME (sa propre console d'administration).
|
|
acces:
|
|
- groupe: sysadmin
|
|
accorde: realm-admin
|
|
porte_par: aucun
|
|
raison: >-
|
|
Administration du realm : clients, mappers, politiques. Aujourd'hui seul le
|
|
compte local `admin` (voute) l'obtient.
|