Set-OPS-Public/roles/serveur_icingaweb2/templates/authentication.ini.j2

; Géré par Set-OPS (rôle serveur_icingaweb2). Ne pas éditer à la main.
{% if serveur_icingaweb2_auth == 'locale' %}
; MODE `locale` : nginx a DEJA authentifie, et pose `REMOTE_USER`. Icinga Web 2 fait
; confiance a ce que le serveur web lui dit — c'est exactement le contrat du backend
; `external`, celui qu'emploie aussi le SSO. La difference n'est pas ici, elle est devant :
; une authentification HTTP Basic au lieu d'une passerelle OIDC.
;
; AUCUN BACKEND D'ANNUAIRE, parce qu'il n'y en a pas. Un site n'a ni LDAP ni Keycloak :
; ce sont des services d'ecosysteme. L'habilitation se fait donc par NOM dans `roles.ini`,
; et c'est ecrit la-bas pourquoi.
[icingaweb2]
backend = "external"
{% 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 %}