L'authentification est un processus qui vous permet de vérifier qu'une personne est bien celle qu'elle prétend être. L'autorisation est un processus qui permet à une personne d'aller là où elle veut aller, ou d'obtenir les informations qu'elle désire.
Pour le contrôle d'accès en général, voir le How-To Contrôle d'accès.
Si votre site web contient des informations sensibles ou destinées seulement à un groupe de personnes restreint, les techniques exposées dans cet article vont vous aider à vous assurer que les personnes qui ont accès à ces pages sont bien celles auxquelles vous avez donné l'autorisation d'accès.
Cet article décrit les méthodes "standards" de protection de parties de votre site web que la plupart d'entre vous sont appelés à utiliser.
Si vos données ont un réel besoin de sécurisation, prévoyez
l'utilisation de
Les directives décrites dans cet article devront être insérées
soit au niveau de la configuration de votre serveur principal (en
général dans une section .htaccess
)
Si vous envisagez l'utilisation de fichiers
.htaccess
, la configuration de votre serveur devra
permettre l'ajout de directives d'authentification dans ces
fichiers. Pour ce faire, on utilise la directive
Comme il est ici question d'authentification, vous aurez besoin
d'une directive
Si vous avez l'intention d'ajouter les directives directement dans le fichier de configuration principal, vous devrez bien entendu posséder les droits en écriture sur ce fichier.
Vous devrez aussi connaître un tant soit peu la structure des répertoires de votre serveur, ne serait-ce que pour savoir où se trouvent certains fichiers. Cela ne devrait pas présenter de grandes difficultés, et nous essaierons de clarifier tout ça lorsque le besoin s'en fera sentir.
Enfin, vous devrez vous assurer que les modules
Nous décrivons ici les bases de la protection par mot de passe d'un répertoire de votre serveur.
Vous devez en premier lieu créer un fichier de mots de passe. La méthode exacte selon laquelle vous allez créer ce fichier va varier en fonction du fournisseur d'authentification choisi. Mais nous entrerons dans les détails plus loin, et pour le moment, nous nous contenterons d'un fichier de mots de passe en mode texte.
Ce fichier doit être enregistré à un endroit non accessible
depuis le web, de façon à ce que les clients ne puissent pas le
télécharger. Par exemple, si vos documents sont servis à partir de
/usr/local/apache/htdocs
, vous pouvez enregistrer le
fichier des mots de passe dans
/usr/local/apache/passwd
.
L'utilitaire bin
de votre installation d'Apache. Si vous avez
installé Apache à partir d'un paquetage tiers, il sera probablement
dans le chemin par défaut de vos exécutables.
Pour créer le fichier, tapez :
Si /usr/local/apache2/bin/htpasswd
.
Ensuite, vous allez devoir configurer le serveur de façon à ce
qu'il demande un mot de passe et lui préciser quels utilisateurs ont
l'autorisation d'accès. Pour ce faire, vous pouvez soit éditer le
fichier httpd.conf
, soit utiliser un fichier
.htaccess
. Par exemple, si vous voulez protéger le
répertoire /usr/local/apache/htdocs/secret
, vous pouvez
utiliser les directives suivantes, soit dans le fichier
/usr/local/apache/htdocs/secret/.htaccess
, soit dans le
fichier httpd.conf
à l'intérieur d'une section <Directory
"/usr/local/apache/htdocs/secret"> :
Examinons ces directives une à une. La directive Basic
, et elle est implémentée par
AuthType
Digest
. Cette méthode est implémentée
par le module
La directive
Ainsi par exemple, une fois un client authentifié dans la zone
"Fichiers réservés"
, il soumettra à nouveau
automatiquement le même mot de passe pour toute zone du même serveur
marquée de l'identificateur "Fichiers réservés"
. De
cette façon, vous pouvez éviter à un utilisateur d'avoir à saisir
plusieurs fois le même mot de passe en faisant partager le même
identificateur entre plusieurs zones réservées. Bien entendu et pour
des raisons de sécurité, le client devra redemander le mot
de passe chaque fois que le nom d'hôte du serveur sera modifié.
La directive file
est la valeur par défaut
pour cette directive. Par contre, cette directive sera obligatoire
si vous utilisez une autre source d'authentification comme
La directive
Enfin, la directive
Les directives ci-dessus n'autorisent qu'une personne (quelqu'un
possédant le nom d'utilisateur rbowen
) à accéder au
répertoire. Dans la plupart des cas, vous devrez autoriser
l'accès à plusieurs personnes. C'est ici
qu'intervient la directive
Si vous voulez autoriser l'accès à plusieurs personnes, vous devez créer un fichier de groupes qui associe des noms de groupes avec une liste d'utilisateurs de ce groupe. Le format de ce fichier est très simple, et vous pouvez le créer avec votre éditeur favori. Son contenu se présente comme suit :
Il s'agit simplement une liste des membres du groupe sous la forme d'une ligne séparée par des espaces.
Pour ajouter un utilisateur à votre fichier de mots de passe préexistant, entrez :
Vous obtiendrez le même effet qu'auparavant, mais le mot de passe
sera ajouté au fichier, plutôt que d'en créer un nouveau (C'est le
drapeau -c
qui permet de créer un nouveau fichier de
mots de passe)..
Maintenant, vous devez modifier votre fichier
.htaccess
comme suit :
Maintenant, quiconque appartient au groupe
Nom-de-groupe
, et possède une entrée dans le fichier
password
pourra accéder au répertoire s'il tape le bon
mot de passe.
Il existe une autre méthode moins contraignante pour autoriser l'accès à plusieurs personnes. Plutôt que de créer un fichier de groupes, il vous suffit d'ajouter la directive suivante :
Le remplacement de la ligne Require user rbowen
par
la ligne Require valid-user
autorisera l'accès à
quiconque possédant une entrée dans le fichier password, et ayant
tapé le bon mot de passe. Vous pouvez même simuler le comportement
des groupes en associant un fichier de mots de passe différent pour
chaque groupe. L'avantage de cette approche réside dans le fait
qu'Apache ne doit consulter qu'un fichier au lieu de deux. Par
contre, vous devez maintenir un nombre plus ou moins important de
fichiers de mots de passe, et vous assurer de faire référence au bon
fichier dans la directive
L'authentification Basic est spécifiée d'une telle manière que vos nom d'utilisateur et mot de passe doivent être vérifiés chaque fois que vous demandez un document au serveur, et ceci même si vous rechargez la même page, et pour chaque image contenue dans la page (si elles sont situées dans un répertoire protégé). Comme vous pouvez l'imaginer, ceci ralentit un peu le fonctionnement. La mesure dans laquelle le fonctionnement est ralenti est proportionnelle à la taille du fichier des mots de passe, car ce dernier doit être ouvert et la liste des utilisateurs parcourue jusqu'à ce que votre nom soit trouvé, et ceci chaque fois qu'une page est chargée.
En conséquence, ce ralentissement impose une limite pratique au nombre d'utilisateurs que vous pouvez enregistrer dans un fichier de mots de passe. Cette limite va varier en fonction des performances de votre serveur, mais vous commencerez à remarquer un ralentissement lorsque vous atteindrez quelques centaines d'utilisateurs, et serez alors appelés à utiliser une méthode d'authentification différente.
Suite au problème évoqué précédemment et induit par le stockage des mots de passe dans un fichier texte, vous pouvez être appelé à stocker vos mots de passe d'une autre manière, par exemple dans une base de données.
Pour y parvenir, on peut utiliser les modules
dbm
ou
dbd
à la place de file
pour la directive
Par exemple, pour sélectionner un fichier dbm à la place d'un fichier texte :
D'autres options sont disponibles. Consultez la documentation de
Depuis l'arrivée des nouvelles architecture d'autorisation et d'authentification basées sur les fournisseurs, vous n'êtes plus limité à une méthode d'authentification et d'autorisation unique. En fait, on peut panacher autant de fournisseurs que l'on veut, ce qui vous permet d'élaborer l'architecture qui correspond exactement à vos besoins. Dans l'exemple suivant, on utilise conjointement les fournisseurs d'authentification file et LDAP :
Dans cet exemple, le fournisseur file va tenter d'authentifier l'utilisateur en premier. S'il n'y parvient pas, le fournisseur LDAP sera sollicité. Ceci permet l'élargissement des possibilités d'authentification si votre organisation implémente plusieurs types de bases d'authentification. D'autres scénarios d'authentification et d'autorisation peuvent associer un type d'authentification avec un autre type d'autorisation. Par exemple, une authentification basée sur un fichier de mots de passe peut permettre l'attribution d'autorisations basée sur un annuaire LDAP.
Tout comme plusieurs fournisseurs d'authentification peuvent être implémentés, on peut aussi utiliser plusieurs méthodes d'autorisation. Dans l'exemple suivant, on utilise à la fois une autorisation à base de fichier de groupes et une autorisation à base de groupes LDAP.
Pour un scénario d'autorisation un peu plus avancé, des
directives de conteneur d'autorisation comme
La manière dont les autorisations sont accordées est désormais beaucoup plus souple qu'une simple vérification auprès d'une seule base de données. Il est maintenant possible de choisir l'ordre, la logique et la manière selon lesquels une autorisation est accordée.
Le contrôle de la manière et de l'ordre selon lesquels le
processus d'autorisation était appliqué
constituait une sorte de mystère par
le passé. Dans Apache 2.2, un mécanisme d'authentification basé
sur les fournisseurs a été développé afin de séparer le
véritable processus d'authentification de l'autorisation et ses
différentes fonctionnalités. Un des avantages colatéraux
résidait dans le fait que les fournisseurs d'authentification
pouvaient être configurés et appelés selon un ordre particulier
indépendant de l'ordre de chargement du module auth proprement
dit. Ce mécanisme basé sur les fournisseurs a été étendu au
processus d'autorisation. Ceci signifie que la directive
Avec l'introduction des directives de conteneur
d'autorisations
Par défaut, toutes les directives
La vérification du nom d'utilisateur et du mot de passe ne constituent qu'un aspect des méthodes d'authentification. Souvent, le contrôle d'accès à certaines personnes n'est pas basé sur leur identité ; il peut dépendre, par exemple de leur provenance.
Les fournisseurs d'autorisation all
,
env
, host
et ip
vous
permettent d'accorder ou refuser l'accès en
fonction de critères tels que le nom d'hôte ou l'adresse
IP de la machine qui effectue la requête.
L'utilisation de ces fournisseurs est spécifiée à l'aide de
la directive
où adresse est une adresse IP (ou une adresse IP partielle) ou :
où nom_domaine est un nom de domaine entièrement qualifé (ou un nom de domaine partiel) ; vous pouvez indiquer plusieurs adresses ou noms de domaines, si vous le désirez.
Par exemple, si vous voulez rejeter les spams dont une machine vous inonde, vous pouvez utiliser ceci :
Ainsi, les visiteurs en provenance de cette adresse ne pourront pas voir le contenu concerné par cette directive. Si, par contre, vous connaissez le nom de la machine, vous pouvez utiliser ceci :
Et si vous voulez interdire l'accès à toutes les machines d'un domaine, vous pouvez spécifier une partie seulement de l'adresse ou du nom de domaine :
L'utilisation de la directive not
, n'accordera l'accès que si toutes les
conditions négatives sont vérifiées. En d'autres termes, l'accès
sera refusé si au moins une des conditions négatives n'est pas
vérifiée.
L'adoption d'un mécanisme à base de fournisseurs pour
l'authentification, a pour effet colatéral de rendre inutiles
les directives
Les directives fournies par le module
Dans certains cas, l'authentification constitue une charge
inacceptable pour un fournisseur d'authentification ou votre réseau.
Ceci est susceptible d'affecter les utilisateurs du module
Cette mise en cache apportera un gain en performance substantiel à certains utilisateurs.
Vous pouvez aussi lire la documentation de
Les différents algorithmes de chiffrement supportés par Apache pour authentifier les données sont expliqués dans PasswordEncryptions.
Enfin vous pouvez consulter la recette Contrôle d'accès, qui décrit un certain nombre de situations en relation avec le sujet.