Daniel Allaire
51dae506fb
L exploitant : Icinga Web 2 permet nativement de gerer des comptes ; ce genre d intervention n est pertinente que pour integrer Icinga a Keycloak chez les tenants. Le mode locale posait un auth_basic nginx devant le backend external. Ca marchait, et ca reinventait une page de connexion devant une application qui en a une — en privant l exploitant de la gestion des comptes dans l interface. Un vestibule n a de sens que devant une application qui ne sait pas s authentifier ; le GUI de Set-OPS est dans ce cas, Icinga Web 2 non. Mode db : backend natif, groupes natifs, base a elle (les tables du moteur sont reecrites par ses migrations). Le moteur pose UN compte d amorcage et ne l ecrase jamais. D-66 redevient applicable sans annuaire, les groupes vivant en base. Deux pieges du renommage : une garde ecrite en negation a cesse de garder, et le bloc de la base pose apres le rendu des .ini a produit un echec CENSURE par no_log. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
35 lines
1.6 KiB
Django/Jinja
35 lines
1.6 KiB
Django/Jinja
; Géré par Set-OPS (rôle serveur_icingaweb2). Ne pas éditer à la main.
|
|
{% if serveur_icingaweb2_auth == 'db' %}
|
|
; MODE `db` : Icinga Web 2 gere ses comptes LUI-MEME, dans sa propre base, avec sa propre
|
|
; page de connexion. C'est la reponse pour un ecosysteme sans annuaire — un SITE.
|
|
;
|
|
; AUCUN VESTIBULE DEVANT. La premiere ecriture posait un `auth_basic` nginx et faisait
|
|
; confiance a `REMOTE_USER` : ca reinventait une page de connexion devant une application
|
|
; qui en a une, et ca privait l'exploitant de la gestion des comptes dans l'interface.
|
|
[icingaweb2]
|
|
backend = "db"
|
|
resource = "icingaweb_db"
|
|
{% elif serveur_icingaweb2_auth == 'external' %}
|
|
; SSO : l'utilisateur est fourni par la passerelle (oauth2-proxy → Keycloak) via REMOTE_USER.
|
|
[icingaweb2]
|
|
backend = "external"
|
|
|
|
; Backend LDAP declare mais JAMAIS utilise pour authentifier : l'externe repond en
|
|
; premier. Il sert au backend de GROUPES, qui doit resoudre un nom d'utilisateur vers
|
|
; son DN — les membres d'un `groupOfNames` sont des DN, pas des uid.
|
|
; Sans lui, l'habilitation par groupe est impossible en mode SSO, et il faudrait
|
|
; nommer des personnes (ce que D-66 interdit).
|
|
[ldap-annuaire]
|
|
backend = "ldap"
|
|
resource = "icingaweb_ldap"
|
|
user_class = "{{ serveur_icingaweb2_ldap_user_class }}"
|
|
user_name_attribute = "{{ serveur_icingaweb2_ldap_user_attr }}"
|
|
base_dn = "{{ serveur_icingaweb2_ldap_users_dn }}"
|
|
{% else %}
|
|
[icingaweb2]
|
|
backend = "ldap"
|
|
resource = "icingaweb_ldap"
|
|
user_class = "{{ serveur_icingaweb2_ldap_user_class }}"
|
|
user_name_attribute = "{{ serveur_icingaweb2_ldap_user_attr }}"
|
|
base_dn = "{{ serveur_icingaweb2_ldap_users_dn }}"
|
|
{% endif %}
|