Module Apache mod_auth_basic

AuthBasicAuthoritative Directive

Normalement, chaque module d'autorisation �num�r� dans la directive AuthBasicProvider va tenter de v�rifier l'utilisateur, et si ce dernier n'est trouv� dans aucun des fournisseurs, l'acc�s sera refus�. D�finir explicitement la directive AuthBasicAuthoritative � Off permet de confier l'autorisation et l'authentification � d'autres modules non bas�s sur les fournisseurs si aucun identifiant utilisateur ou aucune r�gle ne correspondent � l'identifiant utilisateur sp�cifi�. Ceci ne peut s'av�rer n�cessaire que lorsque mod_auth_basic est combin� avec des modules tiers qui n'ont pas �t� configur�s � l'aide de la directive AuthBasicProvider. Lorsqu'on utilise de tels modules, l'ordre dans lequel s'effectue le traitement est d�fini dans le code source des modules et n'est pas configurable.

AuthBasicFake Directive

Les nom d'utilisateur et mot de passe sp�cifi�s sont rassembl�s dans un en-t�te d'autorisation qui est transmis au serveur ou au service sous-jacent au serveur. Ces nom d'utilisateur et mot de passe sont interpr�t�s par l'interpr�teur d'expression, ce qui permet de les d�finir en fonction de param�tres de la requ�te.

Si aucun mot de passe n'est sp�cifi�, la valeur par d�faut "password" sera utilis�e. Pour d�sactiver l'authentification de base simul�e pour un espace d'URL, d�finissez AuthBasicFake � "off".

Dans l'exemple suivant, un nom d'utilisateur et un mot de passe pr�d�finis sont transmis � un serveur d'arri�re-plan :

<Location /demo>
    AuthBasicFake demo demopass
</Location>
    

Dans l'exemple suivant, l'adresse email extraite d'un certificat client est transmise au serveur, �tendant par l�-m�me la fonctionnalit� de l'option FakeBasicAuth de la directive SSLOptions. Comme avec l'option FakeBasicAuth, le mot de passe se voit attribu� le contenu fixe de la cha�ne "password".

<Location /secure>
    AuthBasicFake %{SSL_CLIENT_S_DN_Email}
</Location>
    

Pour compl�ter l'exemple pr�c�dent, il est possible de g�n�rer la valeur du mot de passe en proc�dant � un hashage de l'adresse email � partir d'un mot d'une passphrase initial fix�e, puis de transmettre le r�sultat obtenu au serveur d'arri�re-plan. Ceci peut s'av�rer utile pour donner acc�s � des serveurs anciens qui ne supportent pas les certificats clients.

<Location /secure>
    AuthBasicFake %{SSL_CLIENT_S_DN_Email} %{sha1:passphrase-%{SSL_CLIENT_S_DN_Email}}
</Location>
    

<Location /public>
    AuthBasicFake off
</Location>
    

AuthBasicProvider Directive

La directive AuthBasicProvider permet de d�finir le fournisseur utilis� pour authentifier les utilisateurs pour la zone du site web concern�e. Le fournisseur par d�faut file est impl�ment� par le module mod_authn_file. Assurez-vous que le module impl�mentant le fournisseur choisi soit bien pr�sent dans le serveur.

<Location /secure>
    AuthType basic
    AuthName "private area"
    AuthBasicProvider  dbm
    AuthDBMType        SDBM
    AuthDBMUserFile    /www/etc/dbmpasswd
    Require            valid-user
</Location>
    

Les fournisseurs sont sollicit�s dans l'ordre jusqu'� ce que l'un d'entre eux trouve une correspondance pour le nom d'utilisateur de la requ�te ; alors, ce dernier fournisseur sera le seul � v�rifier le mot de passe. Un �chec dans la v�rification du mot de passe n'entra�ne pas le passage du contr�le au fournisseur suivant.

Les diff�rents fournisseurs disponibles sont impl�ment�s par les modules mod_authn_dbm, mod_authn_file, mod_authn_dbd, mod_authnz_ldap et mod_authn_socache.

AuthBasicUseDigestAlgorithm Directive

Normalement, lorsqu'on utilise l'authentification basique, les fournisseurs sp�cifi�s via la directive AuthBasicProvider tentent de contr�ler l'identit� d'un utilisateur en recherchant dans leurs bases de donn�es l'existence d'un couple utilisateur/mot de passe correspondant. Les mots de passe enregistr�s sont en g�n�ral chiffr�s, mais ce n'est pas syst�matique ; chaque fournisseur peut choisir son propre mode de stockage des mots de passe.

Lorsqu'on utilise l'authentification de type Digest, les fournisseurs sp�cifi�s par la directive AuthDigestProvider effectuent une recherche similaire dans leurs bases de donn�es pour trouver un couple utilisateur/mot de passe correspondant. Cependant, � la diff�rence de l'authentification basique, les donn�es associ�es � chaque utilisateur et comportant le nom d'utilisateur, le domaine de protection (realm) et le mot de passe doivent �tre contenues dans une cha�ne chiffr�e (Voir le document RFC 2617, Section 3.2.2.2 pour plus de d�tails � propos du type de chiffrement utilis� pour cette cha�ne).

A cause de la diff�rence entre les m�thodes de stockage des donn�es des authentifications de type basique et digest, le passage d'une m�thode d'authentification de type digest � une m�thode d'authentification de type basique requiert l'attribution de nouveaux mots de passe � chaque utilisateur, car leur mots de passe existant ne peut pas �tre extrait � partir du sch�ma de stockage utilis� par les fournisseurs d'authentification de type digest.

Si la directive AuthBasicUseDigestAlgorithm est d�finie � la valeur MD5, le mot de passe d'un utilisateur dans le cas de l'authentification basique sera v�rifi� en utilisant le m�me format de chiffrement que dans le cas de l'authentification de type digest. Tout d'abord, une cha�ne comportant le nom d'utilisateur, le domaine de protection (realm) et le mot de passe est g�n�r�e sous forme de condens� (hash) en utilisant l'algorithme MD5 ; puis le nom d'utilisateur et cette cha�ne chiffr�e sont transmis aux fournisseurs sp�cifi�s via la directive AuthBasicProvider comme si la directive AuthType �tait d�finie � Digest et si l'authentification de type Digest �tait utilis�e.

Gr�ce � cette directive, un site peut basculer d'une authentification de type digest � basique sans devoir changer les mots de passe des utilisateurs.