Delivered-To: mailing list cvs@httpd.apache.org Received: (qmail 10303 invoked by uid 99); 23 Apr 2009 04:10:28 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Apr 2009 04:10:28 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Apr 2009 04:10:15 +0000 Received: by eris.apache.org (Postfix, from userid 65534) id 69B4623889FD; Thu, 23 Apr 2009 04:09:53 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: svn commit: r767783 [2/9] - in /httpd/httpd/trunk/docs/manual: ./ faq/ howto/ misc/ mod/ Date: Thu, 23 Apr 2009 04:09:49 -0000 To: cvs@httpd.apache.org From: wrowe@apache.org X-Mailer: svnmailer-1.0.8 Message-Id: <20090423040953.69B4623889FD@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Modified: httpd/httpd/trunk/docs/manual/howto/auth.html.fr URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/howto/auth.html.fr?rev=767783&r1=767782&r2=767783&view=diff ============================================================================== --- httpd/httpd/trunk/docs/manual/howto/auth.html.fr (original) +++ httpd/httpd/trunk/docs/manual/howto/auth.html.fr Thu Apr 23 04:09:46 2009 @@ -1,644 +1,644 @@ - - - -Authentification, autorisation et contrôle d'accès - Serveur Apache HTTP - - - - - -

-Apache > Serveur HTTP > Documentation > Version 2.3 > Recettes / Tutoriels

Authentification, autorisation et contrôle d'accès

Langues Disponibles: en | - fr | - ja | - ko

- -

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.

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
Pour aller plus loin . . .

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
-
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 "Fichiers réservés" - # (La ligne suivante est facultative) - 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 est beaucoup plus sécurisée. La plupart - des navigateurs récents supportent l'authentification Digest.

- -

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. Le programme dbmmanage permet de créer et manipuler ces fichiers. Vous - trouverez de nombreuses options d'autres types d'authentification - fournies par des modules tiers dans la Base de données des modules - d'Apache.

- -

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 comme suit :

- -

- AuthType Basic - AuthName "By Invitation Only" - # Ligne facultative : - AuthBasicProvider file - AuthUserFile /usr/local/apache/passwd/passwords - AuthGroupFile /usr/local/apache/passwd/groups - Require group Nom-de-groupe -

- -

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

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 adresse -

- -

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

- -

- Require host nom_domaine -

- -

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 serveur.exemple.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 - <RequireNone> - - Require ip 192.168.205 - Require host phishers.exemple.com autres-idiots.exemple - Require host ke - - </RequireNone> - - </RequireAll> -

- -

Dans l'exemple ci-dessus, on utilise la directive du - conteneur <RequireNone> afin de s'assurer - qu'aucune des directives Require qu'il contient ne - fasse correspondre ses paramètres avant d'accorder - l'autorisation.

- - - -

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.

- - - -

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.

- -

Langues Disponibles: en | - fr | - ja | - ko

+ + + +Authentification, autorisation et contrôle d'accès - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.3 > Recettes / Tutoriels

Authentification, autorisation et contrôle d'accès

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

+ +

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.

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
Pour aller plus loin . . .

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
+
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 "Fichiers réservés" + # (La ligne suivante est facultative) + 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 est beaucoup plus sécurisée. La plupart + des navigateurs récents supportent l'authentification Digest.

+ +

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. Le programme dbmmanage permet de créer et manipuler ces fichiers. Vous + trouverez de nombreuses options d'autres types d'authentification + fournies par des modules tiers dans la Base de données des modules + d'Apache.

+ +

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 comme suit :

+ +

+ AuthType Basic + AuthName "By Invitation Only" + # Ligne facultative : + AuthBasicProvider file + AuthUserFile /usr/local/apache/passwd/passwords + AuthGroupFile /usr/local/apache/passwd/groups + Require group Nom-de-groupe +

+ +

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

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 adresse +

+ +

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

+ +

+ Require host nom_domaine +

+ +

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 serveur.exemple.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 + <RequireNone> + + Require ip 192.168.205 + Require host phishers.exemple.com autres-idiots.exemple + Require host ke + + </RequireNone> + + </RequireAll> +

+ +

Dans l'exemple ci-dessus, on utilise la directive du + conteneur <RequireNone> afin de s'assurer + qu'aucune des directives Require qu'il contient ne + fasse correspondre ses paramètres avant d'accorder + l'autorisation.

+ + + +

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.

+ + + +

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.

+ +

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

\ No newline at end of file