Authentification et autorisations¶
Installation¶
Pré-requis logiciels¶
La configuration de l’authentification dans Vigilo nécessite l’installation des logiciels suivants :
- python (>= 2.5), sur la machine à configurer
vigilo-turbogears
, installé automatiquement par les interfaces web de Vigilo
Reportez-vous aux manuels de ces différents logiciels pour savoir comment procéder à leur installation sur votre machine.
Le paquet vigilo-turbogears
requiert également la présence de plusieurs
dépendances Python. Ces dépendances seront automatiquement installées en même
temps que le paquet vigilo-turbogears
.
Comptes par défaut¶
Un compte par défaut est créé lors de l’installation de Vigilo, appelé « manager ». Ce compte correspond à un utilisateur disposant de tous les droits (super-utilisateur). Il n’a pas vocation à être utilisé en cours d’exploitation, mais plutôt à permettre des interventions ponctuelles liées à des tâches d’administration.
Le mot de passe par défaut de ce compte est iddad
. Ce mot de passe peut
être modifié depuis une machine sur laquelle Vigilo est installé, via la ligne
de commandes en exécutant la commande vigilo-passwd, à partir du compte de
l’utilisateur root
.
Phases de l’authentification¶
Le mécanisme d’authentification de Vigilo repose sur le framework
repoze.who
. La gestion des autorisations repose sur le framework
repoze.what
.
Les interfaces graphiques de Vigilo utilisent les prédicats définies dans
repoze.what
afin de restreindre l’accès à certaines fonctionnalités. Ces
prédicats peuvent nécessiter que l’utilisateur soit authentifié, appartienne à
un groupe d’utilisateurs particulier ou dispose d’une permission spéciale. Ce
document ne revient pas sur ce mécanisme de gestion des autorisations mais
insiste plutôt sur l’authentification de l’utilisateur, qui permet d’établir
les groupes auxquels il appartient et les permissions dont il dispose. Le
lecteur pourra consulter la documentation du projet repoze.what
pour plus
d’information sur les mécanismes d’autorisation consulter la documentation de
Repoze. L’authentification se déroule en
plusieurs phases :
- phase de classification, qui permet de savoir d’où provient la requête en cours de traitement (par exemple, provient-elle d’un navigateur web ou s’agit-il d’une requête interne à Vigilo ?),
- phase d’identification, chargée de reconnaître l’utilisateur lorsqu’il se connecte,
- phase d’authentification, chargée de vérifier l’identité de l’utilisateur,
- phase de « challenge », permettant de demander des informations à l’utilisateur afin de l’authentifier,
- phase d’enrichissement à l’aide de fournisseurs de méta-données, permettant d’associer des méta-données à la session de l’utilisateur authentifié.
Fichier de configuration¶
La configuration de l’authentification se fait en créant un fichier INI. Ce fichier INI utilise le format suivant:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | [plugin:foo]
use = bar.baz.foo:FooPlugin
param_foo_1 = valeur1
param_foo_2 = valeur2
[general]
request_classifier = bar.baz:Classifier
challenge_decider = bar.baz:Challenger
[identifiers]
plugins =
foo
[authenticators]
plugins =
foo
[challengers]
plugins =
foo
[mdproviders]
plugins =
foo
|
La documentation du framework repoze.who
contient
de plus amples informations.
Lien avec les phases de l’authentification¶
Le contenu du fichier de configuration suit de près les différentes phases de
l’authentification. Tout d’abord, des modules sont configurés, à l’aide de
sections plugin:
, puis ceux-ci sont associés aux différentes étapes de
l’authentification à l’aide des sections identifiers
(identification),
authenticators
(authentification), challengers
(challenge) et
mdproviders
(fournisseurs de méta-données).
La section general
contient la configuration pour l’étape de
classification, ainsi que des paramètres généraux, qui ne sont pas liés aux
différentes étapes.
La suite de ce document décrit plus en détail le contenu des différentes sections du fichier de configuration.
Sections plugin:
¶
Les sections dont le nom commence par plugin:
correspondent à la
configuration d’un module qui pourra être utilisé dans le cadre de la
configuration de l’authentification. Le libellé après les deux points « : »
correspond à un alias qui sera affecté au plugin.
La clé use
permet de spécifier l’emplacement de la fonction ou de la classe
Python implémentant le module. L’emplacement du module est donné en utilisant
la syntaxe : module.python:ClassOuFonction
. Les autres clés de la section
correspondent aux différents paramètres attendus par le module.
Tous les modules définis par défaut dans repoze.who sont utilisables ici [1].
[1] | La liste complète des modules est disponible à l’adresse : http://docs.repoze.org/who/1.0/narr.html#module-repoze.who.plugins.sql |
Vigilo fournit également le module d’identification et d’authentification
repoze.who.plugins.vigilo.kerberos:VigiloKerberosAuthenticator
permettant
d’utiliser un annuaire LDAP et la méthode Kerberos pour l’authentification des
utilisateurs.
Sections identifiers
, authenticators
, challengers
et mdproviders
¶
Les sections identifiers
, authenticators
, challengers
et
mdproviders
permettent de définir les modules à utiliser au cours des
phases décrites au chapitre Phases de l’authentification.
Chacune de ces sections ne contient qu’une seule clé, appelée plugins
,
qui contient la liste des modules à appeler, à l’aide des alias définis pour
ces modules lors de leur configuration (voir le chapitre
Fichier de configuration).
La liste des modules doit être écrites à la ligne, indentée, avec un module par
ligne. Il est possible de n’appliquer un module que pour une classification
particulière (voir la fonction request_classifier
décrite dans la
Section general du chapitre Fichier de configuration) en
suffixant le nom du module par « ; » suivi de la classification pour laquelle
il agit.
Exemple de configuration possible pour les challengers
:
1 2 3 4 | [challengers]
plugins =
friendlyform;browser
basicauth;vigilo-api
|
Ici, le module friendlyform
est appelé lorsque la fonction de
classification attribue la classification browser
à la requête, tandis
qu’elle appelle le module basicauth
lorsque la classification renvoyée est
vigilo-api
.
Section general
¶
La section general
contient deux options :
request_classifier
permet de classer les requêtes (par exemple, selon leur origine). Il s’agit d’une fonction qui sera appelée à chaque requête et renvoie une chaîne de caractères décrivant la classification de la requête. Cette fonction est indiquée en utilisant la même syntaxe que pour la définition des modules, à savoir :module.python:ClasseOuFonction
.Vigilo fournit la fonction
vigilo.turbogears.repoze_plugins:vigilo_api_classifier
qui permet de distinguer les requêtes provenant d’un navigateur web des requêtes provenant de l’API interne de Vigilo.challenge_decider
permet de définir une fonction qui sera appelée pour décider si la requête actuelle nécessite d’obtenir de plus amples informations sur l’utilisateur afin de pouvoir l’authentifier. Si la réponse est positive, alors les plugins définis dans la sectionchallengers
sont utilisés.Vigilo utilise le module de challenge standard de
repoze.who
(implémenté par la fonctionrepoze.who.classifiers:default_challenge_decider
) pour décider si des informations supplémentaires sont nécessaires au traitement de la demande d’authentification.
Authentification externe¶
Dans le cas où l’authentification doit se faire en utilisant une source externe (ex : annuaire LDAP), la configuration du fichier de gestion de l’authentification (who.ini) doit être adaptée, ainsi que la configuration des diverses interfaces graphiques de Vigilo.
Dans ce chapitre, nous allons mettre en place une solution d’authentification unique (Single Sign-On) basée sur l’utilisation de la méthode d’authentification Kerberos auprès d’un annuaire LDAP.
On suppose que l’infrastructure nécessaire est déjà en place (un annuaire LDAP, un KDC et éventuellement une PKI). On suppose également que l’annuaire LDAP en place contient des informations sur les autorisations accordées aux différents utilisateurs (par exemple, la liste des groupes auxquels un utilisateur à accès, et donc les éléments du parc ou les applications qu’il est susceptible de consulter).
Le chapitre Configuration d’Apache avec Kerberos donne un exemple de configuration du module mod_auth_kerb d’Apache, permettant d’authentifier les utilisateurs grâce à la méthode Kerberos.
Le chapitre Adaptation du fichier who.ini décrit les modifications apportées au fichier who.ini afin d’utiliser le ticket Kerberos transmis par Apache au sein des interfaces graphiques de Vigilo. Ce ticket sera notamment utilisé pour interroger un annuaire LDAP et obtenir des informations sur l’utilisateur actuellement connecté (nom complet, adresse email, groupes dont il est membre).
Enfin, le chapitre Configuration du navigateur web des exploitants décrit la configuration à apporter au sein du navigateur web afin de permettre l’utilisation de Kerberos comme méthode d’authentification.
Configuration d’Apache avec Kerberos¶
Afin d’utiliser Kerberos comme méthode d’authentification, le module
mod_auth_kerb
d’Apache doit être configuré afin de pouvoir décoder le
ticket Kerberos transmis par le navigateur web des utilisateurs (voir aussi le
chapitre Configuration du navigateur web des exploitants pour la
configuration à apporter dans le navigateur web).
Le listing suivant montre comment charger le module mod_auth_kerb
dans Apache pour activer le support de Kerberos:
1 2 3 | <IfModule !mod_auth_kerb.c>
LoadModule auth_kerb_module extramodules/mod_auth_kerb.so
</IfModule>
|
Le chargement du module n’est fait que s’il n’était pas déjà chargé (cette
vérification est faite grâce à l’encapsulation dans la directive IfModule à la
ligne 1). La directive LoadModule
à la ligne 2 donne le nom du point
d’entrée à charger dans le module (auth_kerb_module
dans le cas du
module mod_auth_kerb), ainsi que l’emplacement du module. Le module peut être
installé à un autre endroit sur la machine, en fonction de la distribution
Linux utilisée.
Une fois le module chargé, il faut adapter la configuration Apache des différentes applications (fichiers « vigiboard.conf », « vigimap.conf » et « vigigraph.conf » du répertoire /etc/httpd/conf.d/).
Le listing suivant donne un exemple de configuration de VigiBoard dans Apache afin de gérer l’authentification Kerberos. Ce fichier se trouve dans /etc/httpd/conf.d/vigiboard.conf:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 | <IfModule mod_wsgi.c>
WSGISocketPrefix /var/run/wsgi
WSGIRestrictStdout off
WSGIPassAuthorization on
WSGIDaemonProcess vigiboard user=apache group=apache processes=4 threads=1
WSGIScriptAlias /vigilo/vigiboard "/etc/vigilo/vigiboard/vigiboard.wsgi"
KeepAlive Off
<Directory "/etc/vigilo/vigiboard/">
<IfModule mod_headers.c>
Header set X-UA-Compatible "IE=edge"
</IfModule>
<Files "vigiboard.wsgi">
WSGIProcessGroup vigiboard
WSGIApplicationGroup %{GLOBAL}
<IfModule mod_authz_core.c>
# Apache 2.4
Require all granted
</IfModule>
<IfModule !mod_authz_core.c>
# Apache 2.2
Order Deny,Allow
Allow from all
</IfModule>
</Files>
</Directory>
<Location "/vigilo/vigiboard/login">
AuthType kerberos
AuthName "Kerberos"
KrbServiceName HTTP
KrbAuthRealms EXAMPLE.COM
Krb5Keytab /etc/httpd/conf/HTTP.vigilo.example.com.keytab
KrbMethodNegotiate on
KrbMethodK5Passwd off
KrbSaveCredentials on
KrbVerifyKDC on
Require valid-user
</Location>
</IfModule>
|
Avec cette configuration, seule l’URL
http://vigilo.example.com/vigilo/vigiboard/login
est protégée par une
authentification Kerberos. Les autres pages redirigent vers celle-ci
lorsqu’un utilisateur authentifié est attendu et que l’utilisateur courant
ne l’est pas. Cette solution offre le meilleur compromis possible entre la
sécurité (il n’est pas possible d’accéder à une ressource protégée sans être
authentifié) et les performances (une seule authentification par session).
La ligne 21 indique qu’Apache doit procéder à une authentification de type
« kerberos » afin d’autoriser l’accès à l’application (directive AuthType
).
La ligne 22 permet d’associer un nom à cette méthode d’authentification
(directive AuthName
). Ce nom apparaîtra dans les journaux d’événements du
serveur.
La ligne 23 spécifie le nom du service Kerberos qui sera utilisé pour procéder
à l’authentification (directive KrbServiceName
). La valeur par défaut est
« HTTP » qui correspond à la valeur recommandée.
La ligne 24 indique le nom du domaine Kerberos dans lequel l’authentification a
lieu (directive KrbAuthRealms
). Par convention, il s’agit du nom de domaine
du parc, en majuscules.
La ligne 25 spécifie l’emplacement du fichier contenant la clé secrète
d’authentification de ce service (directive Krb5Keytab
). Ce fichier
doit être accessible par le serveur web (et uniquement celui-ci).
La directive KrbMethodNegotiate
à la ligne 26 autorise la négociation de
la méthode d’authentification entre le navigateur et le serveur web. Il est
recommandé d’autoriser la négociation.
La ligne 27 désactive l’authentification à la volée par identifiant/mot de
passe (directive KrbMethodK5Password
). Cette directive peut être positionnée
à « on » pour autoriser les utilisateurs à s’authentifier à la volée auprès du
serveur web. Si l’utilisateur tente de se connecter à l’application alors qu’il
ne dispose pas d’un ticket Kerberos valide, une boîte de dialogue l’invite à
saisir son identifiant et son mot de passe. La suite du processus
d’authentification se déroule alors comme si un ticket Kerberos avait été
transmis. Dans un environnement configuré pour n’utiliser que Kerberos (et ce
dès l’ouverture d’une session au démarrage des postes utilisateurs), il est
conseillé de positionner cette directive à « off ». Dans les autres cas, il est
recommandé de positionner cette directive à « on » pour permettre aux
utilisateurs ne disposant pas des outils nécessaires sur leur machine de
pouvoir s’authentifier malgré tout.
La directive KrbSaveCredentials
à la ligne 28 permet de sauvegarder
temporairement le ticket Kerberos de l’utilisateur afin de permettre à
l’application d’interroger d’autres services en utilisant la méthode Kerberos.
Cette option est nécessaire dans les interfaces graphiques lorsque l’accès à
Nagios se fait via une authentification Kerberos, afin de propager le ticket
Kerberos reçu et maintenir la traçabilité des accès. Le fichier contenant le
ticket Kerberos est supprimé automatiquement à la fin de la requête.
La directive KrbVerifyKdc
à la ligne 29 désactive la vérification de
l’identité du KDC du parc. Pour plus de sécurité, il est recommandé de
positionner cette directive à la valeur « on ». L’activation de cette option
nécessite cependant une configuration plus avancée de l’infrastructure
Kerberos, qui dépasse le cadre de ce document.
La directive Require
(ligne 32) indique que l’utilisateur doit dispose
d’un compte valide dans la base Kerberos pour pouvoir accéder à l’application.
Enfin, la directin Allow
(ligne 33) indique que n’importe quel machine
est autorisée à se connecter à l’application, quelle que soit son adresse IP.
Adaptation du fichier who.ini¶
La prise en charge de Kerberos comme méthode d’authentification dans Vigilo
se fait en paramétrant le fichier « who.ini » des interfaces graphiques
(VigiMap, VigiGraph et VigiBoard), selon la méthode présentée dans ce
chapitre. Lorsque Kerberos est utilisé comme méthode d’authentification,
l’identifiant Kerberos de l’utilisateur est transmis à l’application
au travers de la variable CGI REMOTE_USER
.
Le listing ci-dessous présente un exemple complet de configuration permettant de synchroniser les comptes utilisateurs dans Vigilo avec un annuaire LDAP externe, tout en utilisant l’identité Kerberos obtenue depuis le serveur web :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 | [plugin:auth_tkt]
use = repoze.who.plugins.auth_tkt:make_plugin
secret = vigilo
cookie_name = authtkt
[plugin:basicauth]
use = repoze.who.plugins.basicauth:make_plugin
realm=Vigilo
[plugin:friendlyform]
use = repoze.who.plugins.friendlyform:FriendlyFormPlugin
login_form_url= /login
login_handler_path = /login_handler
logout_handler_path = /logout_handler
rememberer_name = auth_tkt
post_login_url = /post_login
post_logout_url = /post_logout
[plugin:ldapsync]
use = vigilo.turbogears.repoze.plugins.mdldapsync:VigiloLdapSync
ldap_url = ldap://ldap.example.com
ldap_base = ou=people,dc=example,dc.com
filterstr= (&(uid=%s)(objectClass=*))
ldap_charset = cp1252
http_charset = utf-8
cache_name = vigilo
binddn = mybinduser
bindpw = mybindpassword
attr_cn = cn
attr_mail = mail
attr_member_of = memberOf
timeout = 3
[plugin:externalid]
use = vigilo.turbogears.repoze.plugins.externalid:ExternalIdentification
cache_name = vigilo
[general]
request_classifier = vigilo.turbogears.repoze.classifier:vigilo_classifier
challenge_decider = repoze.who.classifiers:default_challenge_decider
[identifiers]
plugins =
friendlyform;browser
basicauth;vigilo-api
auth_tkt
externalid;browser
[authenticators]
plugins =
vigilo.turbogears.repoze.plugins.sqlauth:plugin
[challengers]
plugins =
friendlyform;browser
basicauth;vigilo-api
[mdproviders]
plugins =
ldapsync
vigilo.turbogears.repoze.plugins.mduser:plugin
vigilo.turbogears.repoze.plugins.mdgroups:plugin
|
Le module ldapsync
(classe
vigilo.turbogears.repoze.plugins.mdldapsync:VigiloLdapSync
) défini aux
lignes 19 à 31 est responsable de la récupération des informations depuis
l’annuaire LDAP à partir de l’identité Kerberos de l’utilisateur.
Les paramètres du module ldapsync
sont les suivants :
ldap_url
- Emplacement de l’annuaire LDAP, sous la forme d’une URL. Exemple :
ldap://ldap.example.com
. ldap_base
- Base de recherche de l’utilisateur dans l’annuaire LDAP, sous la forme
d’un Distinguished Name. Exemple :
ou=People,dc=ldap,dc=example,dc=com
. filterstr
Chaine de filtrage des résultats obtenus par la recherche. Exemple :
sAMAccountName=%
.Cette chaîne de caractères peut contenir la variable de substitution « %s » qui sera remplacée par l’identifiant Kerberos (principal) de l’utilisateur, privé du nom du domaine (par exemple : « vigilo » si le principal Kerberos est « vigilo@EXAMPLE.COM »).
La variable du substitution ne peut être utilisée qu’une seule fois. Par défaut, le filtre utilisé est
(objectClass=*)
.ldap_charset
Encodage des caractères utilisé par l’annuaire. Cet encodage sera utilisé afin de décoder correctement les valeurs transmises par l’annuaire. Les noms d’encodages valides sont ceux définis par Python [2].
Par défaut, l’encodage utilisé est
utf-8
.http_charset
Ce paramètre est similaire au paramètre « ldap_charset » mais s’applique au serveur web. Il est utilisé afin de décoder correctement le principal Kerberos.
Par défaut, l’encodage utilisé est « utf-8 ».
cache_name
- Nom d’une clé qui sera définie dans la session de l’utilisateur afin de
stocker son identité [3]. Cette clé est ensuite utilisée par la classe
vigilo.turbogears.repoze.plugins.externalid:ExternalIdentification
pour authentifier automatiquement l’utilisateur lors des accès suivants. binddn
- DN (optionnel) à utiliser pour se connecter à l’annuaire LDAP (bind). Si ce paramètre n’est pas renseigné, le jeton Kerberos de l’utilisateur est transmis à l’annuaire afin de procéder à un bind par Kerberos (GSSAPI).
bindpw
- Mot de passe associé au DN indiqué dans le paramètre « binddn ».
attr_cn
- Nom de l’attribut (mono-valué) dans l’annuaire permettant d’obtenir le nom usuel (Common Name) de l’utilisateur. La valeur par défaut est « cn », ce qui correspond au nom de cet attribut dans un schéma LDAP classique.
attr_mail
- Nom de l’attribut (mono-valué) dans l’annuaire permettant d’obtenir l’adresse de courrier électronique de l’utilisateur. La valeur par défaut est « mail », ce qui correspond au nom de cet attribut dans un schéma LDAP classique.
attr_member_of
- Nom de l’attribut (multivalué) dans l’annuaire qui identifie les groupes dont l’utilisateur est membre. La valeur par défaut est « memberOf », ce qui correspond au nom de cet attribut dans un schéma LDAP classique.
Le module externalid
(classe
vigilo.turbogears.repoze.plugins.externalid:ExternalIdentification
) défini
aux lignes 33 à 35 est quant à lui utilisé pour mémoriser le fait que
l’utilisateur s’est authentifié à l’aide d’un mécanisme d’authentification
externe (ici, Kerberos) afin d’authentifier automatiquement cet utilisateur
lorsqu’il tente d’accéder à une page dont l’accès est restreint.
Les paramètres du modules externalid
sont les suivants :
cache_name
- Nom d’une clé dans la session contenant l’identité de l’utilisateur.
Il doit s’agir de la même valeur que pour l’option cache_name
du module
ldapsync
(de la classevigilo.turbogears.repoze.plugins.mdldapsync:VigiloLdapSync
).
La ligne 46 indique au framework d’authentification d’utiliser le
module d’authentification externalid
défini plus haut, afin
d’authentifier automatiquement l’utilisateur s’il s’était identifié
au préalable auprès du serveur via Kerberos.
La ligne 59 permet quant à elle d’utiliser le module ldapsync
afin de
synchroniser automatiquement la base de données Vigilo avec les informations
issues de l’annuaire LDAP lorsque l’utilisateur s’authentifie via un
mécanisme d’authentification externe (ici, Kerberos).
[2] | http://docs.python.org/library/codecs.html#standard-encodings |
[3] | Pour le moment, seule la valeur vigilo est fonctionnelle.
Les interfaces de Vigilo supposent qu’il s’agit du nom de cette clé
et ne fonctionneront pas correctement si une autre valeur est utilisée ici. |
Vérification du bon fonctionnement¶
La manière la plus simple de vérifier le bon fonctionnement de l’authentification Kerberos consiste simplement à se connecter à l’une des interfaces web de Vigilo.
Si vous ne disposez pas encore d’un ticket Kerberos valide et que la directive
KrbMethodK5Passwd
a été positionnée à « on » sur le serveur (voir le
chapitre Configuration d’Apache avec Kerberos), une boîte de dialogue
vous invite à vous authentifier à l’aide de votre identifiant et de votre
mot de passe.
En revanche, si cette directive a été positionnée à « off », l’authentification échoue et une page d’erreur apparaît dans le navigateur. Dans ce cas, vous devez d’abord obtenir un ticket Kerberos pour accéder à l’application.
Sous Linux, vous pouvez obtenir un ticket Kerberos à l’aide de la commande suivante:
$ kinit -f <identifiant Kerberos>
L’option « -f » indique que le ticket peut être réutilisé par les services auxquels vous vous connectez (délégation). Elle est nécessaire au bon fonctionnement des interfaces de Vigilo.
Annexes¶
Matrice des permissions associées aux applications¶
Le tableau suivant liste les permissions associées à chaque application avec leur rôle.
- vigiboard-access
- Autorise l’utilisateur à se connecter à VigiBoard.
- vigiboard-update
- Autorise l’utilisateur à mettre à jour des événements dans VigiBoard.
- vigiboard-admin
- Autorise l’utilisateur à forcer l’état d’un événement du bac à « OK ».
- vigiboard-silence
- Autorise l’utilisateur à consulter et à éditer les règles de mise en silence du bac à événements.
- vigigraph-access
- Autorise l’utilisateur à se connecter à VigiGraph.
- vigimap-access
- Autorise l’utilisateur à se connecter à VigiMap.
- vigimap-edit
- Autorise l’utilisateur à accéder au Mode Édition de VigiMap (pour éditer les cartes).
- vigimap-admin
- Autorise l’utilisateur à administrer les groupes de cartes.
Matrice des permissions sur les groupes de données¶
Vigilo permet, via l’interface VigiAdmin, d’accorder des permissions à un utilisateur sur un groupe de données. Ces groupes de données peuvent être de trois types :
- Groupes d’éléments supervisés (hôtes ou services),
- Groupes de cartes,
- Groupes de graphes.
Les accès accordés sont soit en lecture seule, soit en lecture/écriture. Lorsqu’un accès est donné sur un groupe, il est également donné implicitement à tous les descendants de ce groupe dans l’arborescence.
La signification de l’accès en lecture/écriture aux données varie selon le type d’objet et l’interface manipulée. Le tableau suivant précise la signification de chaque type d’accès, selon le type d’objet sur lequel il est appliqué et l’interface de Vigilo consultée.
- VigiBoard
- L’accès en lecture seule sur un groupe permet de voir les événements se rapportant aux hôtes ou aux services de ce groupe. L’accès en lecture/écriture permet en plus de modifier le statut d’acquittement ou le ticket associé aux événements concernant des hôtes ou services du groupe [4].
- VigiGraph
Groupes d’hôtes ou de services : l’accès en lecture seule sur un groupe permet de voir les graphes se rapportant aux hôtes de ce groupe. L’accès en lecture/écriture confère les mêmes droits.
Groupes de graphes : l’accès en lecture seule permet de consulter les graphes associés à ce groupe. L’accès en lecture/écriture [5] confère exactement les mêmes droits.
- VigiMap
Groupes d’hôtes ou de services : l’accès en lecture seule permet de voir les hôtes et services contenus dans le groupe et apparaissant sur une carte. Il permet également d’utiliser les hôtes et services contenus dans le groupe lors de la création ou de la modification d’une carte. L’accès en lecture/écriture confère les mêmes droits [6].
Groupes de cartes : l’accès en lecture seule sur un groupe de cartes permet de consulter les cartes contenues dans ce groupe. L’accès en lecture/écriture permet en plus de créer ou de modifier des cartes dans ce groupe [7].
Groupes de graphes : L’accès en lecture seule permet de voir les graphes associés au groupe lorsqu’ils sont utilisés sur une carte au travers d’un lien de type « service ». Il permet également d’utiliser ces graphes lors de la création ou de la modification d’une carte, au sein d’un lien de type « service ». L’accès en lecture/écriture confère les mêmes droits [8].
[4] | Pour le moment, l’accès en lecture seule est suffisant pour ça... |
[5] | L’accès en lecture seule ou en lecture/écriture devrait permettre de voir les graphes en question. |
[6] | Cette fonctionnalité n’est pas encore implémentée. |
[7] | Pour le moment, l’accès en lecture seule se comporte comme l’accès en lecture/écriture. |
[8] | Cette fonctionnalité n’est pas encore implémentée. |
Glossaire - Terminologie¶
Ce chapitre recense les différents termes techniques employés dans ce document et donne une brève définition de chacun de ces termes.
Glossaire - Terminologie¶
Ce chapitre recense les différents termes techniques employés dans ce document et donne une brève définition de chacun de ces termes.
- API
- Interface logicielle de programmation, permettant à un développeur d’enrichir la liste des fonctionnalités proposées par un logiciel.
- CGI
- Interface standard de communication entre un serveur web et un programme capable de générer une réponse HTTP valide. Il s’agit par exemple de l’interface retenue par Nagios (< 3.3) pour la génération de ses pages web.
- CSS
- Feuilles de styles permettent de modifier la représentation graphique des éléments d’une page web. La version généralement supportée par les navigateurs est la version 2, définie par le document disponible sur http://www.w3.org/TR/CSS2/.
- CSV
- À l’origine, désigne un format textuel de transfert de données dans lequel les entrées sont séparées par des retours chariot et les champs par des virgules (comma). De nos jours, désigne plus généralement un format tabulé pour l’échange de données en vue de leur traitement dans un logiciel de type tableur ou par un traitement automatisé (scripts).
- DN
- Identifiant unique dans le cadre d’un annuaire LDAP.
- Événement brut
- Alerte envoyée par Nagios au corrélateur de Vigilo pour analyse.
- Événement corrélé
- Incident détecté par Vigilo suite à la corrélation des alertes Nagios (évènements bruts). Un événement corrélé est causé par un unique événement brut (exemple : la panne d’un routeur), mais de nombreux autres évènements bruts peuvent lui être rattachés (exemple : les alertes indiquant que les serveurs situés derrière le routeur en panne sont indisponibles). Ces événements secondaires rattachés à l’événement corrélé sont alors appelés « événements bruts masqués ».
- KDC
- Serveur permettant un transfert sécurisé des clés de chiffrement utilisées pour les communications entre divers services. Ce serveur est notamment utilisé lors des échanges initiaux du protocole Kerberos.
- LDAP
- Protocole pour l’interrogation d’un annuaire, servant généralement à recenser les utilisateurs autorisés d’un système et les différentes propriétés associées à ces utilisateurs.
- OS
- Système d’exploitation.
- Nagios
- Composant libre de supervision système et réseau.
- RRD
- Base de données de taille fixe utilisant des fichiers circulaires, dont les données sont progressivement compressées (avec perte) au fur et à mesure de leur vieillissement.
- RRDtool
- Composant libre de gestion de bases RRD (stockage, restitution, génération de graphiques).
- SGBD[R]
- Logiciel permettant d’héberger des bases de données [relationnelles] sur une machine.
- SQL
- Langage de requêtes structuré pour l’interrogation d’une base de données relationnelle.
- URL
- Chaîne de caractères permettant d’identifier une ressource, par exemple une page web sur Internet. Exemple : http://www.vigilo-nms.com/
- WSGI
- Une interface pour la communication entre une application et un serveur web, similaire à CGI. Il s’agit de l’interface utilisée par Vigilo.