Authentification et autorisation h5170

Modules et directives concernés 1s1f24

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

On peut aussi ajouter 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_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 6b1j50

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.

Les prérequis 4i532k

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_authz_core ont été soit compilés avec le binaire httpd, soit chargés par le fichier de configuration apache2.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 n4z1g

Nous décrivons ici les bases de la protection par mot de e d'un répertoire de votre serveur.

Vous devez en premier lieu créer un fichier de mots de e. 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 e 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 e dans /usr/local/apache/wd.

L'utilitaire htwd 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 :

htwd vous demandera d'entrer le mot de e, et de le retaper pour confirmation :

Si htwd 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/htwd.

Ensuite, vous allez devoir configurer le serveur de façon à ce qu'il demande un mot de e et lui préciser quels utilisateurs ont l'autorisation d'accès. Pour ce faire, vous pouvez soit éditer le fichier apache2.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 apache2.conf à l'intérieur d'une section <Directory "/usr/local/apache/htdocs/secret"> :

AuthType Basic
AuthName "Restricted Files"
# (Following line optional)
AuthBasirovider file
AuthFile "/usr/local/apache/wd/s"
Require  rbowen

Examinons ces directives une à une. La directive 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 e. Ensuite, le client l'utilise pour déterminer quel mot de e 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 e 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 e 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 e chaque fois que le nom d'hôte du serveur sera modifié.

La directive mod_authn_dbd.

La directive htdbm permettent de créer et manipuler ces fichiers. Enfin, de nombreux modules tiers fournissent d'autres types d'authentification.

Enfin, la directive Require.

Autorisation d'accès à plusieurs personnes 34h2x

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 :

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 e préexistant, entrez :

Vous obtiendrez le même effet qu'auparavant, mais le mot de e 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 e)..

Maintenant, vous devez modifier votre fichier .htaccess ou la section <Directory> comme suit :

AuthType Basic
AuthName "By Invitation Only"
# Optional line:
AuthBasirovider file
AuthFile "/usr/local/apache/wd/s"
AuthGroupFile "/usr/local/apache/wd/groups"
Require group GroupName

Maintenant, quiconque appartient au groupe Nom-de-groupe, et possède une entrée dans le fichier pourra accéder au répertoire s'il tape le bon mot de e.

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-

Le remplacement de la ligne Require rbowen par la ligne Require valid- autorisera l'accès à quiconque possédant une entrée dans le fichier , et ayant tapé le bon mot de e.

Problèmes possibles 23713c

L'authentification Basic est spécifiée d'une telle manière que vos nom d'utilisateur et mot de e 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 e, 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 e. 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 e 301i3s

Suite au problème évoqué précédemment et induit par le stockage des mots de e dans un fichier texte, vous pouvez être appelé à stocker vos mots de e d'une autre manière, par exemple dans une base de données.

Pour y parvenir, on peut utiliser les modules AuthBasirovider.

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

<Directory "/www/docs/private">

    AuthName "Private"
    AuthType Basic
    AuthBasirovider dbm
    AuthDBMFile "/www/s/wd.dbm"
    Require valid-

</Directory>

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

Utilisation de plusieurs fournisseurs d'authentification 31e4p

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 contement les fournisseurs d'authentification file et LDAP :

<Directory "/www/docs/private">

    AuthName "Private"
    AuthType Basic
    AuthBasirovider file ldap
    AuthFile "/usr/local/apache/wd/s"
    AuthLDAPURL ldap://ldaphost/o=yourorg
    Require valid-

</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 e 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
    AuthBasirovider file
    AuthFile "/usr/local/apache/wd/s"
    AuthLDAPURL ldap://ldaphost/o=yourorg
    AuthGroupFile "/usr/local/apache/wd/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 Conteneurs d'autorisations pour un exemple de ce contrôle.

Pour aller plus loin qu'une simple autorisation 5c3e3n

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 513x3b

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 é. 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 apparaissent dans la configuration.

Avec l'introduction des directives de conteneur d'autorisations 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 <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 5w2l1f

La vérification du nom d'utilisateur et du mot de e 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 ref 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 <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 1t6x47

L'adoption d'un mécanisme à base de fournisseurs pour l'authentification, a pour effet colatéral de rendre inutiles les directives mod_access_compat.

Mise en cache de l'authentification h22w

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_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 . . . 3q2ev

Vous pouvez aussi lire la documentation de <AuthnProviderAlias>.

Les différents algorithmes de chiffrement és par Apache pour authentifier les données sont expliqués dans Encryptions.

Enfin vous pouvez consulter la recette Contrôle d'accès, qui décrit un certain nombre de situations en relation avec le sujet.