Daniel Allaire
5ecce4282a
Icinga Web 2 gagne un troisieme mode, locale : nginx authentifie en HTTP Basic et pose REMOTE_USER, l application le croit. Un SITE n a ni annuaire ni Keycloak — ce sont des services d ecosysteme. Ni backend LDAP ni backend de groupes : un backend qui vise une ressource inexistante fait echouer chaque ouverture de session. L habilitation nomme alors une personne, entorse a D-66 ecrite plutot que contournee. Deux pieges en chemin : resoudre_annuaire etait appele sans condition et tombait sur NoneType has no len (default sans son second argument ne remplace pas None), et le flux du role ne nommait que l edge — le site n en a pas, donc personne ne pouvait entrer. serveur_grafana portait deja la reponse. LE DEFAUT DU DEVIS : une sortie vers un role ABSENT de l ecosysteme retombait sur !SETOPS_INTERNES, la forme de vers l Internet. La frontiere aurait autorise la console a parler LDAPS a n importe quelle machine du monde, pour joindre un annuaire qui n existe pas. C est une source vide ouvre le port, cote destination. Trois regles du meme defaut etaient DEJA posees pour postfix. La frontiere n est pas ecrite : elle porte la production, et le devis attend un mot. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
36 lines
1.7 KiB
Django/Jinja
36 lines
1.7 KiB
Django/Jinja
; 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 %}
|