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>
19 lines
844 B
YAML
19 lines
844 B
YAML
---
|
|
# Habilitations reconnues par ce service. Voir docs/autorisation.md.
|
|
acces:
|
|
- groupe: sysadmin
|
|
accorde: admin
|
|
# /!\ AUCUN mecanisme ne porte cette habilitation aujourd'hui : le role ne
|
|
# configure ni claim de groupe, ni mapping d'equipe. Toute personne qui
|
|
# s'authentifie obtient le niveau par defaut, et le compte administrateur
|
|
# reste le compte local de secours (voute).
|
|
# Forgejo sait lire un claim OIDC de groupes (`GROUP_CLAIM_NAME` +
|
|
# `ADMIN_GROUP`) : c'est le cablage manquant. Constate le 2026-08-07.
|
|
porte_par: aucun
|
|
raison: >-
|
|
Administration de la forge : utilisateurs, organisations, reglages.
|
|
- groupe: dev
|
|
accorde: utilisateur
|
|
porte_par: defaut # tout utilisateur authentifie
|
|
raison: >-
|
|
Creation de depots et contribution. C'est le niveau par defaut.
|