31 lines
1.3 KiB
YAML
31 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.
|