AuthType

AuthType type

Répertoire, .htaccess

AuthType précise le type du contrôle des autorisations. Basic était initialement le seul type possible, mais Apache 1.1 lui a ajouté Digest, qui utilise une empreinte MD5 et un secret partagé.

Lorsque AuthType est utilisé, il doit être accompagné des directives AuthName, AuthGroupFile, et AuthUserFile.

AuthName

AuthName secteur

Répertoire, .htaccess

AuthName donne le nom du secteur d’application des noms et des mots de passe des utilisateurs. Si le nom d’un domaine contient des espaces, il faut l’entourer d’apostrophes doubles :

AuthName "Département des ventes"

AuthGroupFile

AuthGroupFile fichier

Répertoire, .htaccess

AuthGroupFile n’a rien à voir avec la directive Group webgroup située au début du fichier de configuration. Elle indique le nom d’un fichier contenant les noms des groupes et de leurs membres :

cleaners: daphne sonia

directors: bill ben

Nous avons placé ces lignes dans le fichier .ok_users/groups et configuré AuthGroupFile pour qu’il l’utilise. Cette directive n’a aucun effet si la directive require n’a pas été configurée correctement.

AuthUserFile

AuthUserFile fichier

AuthUserFile désigne un fichier contenant une liste d’utilisateurs et leurs mots de passe chiffrés. Nous détaillerons tout cela dans la section « Mots de passe », plus loin dans ce chapitre.

AuthAuthoritative

AuthAuthoritative on|off

Valeur par défaut : on

Répertoire, .htaccess

Mettre cette directive à off permet de transmettre l’authentification et l’autorisation à des modules de plus bas niveau (tels qu’ils sont définis dans le fichier de configuration et dans modules.c ) s’il n’y a pas d’autre ID utilisateur ou règle qui correspond à l’ID fourni par le client. Si au contraire un ID utilisateur ou une règle coïncide avec l’ID envoyé par le client, les vérifications de mot de passe et d’accès habituels s’appliqueront et un échec provoquera une réponse « Authorization Required ».

Si un ID utilisateur apparaît dans la base de données de plusieurs modules, ou si une directive Require s’applique à plus d’un module, le premier d’entre eux vérifiera l’identité et aucun accès ne sera transmis -- quelle que soit la valeur de AuthAuthoritative.

On utilise souvent ce mécanisme avec l’un des modules de bases de données, comme mod_auth_db.c, mod_auth_dbm.c, mod_auth_msql.c et mod_auth_anon.c. Ceux-ci fournissent la base de la vérification de l’identité des utilisateurs, mais quelques accès (administrateur) relèvent d’un niveau plus bas, utilisant un AuthUserFile bien protégé.

Comportement par défaut

Par défaut, le contrôle est toujours effectué et un ID utilisateur ou une règle inconnus produiront une réponse « Authorization Required ». Ne pas configurer cette directive n’ôte donc rien à la sécurité du système.

Sécurité

Le fichier .htaccess peut permettre à un utilisateur de transmettre l’authentification de manière similaire, vous devez donc vérifier que c’est bien ce que vous souhaitez. Il est généralement plus simple de sécuriser un unique fichier .htaccess plutôt qu’une base de données comme mSQL. Assurez-vous que le fichier indiqué par AuthUserFile se trouve en dehors de l’arborescence des documents du serveur ; ne le placez pas dans le répertoire qu’il protège, sinon les clients pourraient le télécharger.

AuthDBAuthoritative

AuthDBAuthoritative on|off

Valeur par défaut : on

.htaccess

Mettre cette directive à off permet de transmettre l’authentification et l’autorisation à des modules de plus bas niveau (tels qu’ils sont définis dans le fichier de configuration et dans modules.c ) s’il n’y a pas d’autre ID utilisateur ou règle qui correspond à l’ID fourni par le client. Si au contraire un ID utilisateur ou une règle coïncide avec l’ID envoyé par le client, les vérifications de mot de passe et d’accès habituels s’appliqueront et un échec provoquera une réponse « Authorization Required ».

Si un ID utilisateur apparaît dans la base de données de plusieurs modules, ou si une directive Require s’applique à plus d’un module, le premier d’entre eux vérifiera l’identité et aucun accès ne sera transmis -- quelle que soit la valeur de AuthDBAuthoritative.

On utilise souvent ce mécanisme avec l’un des modules d’authentification de base, comme mod_auth.c. Bien que ce module DB fournisse la base de la vérification de l’identité des utilisateurs, quelques accès (administrateur) relèvent d’un niveau plus bas, utilisant un fichier .htaccess bien protégé.

Comportement par défaut

Par défaut, le contrôle est toujours effectué et un ID utilisateur ou une règle inconnus produiront une réponse « Authorization Required ». Ne pas configurer cette directive n’enlève donc rien à la sécurité du système.

Sécurité

Le fichier .htaccess peut permettre à un utilisateur de transmettre l’authentification de manière similaire, vous devez donc vérifier que c’est bien ce que vous souhaitez. Il est généralement plus simple de sécuriser un unique fichier .htpasswd plutôt qu’une base de données qui pourrait avoir plusieurs interfaces d’accès.

AuthDBMAuthoritative

AuthDBMAuthoritative on|off

Valeur par défaut : on

Répertoire, .htaccess

Mettre cette directive à off permet de transmettre l’authentification et l’autorisation à des modules de plus bas niveau (tels qu’ils sont définis dans le fichier de configuration et dans modules.c ) s’il n’y a pas d’autre ID utilisateur ou règle qui correspond à l’ID fourni par le client. Si au contraire un ID utilisateur ou une règle coïncide avec l’ID envoyé par le client, les vérifications de mot de passe et d’accès habituels s’appliqueront et un échec provoquera une réponse « Authorization Required ».

Si un ID utilisateur apparaît dans la base de données de plusieurs modules, ou si une directive Require s’applique à plus d’un module, le premier d’entre eux vérifiera l’identité et aucun accès ne sera oublié -- quelle que soit la valeur de AuthDBMAuthoritative.

On utilise souvent ce mécanisme avec l’un des modules d’authentification de base, comme mod_auth.c. Bien que ce module DBM fournisse la base de la vérification de l’identité des utilisateurs, quelques accès (administrateur) relèvent d’un niveau plus bas, utilisant un fichier .htpasswd bien protégé.

Comportement par défaut

Par défaut, le contrôle est toujours effectué et un ID utilisateur ou une règle inconnus produiront une réponse « Authorization Required ». Ne pas configurer cette directive n’enlève donc rien à la sécurité du système.

Sécurité

Le fichier .htaccess peut permettre à un utilisateur de transmettre l’authentification de manière similaire, vous devez donc vérifier que c’est bien ce que vous souhaitez. Il est généralement plus simple de sécuriser un unique fichier .htpasswd plutôt qu’une base de données qui pourrait avoir plusieurs interfaces d’accès.

require

require [user utilisateur1 utilisateur2 ...] [group groupe1 groupe2...]

[valid-user] [valid-group] [file-owner] [file-group]

Répertoire, .htaccess

require est la directive essentielle, qui met en marche la vérification des mots de passe.

L’option valid-user permet d’accepter n’importe quel utilisateur présent dans le fichier des mots de passe. Ne vous trompez pas en tapant valid_user, ou vous aurez une erreur d’autorisation difficile à expliquer lorsque vous tenterez d’accéder à ce site via un navigateur. En effet, Apache ne se soucie pas de ce qu’il y a après require et interprétera valid_user comme un nom d’utilisateur. Il serait préférable qu’il renvoie un message d’erreur, mais require est utilisé par de nombreux modules et il n’y a pas moyen (avec l’API actuelle) de connaître les valeurs correctes.

file-owner

[À partir d’Apache 1.3.20] Le nom et le mot de passe fournis doivent se trouver dans la base de données AuthUserFile et le nom doit correspondre à celui du propriétaire système du fichier demandé. Ainsi, si le système d’exploitation indique que ce fichier appartient à jean, le nom pour y accéder via le Web doit également être jean.

file-group

[À partir d’Apache 1.3.20] Le nom et le mot de passe fournis doivent se trouver dans la base de données AuthUserFile et le nom du groupe propriétaire du fichier demandé doit être dans la base AuthGroupFile. Le nom de l’utilisateur fourni doit être membre de ce groupe : si le système d’exploitation indique, par exemple, que le fichier demandé appartient au groupe compta, ce groupe doit se trouver dans la base AuthGroupFile et le nom d’utilisateur fourni doit être membre de ce groupe.

Nous pourrions écrire :

require user bill ben simon

pour n’autoriser que ces utilisateurs, pourvu qu’ils existent également dans la table des mots de passe. Nous pourrions également écrire :

require group cleaners

au cas où seuls sonia et daphne doivent être autorisées à accéder au site, pourvu qu’elles aient des mots de passe corrects et que AuthGroupFile soit correctement configuré.

Le bloc qui protège ... /cgi-bin pourrait sans problème être laissé sans protection d’accès dans un bloc séparé, mais comme la protection du répertoire ... /salesmen n’intervient que lors de l’accès à sales.butterthlies.com, autant mettre la directive require dans le bloc du répertoire consacré à ce site.

satisfy

satisfy [any|all]

Valeur par défaut : all

Répertoire, .htaccess

satisfy configure la politique d’accès lorsque les directives allow et require sont toutes les deux utilisées. Cette directive ne sert que si l’accès à une zone particulière dépend à la fois d’un nom d’utilisateur/mot de passe et de l’adresse de la machine cliente. Dans ce cas, le comportement par défaut ( all ) consiste à exiger que le client satisfasse aux règles d’accès par adresse et qu’il fournisse un nom et un mot de passe corrects. Avec any l’accès sera autorisé si le client satisfait aux règles d’accès par adresse, ou s’il fournit un nom et un mot de passe corrects : cela permet d’autoriser les clients ayant des adresses particulières à accéder à des zones à accès limité, sans leur demander de mot de passe.

Si nous voulons, par exemple, que tous les utilisateurs, sauf ceux du site 1.2.3.4, fournissent un mot de passe :

<config. habituelle de l’authentification (domaine, fichiers etc.)>

require valid-user

Satisfy any

order deny,allow

allow from 1.2.3.4

deny from all