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>
18 lines
794 B
YAML
18 lines
794 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 pas de mapping de groupes OIDC. L'administration passe donc par
|
|
# le compte local de secours (voute, `occ`), ce qui contredit « une identite,
|
|
# un mot de passe ». Constate le 2026-08-07.
|
|
# `user_oidc` sait mapper un claim de groupes : c'est le cablage manquant.
|
|
porte_par: aucun
|
|
raison: >-
|
|
Administration : utilisateurs, quotas, applications, partages.
|
|
- groupe: personnel
|
|
accorde: utilisateur
|
|
porte_par: defaut # tout utilisateur authentifie
|
|
raison: >-
|
|
Son espace de fichiers et ses partages. C'est le niveau par defaut.
|