Problématiques rencontrées avec l'authentification NagVis

Lorsqu'un utilisateur utilise une instance de NagVis, il utilise des identifiants propres à cette installation de NagVis. Il est possible de gérer les utilisateurs et leur droit directement dans NagVis.

Lorsque NagVis est installé pour être utilisé de manière transparente avec Shinken Entreprise, cette fonctionnalité devient un problème puisqu'il devient nécessaire de synchroniser les bases d'utilisateurs de Shinken et de NagVis. Dans Shinken, une base d'utilisateurs est déjà présente.

Pour simplifier la gestion de l'authentification entre NagVis et Shinken, plusieurs modules ont été ajoutés dans NagVis.

Fonctionnement de l'authentification de NagVis

Pour plus d'informations sur les modules disponibles par défaut, la documentation NagVis présente un récapitulatif des fonctionnalités disponibles: 

• http://docs.nagvis.org/1.9/en_US/index.html

Solutions d'authentification mises en place

Pour permettre une gestion de l'authentification transparente entre Shinken et NagVis, plusieurs modules ont été ajoutés.

Configuration générale

Pour permettre la liaison de l'authentification avec Shinken, les différents modules utilisés pour la connexion ont besoin de savoir quelle est l'adresse de l'installation Shinken avec laquelle il lui faut se connecter.

De manière plus précise, pour se connecter avec Shinken, NagVis utilise le module WebUI (l'interface de visualisation).

Plusieurs paramètres sont ajoutés pour spécifier l'installation Shinken à contacter:

Ces paramètres peuvent être modifiés de 2 manières différentes:

• Par le fichier de configuration de NagVis:

; Defines the authentication module to use. By default NagVis uses the built-in
; SQLite authentication module. On delivery there is no other authentication
; module available. It is possible to add own authentication modules for
; supporting other authorisation mechanisms. For details take a look at the
; documentation.
authmodule="CoreAuthModShinken"

; - CoreAuthorisationModMySQL: Uses the same data structure as the SQLite authorisation
;   module, but stores the data in a MySQL database.
; - CoreAuthorisationModMultisite: Uses information exported by Check_MKs Multisite
;   to gather user permissions. This makes use of the roles defined for a user within
;   multisite and the resulting permissions.
; - CoreAuthorisationModGroups: Assumes all users which should access NagVis are
;   available in your monitoring core as contacts and assigned to contactgroups. Those
;   contact group memberships are matched against a mapping table, which is defined in
;   nagvis/etc/perms.db. This mapping table defines the permissions of each contact
;   group within NagVis. Take a look at the docs for details.
;
; It is possible to add own authorisation modules for supporting other authorisation
; mechanisms. For details take a look at the documentation.
authorisationmodule="CoreAuthorisationModShinkenGroups"


; Protocol to use when authenticating with Shinken (http or https) when using the CoreAuthModShinken authentication module
;shinken_auth_protocol="http"
; Port of broker webui
;shinken_auth_port=7767
; Address of broker webui. If not specified, address of default backend is used instead
;shinken_auth_address=""
; Name of the HTTP header to use to perform SSO authentication with Shinken.
; This value must be the same as the one configured in Shinken. An empty value means authentication by http header is disabled.
;shinken_auth_remote_user_variable=""
; Authorize authentication into NagVis to Shinken administrators only
;shinken_auth_restrict_to_shinken_admin=1

...

; LogonMixed: The mixed logon module uses the LogonEnv module as default and
;   the LogonDialog module as fallback when LogonEnv returns no username. This
;   should fit the requirements of most environments.
;

...

logonmodule="LogonShinkenMixed"

Modules de login

Utilisation d'entêtes HTTP

Nom du module: CoreLogonShinkenHeader

Lorsque la connexion par SSO est activée dans Shinken (Synchronizer - Authentification unique ( SSO )), il est alors possible d'utiliser cette fonctionnalité pour se connecter dans NagVis en utilisant les mêmes entêtes HTTP que ceux utilisés pour Shinken.

L'entête utilisé dans NagVis doit être le même que celui utilisé dans l'interface de Visualisation de Shinken. Pour utiliser l'authentification par SSO dans NagVis avec le module fourni par Shinken, l'authentification par entête HTTP doit également être activée dans Shinken sur l'UI de Visualisation.

Le nom de l'entête contenant le nom d'utilisateur doit être spécifié dans NagVis avec le paramètre "shinken_auth_remote_user_variable".

; Name of the HTTP header to use to perform SSO authentication with Shinken.
; This value must be the same as the one configured in Shinken. An empty value means authentication by http header is disabled.
;shinken_auth_remote_user_variable=""

Lorsque cette variable est vide, l'authentification par entête HTTP est désactivée. Par défaut, l'utilisation des entêtes HTTP est donc désactivée dans NagVis.

Utilisation des cookies des interfaces Web Shinken

Nom du module: CoreLogonShinkenCookie

Ce module utilise les cookies des interfaces Web de Shinken Entreprise. Lorsque l'utilisateur est connecté dans une interface (interface de Configuration ou interface de Visualisation), il sera donc automatiquement connecté dans NagVis. La connexion peut être restreinte aux administrateurs Shinken grâce au paramètre "shinken_auth_restrict_to_shinken_admin".

Formulaire de connexion

Nom du module: CoreLogonDialog

Ce module est le module par défaut de connexion NagVis. Il affiche un formulaire qui demande à l'utilisateur d'entrer son nom d'utilisateur et son mot de passe pour se connecter dans NagVis.

Lorsqu'il est utilisé avec le module d'authentification "CoreAuthModShinken", les identifiants entrés dans le formulaire seront vérifiés avec Shinken.

Agrégation des modules précédents

Nom du module: CoreLogonShinkenMixed (par défaut)

Ce module rassemble les différents modes de connexion précédents en un seul module. Le fonctionnement du module est le suivant:

• Tentative de connexion en utilisant les entêtes HTTP
• Si l'authentification avec entête HTTP échoue (utilisateur invalide, entête HTTP non défini), le module tente de connecter l'utilisateur en utilisant le cookie des interfaces Web Shinken.
• Si l'authentification par cookie a échoué, le formulaire de connexion est présenté à l'utilisateur.

Modules d'authentification

Authentification avec Shinken Entreprise

Nom du module: CoreAuthModShinken (par défaut)

Ce module utilise les données de connexion fournies par le module de login et vérifie auprès de Shinken (en particulier l'interface de visualisation) si les identifiants correspondent bien à un utilisateur Shinken existant.

Le comportement de ce module est configurable avec les variables définies dans la section précédente sur la configuration générale des modules d'authentification.

Modules d'autorisation

Définition des droits selon le profil Shinken

Nom du module: CoreAuthorisationModShinken (par défaut)

Ce module définit des droits par défaut pour un utilisateur connecté avec Shinken. Ces droits, non configurables, sont les suivants:

• Visualisation en lecture seule de toutes les cartes définies
• Visualisation en lecture seule des rotations définies dans NagVis (plus d'information sur les rotations dans la documentation NagVis: http://docs.nagvis.org/1.9/en_US/nagvis_config_format_description.html#rotation)
• Modification autorisée de la configuration générale de NagVis

Définition des droits selon les groupes d'utilisateurs

Nom du module: CoreAuthorisationModShinkenGroups

Ce module est très similaire au module "CoreAuthorisationModGroups" présent dans une installation NagVis classique. Il permet de définir les droits utilisateurs en fonction des groupes d'utilisateur Shinken dans lequel l'utilisateur est présent.

Authentification avec le widget Page Web

Pour fonctionner avec le widget Page Web, certains site comme Grafana ou NagVis nécessite quelques modifications. L'authentification se fait avec des cookies. Dans les dernières versions de Chrome/Internet Explorer/Edge (Firefox n'est pas concerné), l'utilisation de requête "cross-site" par un cookie n'est plus autorisé. Ça signifie que si l'application n'est pas installé sur le même serveur que la WebUI de Shinken, l'authentification depuis le widget Page Web ne fonctionnera pas.

Pour palier a ce problème, nous allons utiliser HAProxy (Version 1.5.18) pour récupérer le flux de ce site et simuler sa présence sur le serveur où est installé la WebUI.

Dans le cas ou vous souhaitez afficher la carte NagVis qui n'est pas installé sur le serveur ou se trouve la WebUI Shinken. Il faut installer HAProxy sur chacun des serveurs ou vous souhaitez afficher ces graphes dans le widget Page Web.

yum install haproxy

Ajouter une exception dans SELinux pour HAProxy:

setsebool -P haproxy_connect_any=1

Modifier le fichier de configuration /etc/haproxy/haproxy.cfg et le remplir avec ces informations :

#---------------------------------------------------------------------
# Example configuration for a possible web application.  See the
# full configuration options online.
#
#   http://haproxy.1wt.eu/download/1.4/doc/configuration.txt
#
#---------------------------------------------------------------------

#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
    # to have these messages end up in /var/log/haproxy.log you will
    # need to:
    #
    # 1) configure syslog to accept network log events.  This is done
    #    by adding the '-r' option to the SYSLOGD_OPTIONS in
    #    /etc/sysconfig/syslog
    #
    # 2) configure local2 events to go to the /var/log/haproxy.log
    #   file. A line like the following can be added to
    #   /etc/sysconfig/syslog
    #
    #    local2.*                       /var/log/haproxy.log
    #
    log         127.0.0.1 local2

    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon

    # turn on stats unix socket
    stats socket /var/lib/haproxy/stats

#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000

listen  nagvis
  bind    ERVEUR_WEBUI:800
  server SERVEUR_NAGVIS SERVEUR_NAGVIS:80

Démarrer HAProxy

systemctl enable haproxy
systemctl start haproxy

Vous pouvez ajouter l'URL suivante dans le widget Page Web : http://SERVEUR_WEBUI:800/nagvisXXXX mais pas http://SERVEUR_NAGVIS/nagvisXXXX La première authentification est nécessaire.

Log HAProxy

Par défaut HAProxy n'a pas de fichier de log. Si vous souhaitez en générer un il faut :

Éditer le fichier /etc/rsyslog.conf et décommenter les lignes suivantes :

$ModLoad imudp
$UDPServerRun 514

Créer et ajouter dans le fichier /etc/rsyslog.d/haproxy.conf :

local2.* /var/log/haproxy.log

Redémarrer rsyslog et haproxy :

systemctl restart rsyslog
systemctl restart haproxy