---
# 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.