Webserver/Apache/Authentification

Introduction

Ce document a pour but de détailler les différents modes d'authentification du serveur web Apache, ainsi que les différents providers.

Lexique

• Authentification : l'authentification est le procédé permettant de s'assurer qu'une entité est bien celle qu'elle prétend être.
• Type d'authentification : le type d'authentification définit la manière dont le navigateur va transmettre les informations au serveur.
• Provider : le Provider définit la manière dont les informations d'authentification vont être stockées sur le serveur (back-ends).

Les différents types d'authentification

Il existe deux types d'authentification possibles pour le protocole HTTP : le type Basic et le type Digest.

• Le type Basic : c'est le type d'authentification le plus courant, c'est celui utilisé par défaut pour les fichiers « htaccess ».
  C'est le plus simple à mettre en place, mais il possède la caractéristique de voir le mot de passe transiter en clair sur le réseau. Il est donc très facile de « sniffer » ce type de données avec un outil approprié.
  En revanche, c'est la méthode qui fonctionnera à coup sûr avec tout les navigateurs.
• Le type Digest : ce type d'authentification est plus sécurisé que le type Basic dans la mesure ou le mot de passe ne transite pas entre le navigateur et le serveur.
  Il présente aussi l'avantage de ne pas stocker les mot de passes en clair sur le serveur, il ne stocke que les hash.
  Contrairement à certains providers du type Basic, qui ne stockent pas non plus les mots de passe en clair sur le serveur, c'est ici une obligation.

Les mécanismes d'authentification

Selon le type d'authentification, le mécanisme n'est pas le même. Cette section va décrire les mécanismes des deux types d'authentification Basic et Digest, c'est à dire les échanges entre le navigateur et le serveur.

Fonctionnement général : Lorsqu'un client HTTP demande une ressource protégée au serveur, celui-ci répond de différente façon selon la requête :

• Soit la requête ne contient pas d'en-tête HTTP d'identification, dans ce cas le serveur répond avec le code HTTP 401 - Unauthorized et envoie les en-tête d'information sur l'identification demandée
• Soit la requête contient les en-têtes HTTP d'identification, dans ce cas, après vérification du nom et du mot de passe, si l'identification échoue, le serveur répond par le code 401 comme dans le cas précédent, sinon il répond de manière normale (200 - OK)

Mécanisme de l'authentification Basic :

• Le navigateur envoi une requête afin d'accéder à une ressource protégée.
• Si le serveur n'a pas reçu d'entête d'authentification, il retourne une réponse WWW-Authenticate: Basic realm=mon royaume. On reconnaît de ce fait le type d'authentification attendu. Le serveur génère un code 401 – Unauthorized.
• Le navigateur demande donc un nom d'utilisateur et un mot de passe.
• Le navigateur retente alors la requête en ajoutant dans l'entête HTTP Authorization: Basic chaîne, où chaîne est constitué du nom d'utilisateur et du mot de passe séparés par un double point (:), le tout encodé en Base64.
• Les données reçues sont analysées par le serveur. Si l'authentification réussit, un code 200 – OK est généré et la ressource demandée est transmise. Si elle échoue, un code 401 – Unauthorized est à nouveau généré. Dans ce cas, généralement, la procédure reprend et le navigateur demande de nouveau un nom d'utilisateur et un mot de passe. Si l'utilisateur annule la demande, il verra un code 401 – Unauthorized.

Mécanisme de l'authentification Digest :

• Le navigateur envoi une requête afin d'accéder à une ressource protégée.
• Le serveur précise alors le royaume, le niveau de protection (optionnel), le type d'authentification à utiliser, le domaine de protection (optionnel) et une chaîne que le client doit traiter, c'est le challenge.
• Le client va alors calculer une réponse en fonction de ces paramètres et du mot de passe à sa disposition, et les transmettre sous la forme d'un digest en compagnie des éléments fournis par le serveur.
• Enfin, le serveur va alors vérifier ces informations en se basant sur les hash qu'il possède. Si la vérification réussit, l'accès est autorisé. Si elle échoue, la procédure reprend avec un nouveau challenge.

Les différents providers

Il existe une multitude de providers, certains pouvant être utilisés avec les deux types d'authentification, et d'autres seulement avec l'authentification Basic. Ce document va décrire trois différents providers : le provider File, le provider DBM et le provider MySQL.

• Le provider File : c'est le provider le plus couramment utilisé, il permet de traiter les données stockées dans de simples fichiers textes (utilisateur et mot de passe référencés ligne par ligne).
  Le mot de passe est chiffré par défaut via la fonction « crypt » (basée sur l'algorithme DES), mais peut aussi bien être chiffré en MD5. Ce provider peut être utilisé avec le type Basic et le type Digest.
• Le provider DBM : ce provider utilise un format de base de données adapté au stockage des informations d 'authentification.
  Les avantages de ce provider sont l'indexation et la vitesse de recherche, mais aussi le fait de pouvoir stocker les logins, mots de passe ainsi que les groupes d'utilisateurs, dans un même fichier.
  Ce provider peut être utilisé avec le type Basic, et avec le type Digest moyennant une manipulation spéciale.
• Le provider MySQL : ce provider permet l'utilisation d'une base de données (locale ou distante) de type MySQL afin de stocker les informations d'authentification, ce qui présente l'avantage d'une manipulation aisée des données.
  Ce provider ne peut être utilisé qu'avec le type Basic.

L'authentification Basic et le provider File

Avant toute chose, pour utiliser l'authentification Basic, il faut vérifier que le module « auth_basic » soit bien chargé au démarrage de Apache, ce qui est normalement le cas par défaut :

LoadModule auth_basic_module modules/mod_auth_basic.so

Il faut aussi que le module « authn_file » soit chargé :

LoadModule authn_file_module modules/mod_authn_file.so

Voici la configuration pour une authentification de type Basic, utilisant le provider File :

<Directory "/opt/httpd/htdocs/test">
AuthType 		Basic	
AuthName 		"Zone securisee"
AuthBasicProvider 	file
AuthUserFile		"/opt/httpd/conf/auth_basic_file/.mdp"
AuthGroupFile		"/opt/httpd/conf/auth_basic_file/.group"
Require 		valid-user
</Directory>

AuthType définit le type d'authentification. AuthName définit le « royaume » ou domaine de protection (aussi appelé « realm »). AuthBasicProvider définit le provider utilisé. AuthUserFile définit le fichier de mot de passe à utiliser. AuthGroupFile définit le fichier de groupes à utiliser. Require permet de définir qui aura le droit d'accéder à la ressource. Le fichier de mot de passe devra être produit à l'aide de la commande « htpasswd » :

htpasswd -c opt/httpd/conf/auth_basic_file/.mdp monlogin

L'option -c n'est à utiliser que la première fois pour créer le fichier. Le fichier de groupe pourra quand à lui être créé comme n'importe quel fichier texte, il suffit de respecter la syntaxe : nomdugroupe=user user2 user3

Directive Require
On peut aussi utiliser l'argument « group » pour restreindre l'accès aux membres de certains groupes :

Require group mongroupe

On peut utiliser plusieurs fois la directive Require pour définir plusieurs arguments, ces occurrences seront alors interprétés sous la forme de OU logiques.

L'authentification basic et le provider DBM

Avant toute chose, pour utiliser le provider DBM, il faut charger les module « authn_dbm » et « authz_dbm » :

LoadModule authn_dbm_module modules/mod_authn_dbm.so
LoadModule authz_dbm_module modules/mod_authz_dbm.so

Voici la configuration pour une authentification de type Basic, utilisant le provider DBM :

<Directory "/opt/httpd/htdocs/test">
AuthType 		Basic
AuthName 		"Zone securisee"
AuthBasicProvider 	dbm
AuthDBMUserFile	  	"/opt/httpd/conf/auth_basic_dbm/.mdp.dat"
AuthDBMGroupFile  	"/opt/httpd/conf/auth_basic_dbm/.mdp.dat"
Require 		valid-user
</Directory>

Les directives ont le même rôle que dans la partie précédente, seuls les noms des directives concernant les fichiers de mot de passe et de groupe changent et deviennent AuthDBMUserFile et AuthDBMGroupFile. On utilise dans ce cas là le même fichier pour les login/mdp et les groupes, ceci étant un des avantages du provider DBM.

Le fichier de mot de passe (et de groupe) devra être créé via un outil spécialement conçu pour manipuler les fichiers DBM. Il existe deux principaux outils : « htdbm » et « dbmmanage ». Dans le cas d'une version compilée d'Apache, ces outils ainsi que d'autres sont disponibles dans le dossier /opt/httpd/bin/, il suffit donc de les copier vers le dossier /usr/bin/ ou bien de créer un lien symbolique, pour pouvoir les utiliser directement en ligne de commande.

Ces deux outils se ressemblent beaucoup, à l'exception que « htdbm » ne gère pas les groupes, et ne permet pas d'importer les données d'authentification depuis un fichier classique créé avec « htpasswd ».

De plus, par défaut, ces deux outils n'utilisent pas le même type de fichier DBM : « htdbm » utilise des fichiers au format SDBM, et « dbmmanage » des fichiers au format Berkeley DB.

Les fichiers reconnus par défaut par Apache sont les fichiers SDBM, aussi il n'est pas possible d'utiliser « dbmmanage » avec sa configuration par défaut pour manipuler ce type de fichier.

Il faut alors modifier le code du programme « dbmmanage » pour lui indiquer d'utiliser des fichiers de type SDBM par défaut :

# vi /usr/bin/dbmmanage

Au début du fichier, il faut modifier la ligne suivante :

BEGIN { @AnyDBM_File::ISA = qw(DB_File NDBM_File GDBM_File SDBM_File) }

En plaçant en premier le type de fichier SDBM :

BEGIN { @AnyDBM_File::ISA = qw(SDBM_File DB_File NDBM_File GDBM_File ) }

Une fois cette manipulation effectué, on peut utiliser « dbmmanage » pour importer les utilisateurs à partir d'un autre fichier de mot de passe créé avec « htpasswd » grâce aux commandes « cat » et « import » :

# cat .mdp | dbmmanage .mdp.dat import

On peut sinon créer notre fichier directement avec « dbmmanage » :

# dbmmanage .mdp.dat adduser monlogin - mongroupe

• C'est la même méthode pour créer un utilisateur, seulement la première fois que la commande est lancé, elle créé le fichier s'il n'existe pas.

On peut mettre à jour les informations d'un utilisateur :

# dbmmanage .mdp.dat update monlogin monnouveaumotdepasse monnouveaugroupe

On peut supprimer un utilisateur :

# dbmmanage .mdp.dat delete monlogin

Et enfin pour voir l'intégralité des utilisateurs ainsi que leurs groupes et leurs mots de passe (cryptés) :

# dbmmanage .mdp.dat view

En ce qui concerne la commande « htdbm » : Pour créer le fichier et ajouter un utilisateur :

# htdbm -c .mdp.dat monlogin

• L'option -c n'est à utiliser que la première fois pour créer le fichier.

Pour supprimer un utilisateur :

# htdbm -x .mdp.dat monlogin

Pour afficher l'intégralité des utilisateurs :

# htdbm -l .mdp.dat

L'authentification Basic et le provider MySQL

Avant toute chose, pour utiliser le provider MySQL il faut charger le module « auth_mysql ».

LoadModule mysql_auth_module modules/mod_auth_mysql.so

Il faut aussi bien entendu avoir un serveur MySQL installé et fonctionnel.

Voici la configuration pour une authentification de type Basic, utilisant le provider MySQL :

<Directory "/opt/httpd/htdocs/test">
AuthType						Basic
AuthName 						"Zone securisee"
AuthMYSQLEnable 			on
AuthMySQLUser 				root
AuthMySQLPassword 		root
AuthMySQLDB 					provider
AuthMySQLUserTable 		mysql_auth
AuthMySQLNameField 		username
AuthMySQLPasswordField 	passwd
AuthMySQLGroupField 	groups
Require 						valid-user
</Directory>

• AuthMYSQLEnable permet d'activer l'authentification via la base de données MySQL.
• AuthMYSQLUser correspond au nom d'utilisateur de la base de données MySQL.
• AuthMYSQLPassword correspond au mot de passe de la base de données MySQL.
• AuthMYSQLDB correspond au nom de la base de données MySQL contenant les informations d'authentification.
• AuthMYSQLUserTable correspond au nom de la table contenant les informations d'authentification.
• AuthMYSQLNameField correspond au nom du champ contenant les noms d'utilisateurs.
• AuthMYSQLPasswordField correspond au nom du champ contenant les mots de passe.
• AuthMYSQLGroupField correspond au nom du champ contenant les groupes.

Bien évidement, il faudra créer une base de données et la table qui correspond :

CREATE DATABASE provider;
USE provider;
CREATE TABLE mysql_auth (
		username char(25) not null,
		passwd char(25),
		groups char(25),
		primary key (username)
);

Et créer au moins un utilisateur :

INSERT INTO mysql_auth VALUES (''monlogin'', ''monmotdepasse'', ''mongroupe'');

NB: Le mot de passe devra être crypté avant à l'aide de la commande « htpasswd ». L'encryptage par défaut est « crypt », mais il est possible d'en définir d'autres grâce à une directive appropriée :

AuthMySQLPwEncryption		crypt | scrambled | md5 | aes | sha1

L'authentification Digest et le provider file

Avant toute chose, pour utiliser l'authentification Digest, il faut vérifier que le module « auth_digest » soit bien chargé au démarrage de Apache, ce qui est normalement le cas par défaut :

LoadModule auth_digest_module modules/mod_auth_digest.so

Il faut aussi que le module« authn_file » soit chargé :

LoadModule authn_file_module modules/mod_authn_file.so

Voici la configuration pour une authentification de type digest, utilisant le provider File :

<Directory "/opt/httpd/htdocs/test">
AuthType				Digest
AuthName 				"Zone securisee"
AuthDigestProvider	file
AuthUserFile			"/opt/httpd/conf/auth_digest_file/.mdp.digest"
AuthGroupFile			"/opt/httpd/conf/auth_digest_file/.group"
Require					valid-user
</Directory>

La seule directive qui change par rapport à l'authentification Basic avec File est la directive AuthBasicProvider remplacée par AuthDigestProvider.

Le fichier de mot de passe devra être produit à l'aide de la commande « htdigest » :

# htdigest -c .mdp.digest Zone securisee monlogin

L'option -c n'est à utiliser que la première fois pour créer le fichier. {{Admon/note|Royaume ou domaine de protection|On remarque que la syntaxe est la même que pour la commande « htpasswd », excepté qu'il faut définir le domaine de protection (« realm »), celui-ci faisant partie intégrante du challenge d'authentification (stocké dans le fichier de mot de passe).

L'authentification digest et le provider DBM

Avant toute chose, pour utiliser le provider DBM, il faut charger les module « authn_dbm » et « authz_dbm » :

 LoadModule authn_dbm_module modules/mod_authn_dbm.so
 LoadModule authz_dbm_module modules/mod_authz_dbm.so

Voici la configuration pour une authentification de type Digest, utilisant le provider DBM :

<Directory "/opt/httpd/htdocs/test"
AuthType                	Digest
AuthName 				"Zone securisee"
AuthDigestProvider     dbm
AuthDBMUserFile       "/opt/httpd/conf/auth_digest_dbm/.mdp.dat"
AuthDBMGroupFile     "/opt/httpd/conf/auth_digest_dbm/.mdp.dat"
Require					valid-user
</Directory>

Pour produire le fichier de mot de passe, ça se complique. En effet les commandes « dbmmanage » et « htdbm » ne disposent d'aucunes options pour le type Digest. Néanmoins, on peut effectuer une manipulation qui permettra de produire des logins/mdp compatibles avec l'authentification Digest. Pour que les logins/mdp soient compatibles, il faut que le nom d'utilisateur soit composé du login ainsi que du domaine de protection, séparés par un double point (:), et que le mot de passe soit le condensé MD5 de la concaténation du login, du domaine de protection et du mot de passe en clair, séparés par un double point. En sachant ça, on peut écrire un script shell qui servira de « wrapper » à dbmmanage :

# vi dbmdigest.sh

#!/bin/sh
FILE=$1
CMD=$2
USER=$3
REALM=$4
PASS=$5
GROUPE=$6
HASH=`echo -n "$USER:$REALM:$PASS" | md5sum | sed "s/ .*//"`
DBUSER=`echo -n "$USER:$REALM"`
echo Fichier         			: $FILE
echo Commande        		: $CMD
echo Utilisateur     			: $USER
echo Realm           			: $REALM
echo Utilisateur DB  		: $DBUSER
echo Mot de passe DB 	: $HASH
/usr/bin/dbmmanage .mdp.dat \
$CMD "$DBUSER" "$HASH" "$GROUPE"
#EOS

On peut maintenant créer un fichier de mot de passe ainsi que des utilisateurs, comme ceci :

# ./dbmdigest.sh .mdp.dat add monlogin "Zone securisee" monmotdepasse mongroupe

On peut supprimer un utilisateur comme ceci :

# ./dbmdigest.sh .mdp.dat delete monlogin "Zone securisee" monmotdepasse mongroupe