Authentification et autorisation

Langues Disponibles: en | + es | + fr | + ja | + ko | + tr

+ +

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.

Modules et directives concernés
Introduction
Les prérequis
Mise en oeuvre
Autorisation d'accès à +plusieurs personnes
Problèmes possibles
Autre méthode de stockage des mots de +passe
Utilisation de plusieurs fournisseurs +d'authentification
Pour aller plus loin qu'une simple +autorisation
Mise en cache de l'authentification
Pour aller plus loin . . .

Voir aussi

Commentaires

Modules et directives concernés

+ +

Trois groupes de modules sont concernés par le processus +d'authentification et d'autorisation. Vous devrez utiliser au moins un +module de chaque groupe.

+ +

Type d'authentification (voir la directive AuthType) +
- mod_auth_basic
- mod_auth_digest
+
Fournisseur d'authentification (voir les directives AuthBasicProvider et AuthDigestProvider) + +
- mod_authn_anon
- mod_authn_dbd
- mod_authn_dbm
- mod_authn_file
- mod_authnz_ldap
- mod_authn_socache
+
Autorisation (voir la directive Require) +
- mod_authnz_ldap
- mod_authz_dbd
- mod_authz_dbm
- mod_authz_groupfile
- mod_authz_host
- mod_authz_owner
- mod_authz_user
+

+ +

On peut aussi ajouter mod_authn_core et + mod_authz_core. Ces modules implémentent des + directives générales qui opèrent au dessus de tous les modules + d'authentification.

+ +

Le module mod_authnz_ldap est un fournisseur + d'authentification et d'autorisation. Le module + mod_authz_host fournit une autorisation et un + contrôle d'accès basés sur le nom du serveur, l'adresse IP ou + certaines caractéristiques de la requête, mais ne fait pas partie du + système fournisseur d'authentification. Le module + mod_access_compat a été créé à des fins de + compatibilité ascendante avec mod_access.

+ +

Vous devriez aussi jeter un coup d'oeil au manuel de recettes de Contrôle d'accès, qui décrit les différentes + méthodes de contrôle d'accès à votre serveur.

+ +

Introduction

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.

+ +

Note :

Si vos données ont un réel besoin de sécurisation, prévoyez + l'utilisation de mod_ssl en plus de toute méthode + d'authentification.

Les prérequis

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 <Directory>), soit au niveau de la + configuration des répertoires (fichiers .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 AllowOverride, qui spécifie quelles + directives pourront éventuellement contenir les fichiers de + configuration de niveau répertoire.

+ +

Comme il est ici question d'authentification, vous aurez besoin + d'une directive AllowOverride + du style :

+ +

AllowOverride AuthConfig

+ + +

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 + mod_authn_core et mod_authz_core + ont été soit compilés avec le binaire httpd, soit chargés par le + fichier de configuration httpd.conf. Ces deux modules fournissent + des directives générales et des fonctionnalités qui sont critiques + quant à la configuration et l'utilisation de l'authentification et + de l'autorisation au sein du serveur web.

Mise en oeuvre

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 htpasswd fourni avec Apache + permet de créer ce fichier. Vous le trouverez dans le répertoire + 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 :

+ +

+ htpasswd -c /usr/local/apache/passwd/passwords rbowen +

+ +

htpasswd vous demandera d'entrer le mot de + passe, et de le retaper pour confirmation :

+ +

+ # htpasswd -c /usr/local/apache/passwd/passwords rbowen + New password: mot-de-passe + Re-type new password: mot-de-passe + Adding password for user rbowen +

+ +

Si htpasswd n'est pas dans le chemin par + défaut de vos exécutables, vous devrez bien entendu entrer le chemin + complet du fichier. Dans le cas d'une installation par défaut, il se + trouve à /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"> :

+ +

AuthType Basic
+AuthName "Restricted Files"
+# (Following line optional)
+AuthBasicProvider file
+AuthUserFile "/usr/local/apache/passwd/passwords"
+Require user rbowen

+ + +

Examinons ces directives une à une. La directive AuthType définit la méthode + utilisée pour authentifier l'utilisateur. La méthode la plus + courante est Basic, et elle est implémentée par + mod_auth_basic. Il faut cependant garder à l'esprit + que l'authentification Basic transmet le mot de passe depuis le + client vers le serveur en clair. Cette méthode ne devra donc pas + être utilisée pour la transmission de données hautement sensibles si + elle n'est pas associée au module mod_ssl. Apache + supporte une autre méthode d'authentification : AuthType + Digest. Cette méthode est implémentée par le module mod_auth_digest et a été conçue pour + améliorer la sécurité. Ce but n'a cependant pas été atteint et il est préférable + de chiffrer la connexion avec mod_ssl.

+ +

La directive AuthName définit + l'Identificateur (Realm) à utiliser avec + l'authentification. L'identificateur possède deux fonctions. Tout + d'abord, le client présente en général cette information à + l'utilisateur dans le cadre de la boîte de dialogue de mot de passe. + Ensuite, le client l'utilise pour déterminer quel mot de passe + envoyer pour une zone authentifiée donnée.

+ +

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 AuthBasicProvider est, dans ce + cas, facultative, car 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 + mod_authn_dbm ou + mod_authn_dbd.

+ +

La directive AuthUserFile définit le chemin + du fichier de mots de passe que nous venons de créer avec + htpasswd. Si vous possédez un grand nombre + d'utilisateurs, la durée de la recherche dans un fichier texte pour + authentifier un utilisateur à chaque requête va augmenter + rapidement, et pour pallier cet inconvénient, Apache peut aussi + stocker les données relatives aux + utilisateurs dans des bases de données rapides. Le module + mod_authn_dbm fournit la directive AuthDBMUserFile. Les programmes dbmmanage et htdbm permettent de + créer et manipuler ces fichiers. Enfin, de nombreux modules tiers + fournissent d'autres types d'authentification.

+ +

Enfin, la directive Require implémente la partie + autorisation du processus en définissant l'utilisateur autorisé à + accéder à cette zone du serveur. Dans la section suivante, nous + décrirons les différentes méthodes d'utilisation de la directive + Require.

Autorisation d'accès à +plusieurs personnes

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 AuthGroupFile.

+ +

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 :

+ +

+ Nom-de-groupe: rbowen dpitts sungo rshersey +

+ +

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 :

+ +

+ htpasswd /usr/local/apache/passwd/passwords dpitts +

+ +

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 ou la section <Directory> comme suit :

+ +

AuthType Basic
+AuthName "By Invitation Only"
+# Optional line:
+AuthBasicProvider file
+AuthUserFile "/usr/local/apache/passwd/passwords"
+AuthGroupFile "/usr/local/apache/passwd/groups"
+Require group GroupName

+ + +

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 :

+ +

Require valid-user

+ + +

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.

Problèmes possibles

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.

Autre méthode de stockage des mots de +passe

+ +

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 + mod_authn_dbm ou mod_authn_dbd. + Vous pouvez choisir comme format de stockage dbm ou + dbd à la place de file pour la directive + AuthBasicProvider.

+ +

Par exemple, pour sélectionner un fichier dbm à la place d'un + fichier texte :

+ +

<Directory "/www/docs/private">
+
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider dbm
+    AuthDBMUserFile "/www/passwords/passwd.dbm"
+    Require valid-user
+
+</Directory>

+ + +

D'autres options sont disponibles. Consultez la documentation de + mod_authn_dbm pour plus de détails.

Utilisation de plusieurs fournisseurs +d'authentification

+ +

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 :

+ +

<Directory "/www/docs/private">
+
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider file ldap
+    AuthUserFile "/usr/local/apache/passwd/passwords"
+    AuthLDAPURL ldap://ldaphost/o=yourorg
+    Require valid-user
+
+</Directory>

+ + +

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.

+ +

<Directory "/www/docs/private">
+
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider file
+    AuthUserFile "/usr/local/apache/passwd/passwords"
+    AuthLDAPURL ldap://ldaphost/o=yourorg
+    AuthGroupFile "/usr/local/apache/passwd/groups"
+    Require group GroupName
+    Require ldap-group cn=mygroup,o=yourorg
+
+</Directory>

+ + +

Pour un scénario d'autorisation un peu plus avancé, des + directives de conteneur d'autorisation comme <RequireAll> et + <RequireAny> permettent d'appliquer une + logique telle que l'ordre dans lequel les autorisations sont + appliquées peut être entièrement contrôlé au niveau de la + configuration. Voir Conteneurs + d'autorisations pour un exemple de ce contrôle.

+ +

Pour aller plus loin qu'une simple +autorisation

+ +

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.

+ +

Appliquer logique et + ordonnancement

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 + Require définit + non seulement quelles méthodes d'autorisation doivent être + utilisées, mais aussi l'ordre dans lequel elles sont appelées. + Les méthodes d'autorisation sont appelées selon l'ordre dans + lequel les directives Require apparaissent dans la + configuration.

+ +

Avec l'introduction des directives de conteneur + d'autorisations <RequireAll> + et <RequireAny>, la + configuration contrôle aussi le moment où les méthodes + d'autorisation sont appelées, et quels critères déterminent + l'autorisation d'accès. Voir Conteneurs + d'autorisations pour un exemple de la manière de les + utiliser pour exprimer des logiques d'autorisation + complexes.

+ +

Par défaut, toutes les directives Require sont + traitées comme si elles étaient contenues dans une directive + <RequireAny>. En d'autres termes, il + suffit + qu'une méthode d'autorisation s'applique avec succès pour que + l'autorisation soit accordée.

+ + + +

Utilisation de fournisseurs + d'autorisation pour le contrôle d'accès

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 Require. Cette directive + permet d'enregistrer quels fournisseurs d'autorisation + seront appelés dans le processus d'autorisation au cours du + traitement de la requête. Par exemple :

+ +

Require ip address

+ + +

où adresse est une adresse IP (ou une adresse IP + partielle) ou :

+ +

Require host domain_name

+ + +

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 :

+ +

<RequireAll>
+    Require all granted
+    Require not ip 10.252.46.165
+</RequireAll>

+ + +

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 :

+ +

<RequireAll>
+    Require all granted
+    Require not host host.example.com
+</RequireAll>

+ + +

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 :

+ +

<RequireAll>
+    Require all granted
+    Require not ip 192.168.205
+    Require not host phishers.example.com moreidiots.example
+    Require not host ke
+</RequireAll>

+ + +

L'utilisation de la directive <RequireAll> + avec de multiples directives <Require>, toutes avec la négation + 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.

+ + + +

Compatibilité ascendante du contrôle + d'accès

L'adoption d'un mécanisme à base de fournisseurs pour + l'authentification, a pour effet colatéral de rendre inutiles + les directives Order, Allow, Deny et Satisfy. Cependant, et à + des fins de compatibilité ascendante vers les anciennes + configurations, ces directives ont été déplacées vers le module + mod_access_compat.

+ +

Note

Les directives fournies par le module + mod_access_compat sont devenues obsolètes depuis + la refonte du module mod_authz_host. Mélanger d'anciennes + directives comme Order, Allow ou Deny avec des nouvelles comme + Require est techniquement + possible mais déconseillé. En effet, mod_access_compat a + été conçu pour supporter des configurations ne contenant que des anciennes + directives afin de faciliter le passage à la version 2.4. Voir le document + upgrading pour plus de détails. +

+ + +

Mise en cache de l'authentification

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 + mod_authn_dbd (ou les fournisseurs + tiers/personnalisés). Pour résoudre ce problème, HTTPD 2.3/2.4 + propose un nouveau fournisseur de mise en cache, + mod_authn_socache, qui permet de mettre en cache + les données d'authentification, et ainsi réduire la charge du/des + fournisseurs(s) originels.

Cette mise en cache apportera un gain en performance substantiel + à certains utilisateurs.

Pour aller plus loin . . .

Vous pouvez aussi lire la documentation de + mod_auth_basic et mod_authz_host + qui contient des informations supplémentaires à propos du + fonctionnement de tout ceci. + Certaines configurations d'authentification peuvent aussi être + simplifiées à l'aide de la directive <AuthnProviderAlias>.

+ +

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.

+ +