Authentification et autorisation

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.

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

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 vous demandera d'entrer le mot de passe, et de le retaper pour confirmation :

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 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)
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. 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 :

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

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.