Serveur Apache HTTP Version 2.4
![](feather.png)
Module Apache mod_authz_core
Description: | Autorisation basique |
---|---|
Statut: | Base |
Identificateur de Module: | authz_core_module |
Fichier Source: | mod_authz_core.c |
Compatibilité: | Disponible depuis la version 2.3 d'Apache HTTPD |
Sommaire
Ce module fournit des fonctionnalités d'autorisation basiques
permettant d'accorder ou refuser l'accès à certaines zones du site
web aux utilisateurs authentifiés. mod_authz_core
donne la possibilité d'enregistrer divers fournisseurs
d'autorisation. Il est en général utilisé avec un module fournisseur
d'authentification comme mod_authn_file
, et un
module d'autorisation comme mod_authz_user
. Il
permet aussi l'application d'une logique élaborée au déroulement du
processus d'autorisation.
Création des alias du fournisseur d'autorisation
Il est possible de créer des fournisseurs d'autorisation étendus
dans le fichier de configuration et de leur assigner un nom d'alias.
On peut ensuite utiliser ces fournisseurs aliasés dans une
directive Require
de
la même manière qu'on le ferait pour des fournisseurs d'autorisation
de base. En plus de la possibilité de créer et d'aliaser un
fournisseur étendu, le même fournisseur d'autorisation étendu peut
être référencé par plusieurs localisations.
Exemple
Dans l'exemple suivant, on crée deux alias de fournisseur d'autorisation ldap différents basés sur le fournisseur d'autorisation ldap-group. Il est ainsi possible pour un seul répertoire de vérifier l'appartenance à un groupe dans plusieurs serveurs ldap :
<AuthzProviderAlias ldap-group ldap-group-alias1 cn=my-group,o=ctx> AuthLDAPBindDN cn=youruser,o=ctx AuthLDAPBindPassword yourpassword AuthLDAPURL ldap://ldap.host/o=ctx </AuthzProviderAlias> <AuthzProviderAlias ldap-group ldap-group-alias2 cn=my-other-group,o=dev> AuthLDAPBindDN cn=yourotheruser,o=dev AuthLDAPBindPassword yourotherpassword AuthLDAPURL ldap://other.ldap.host/o=dev?cn </AuthzProviderAlias> Alias "/secure" "/webpages/secure" <Directory "/webpages/secure"> Require all granted AuthBasicProvider file AuthType Basic AuthName LDAP_Protected_Place #implied OR operation Require ldap-group-alias1 Require ldap-group-alias2 </Directory>
Conteneurs d'autorisation
Les directives de conteneur d'autorisation <RequireAll>
,
<RequireAny>
et <RequireNone>
peuvent être combinées entre elles et avec la directive Require
pour confectionner une
logique d'autorisation complexe.
L'exemple ci-dessous illustre la logique d'autorisation suivante.
Pour pouvoir accéder à la ressource, l'utilisateur doit être
l'utilisateur superadmin
, ou appartenir aux deux
groupes LDAP admins
et Administrateurs
et
soit appartenir au groupe ventes
ou avoir
ventes
comme valeur de l'attribut LDAP
dept
. De plus, pour pouvoir accéder à la ressource,
l'utilisateur ne doit appartenir ni au groupe temps
, ni
au groupe LDAP Employés temporaires
.
<Directory "/www/mydocs"> <RequireAll> <RequireAny> Require user superadmin <RequireAll> Require group admins Require ldap-group cn=Administrators,o=Airius <RequireAny> Require group sales Require ldap-attribute dept="sales" </RequireAny> </RequireAll> </RequireAny> <RequireNone> Require group temps Require ldap-group cn=Temporary Employees,o=Airius </RequireNone> </RequireAll> </Directory>
Les directives Require
Le module mod_authz_core
met à disposition des
fournisseurs d'autorisation génériques utilisables avec la directive
Require
.
Require env
Le fournisseur env
permet de contrôler l'accès au
serveur en fonction de l'existence d'une variable d'environnement. Lorsque Require
env env-variable
est spécifié, la requête se voit
autoriser l'accès si la variable d'environnement
env-variable existe. Le serveur permet de définir
facilement des variables d'environnement en fonction des
caractéristiques de la requête du client via les directives fournies
par le module mod_setenvif
. Cette directive Require
env permet donc de contrôler l'accès en fonction des
valeurs des en-têtes de la requête HTTP tels que
User-Agent
(type de navigateur), Referer
,
entre autres.
SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in <Directory "/docroot"> Require env let_me_in </Directory>
Avec cet exemple, les navigateurs dont la chaîne user-agent
commence par KnockKnock/2.0
se verront autoriser
l'accès, alors que tous les autres seront rejetés.
Lorsque le serveur cherche un chemin via une sous-requête interne (par exemple la
recherche d'un DirectoryIndex
), ou lorsqu'il génère un
listing du contenu d'un répertoire via le module
mod_autoindex
, la sous-requête n'hérite pas des
variables d'environnement spécifiques à la requête. En outre, à cause
des phases de l'API auxquelles mod_setenvif
prend
part, les directives SetEnvIf
ne sont pas évaluées
séparément dans la sous-requête.
Require all
Le fournisseur all
reproduit la fonctionnalité
précédemment fournie par les directives 'Allow from all' et 'Deny
from all'. Il accepte un argument dont les deux valeurs possibles
sont : 'granted' ou 'denied'. Les exemples suivants autorisent ou
interdisent l'accès à toutes les requêtes.
Require all granted
Require all denied
Require method
Le fournisseur method
permet d'utiliser la méthode
HTTP dans le processus d'autorisation. Les méthodes GET et HEAD sont
ici considérées comme équivalentes. La méthode TRACE n'est pas
supportée par ce fournisseur ; utilisez à la place la directive
TraceEnable
.
Dans l'exemple suivant, seules les méthodes GET, HEAD, POST, et OPTIONS sont autorisées :
Require method GET POST OPTIONS
Dans l'exemple suivant, les méthodes GET, HEAD, POST, et OPTIONS sont autorisées sans authentification, alors que toutes les autres méthodes nécessitent un utilisateur valide :
<RequireAny> Require method GET POST OPTIONS Require valid-user </RequireAny>
Require expr
Le fournisseur expr
permet d'accorder l'autorisation
d'accès de base en fonction d'expressions arbitraires.
Require expr "%{TIME_HOUR} -ge 9 && %{TIME_HOUR} -le 17"
<RequireAll> Require expr "!(%{QUERY_STRING} =~ /secret/)" Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }" </RequireAll>
Require expr "!(%{QUERY_STRING} =~ /secret/) && %{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
La syntaxe de l'expression est décrite dans la documentation de ap_expr.
Normalement, l'expression est évaluée avant l'authentification.
Cependant, si l'expression renvoie false et se réfère à la variable
%{REMOTE_USER}
, le processus d'authentification sera
engagé et l'expression réévaluée.
Directive AuthMerging
Description: | Définit la manière dont chaque logique d'autorisation des sections de configuration se combine avec celles des sections de configuration précédentes. |
---|---|
Syntaxe: | AuthMerging Off | And | Or |
Défaut: | AuthMerging Off |
Contexte: | répertoire, .htaccess |
AllowOverride: | AuthConfig |
Statut: | Base |
Module: | mod_authz_core |
Lorsque l'autorisation est activée, elle est normalement héritée
par chaque section de
configuration suivante, à moins qu'un jeu de directives
d'autorisations différent ne soit spécifié. Il s'agit du
comportement par défaut, qui correspond à la définition explicite
AuthMerging Off
.
Dans certaines situations cependant, il peut être souhaitable de
combiner la logique d'autorisation d'une section de configuration
avec celle de la section précédente lorsque les sections de
configuration se combinent entre elles. Dans ce cas, deux options
sont disponibles, And
et Or
.
Lorsqu'une section de configuration contient AuthMerging
And
ou AuthMerging Or
, sa logique d'autorisation
se combine avec celle de la section de configuration qui la précède
(selon l'ordre général des sections de configuration), et qui
contient aussi une logique d'autorisation, comme si les deux
sections étaient concaténées respectivement dans une directive
<RequireAll>
ou <RequireAny>
.
AuthMerging
ne concerne que la section de
configuration dans laquelle elle apparaît. Dans l'exemple suivant,
seuls les utilisateurs appartenant au groupe alpha
sont
autorisés à accéder à /www/docs
. Les utilisateurs
appartenant au groupe alpha
ou au groupe
beta
sont autorisés à accéder à
/www/docs/ab
. Cependant, la définition implicite à
Off
de la directive AuthMerging
s'applique à la section de configuration <Directory>
concernant le répertoire
/www/docs/ab/gamma
, ce qui implique que les directives
d'autorisation de cette section l'emportent sur celles des sections
précédentes. Par voie de conséquence, seuls les utilisateurs
appartenant au groupe gamma
sont autorisés à accéder à
/www/docs/ab/gamma
.<Directory "/www/docs"> AuthType Basic AuthName Documents AuthBasicProvider file AuthUserFile "/usr/local/apache/passwd/passwords" Require group alpha </Directory> <Directory "/www/docs/ab"> AuthMerging Or Require group beta </Directory> <Directory "/www/docs/ab/gamma"> Require group gamma </Directory>
Directive <AuthzProviderAlias>
Description: | Regroupe des directives représentant une extension d'un fournisseur d'autorisation de base qui pourra être référencée à l'aide de l'alias spécifié |
---|---|
Syntaxe: | <AuthzProviderAlias fournisseur-de-base Alias
Paramètres-Require>
... </AuthzProviderAlias>
|
Contexte: | configuration du serveur |
Statut: | Base |
Module: | mod_authz_core |
Les balises <AuthzProviderAlias>
et
</AuthzProviderAlias>
permettent de regrouper des
directives d'autorisation auxquelles on pourra faire référence à
l'aide de l'alias spécifié dans une directive Require
.
Directive AuthzSendForbiddenOnFailure
Description: | Envoie '403 FORBIDDEN' au lieu de '401 UNAUTHORIZED' si l'authentification réussit et si l'autorisation a été refusée. |
---|---|
Syntaxe: | AuthzSendForbiddenOnFailure On|Off |
Défaut: | AuthzSendForbiddenOnFailure Off |
Contexte: | répertoire, .htaccess |
Statut: | Base |
Module: | mod_authz_core |
Compatibilité: | Disponible depuis la version 2.3.11 d'Apache HTTPD |
Par défaut, si l'authentification réussit, alors que
l'autorisation est refusée, Apache HTTPD renvoie un code de réponse
HTTP '401 UNAUTHORIZED'. En général, les navigateurs proposent alors
une nouvelle fois à l'utilisateur la boîte de dialogue de saisie du
mot de passe, ce qui n'est pas toujours souhaitable. La directive
AuthzSendForbiddenOnFailure
permet de changer
le code de réponse en '403 FORBIDDEN'.
Avertissement de sécurité
La modification de la réponse en cas de refus d'autorisation diminue la sécurité du mot de passe, car elle indique à un éventuel attaquant que le mot de passe qu'il a saisi était correct.
Directive Require
Description: | Vérifie si un utilisateur authentifié a une autorisation d'accès accordée par un fournisseur d'autorisation. |
---|---|
Syntaxe: | Require [not] nom-entité [nom-entité]
... |
Contexte: | répertoire, .htaccess |
AllowOverride: | AuthConfig |
Statut: | Base |
Module: | mod_authz_core |
Cette directive permet de vérifier si un utilisateur authentifié
a l'autorisation d'accès accordée pour un certain fournisseur
d'autorisation et en tenant compte de certaines restrictions.
mod_authz_core
met à disposition les fournisseurs
d'autorisation génériques suivants :
Require all granted
- L'accès est autorisé sans restriction.
Require all denied
- L'accès est systématiquement refusé.
Require env env-var [env-var] ...
- L'accès n'est autorisé que si l'une au moins des variables d'environnement spécifiées est définie.
Require method http-method [http-method] ...
- L'accès n'est autorisé que pour les méthodes HTTP spécifiées.
Require expr expression
- L'accès est autorisé si expression est évalué à vrai.
Voici quelques exemples de syntaxes autorisées par
mod_authz_user
, mod_authz_host
et
mod_authz_groupfile
:
Require user identifiant utilisateur [identifiant utilisateur] ...
- Seuls les utilisateurs spécifiés auront accès à la ressource.
Require group nom groupe [nom groupe] ...
- Seuls les utilisateurs appartenant aux groupes spécifiés auront accès à la ressource.
Require valid-user
- Tous les utilisateurs valides auront accès à la ressource.
Require ip 10 172.20 192.168.2
- Les clients dont les adresses IP font partie des tranches spécifiées auront accès à la ressource.
D'autres modules d'autorisation comme
mod_authnz_ldap
, mod_authz_dbm
,
mod_authz_dbd
,
mod_authz_owner
et mod_ssl
implémentent des options de la directive Require.
Pour qu'une configuration d'authentification et d'autorisation
fonctionne correctement, la directive Require
doit être accompagnée dans la plupart des cas de directives AuthName
, AuthType
et AuthBasicProvider
ou AuthDigestProvider
, ainsi que
de directives telles que AuthUserFile
et AuthGroupFile
(pour la
définition des utilisateurs et des groupes). Exemple :
AuthType Basic AuthName "Restricted Resource" AuthBasicProvider file AuthUserFile "/web/users" AuthGroupFile "/web/groups" Require group admin
Les contrôles d'accès appliqués de cette manière sont effectifs
pour toutes les méthodes. C'est d'ailleurs
ce que l'on souhaite en général. Si vous voulez n'appliquer
les contrôles d'accès qu'à certaines méthodes, tout en laissant les
autres méthodes sans protection, placez la directive
Require
dans une section <Limit>
.
Le résultat de la directive Require
peut
être inversé en utilisant l'option not
. Comme dans le
cas de l'autre directive d'autorisation inversée <RequireNone>
, si la directive
Require
est inversée, elle ne peut qu'échouer
ou produire un résultat neutre ; elle ne peut donc alors pas
autoriser une requête de manière indépendante.
Dans l'exemple suivant, tous les utilisateurs appartenant aux
groupes alpha
et beta
ont l'autorisation
d'accès, à l'exception de ceux appartenant au groupe
reject
.
<Directory "/www/docs"> <RequireAll> Require group alpha beta Require not group reject </RequireAll> </Directory>
Lorsque plusieurs directives Require
sont
placées dans une même section de
configuration, et ne se trouvent pas dans une autre directive
d'autorisation comme <RequireAll>
, elles sont implicitement
contenues dans une directive <RequireAny>
. Ainsi, la première directive
Require
qui autorise l'accès à un utilisateur
autorise l'accès pour l'ensemble de la requête, et les directives
Require
suivantes sont ignorées.
Avertissement à propos de la sécurité
Prettez une attention particulière aux directives d'autorisation
définies
au sein des sections Location
qui se chevauchent avec des contenus servis depuis le système de
fichiers. Par défaut, les configurations définies dans ces sections l'emportent sur les
configurations d'autorisations définies au sein des sections
Directory
et Files
sections.
La directive AuthMerging
permet de contrôler
la manière selon laquelle les configurations d'autorisations sont
fusionnées au sein des sections précitées.
Voir aussi
Directive <RequireAll>
Description: | Regroupe plusieurs directives d'autorisation dont aucune ne doit échouer et dont au moins une doit retourner un résultat positif pour que la directive globale retourne elle-même un résultat positif. |
---|---|
Syntaxe: | <RequireAll> ... </RequireAll> |
Contexte: | répertoire, .htaccess |
AllowOverride: | AuthConfig |
Statut: | Base |
Module: | mod_authz_core |
Les balises <RequireAll>
et
</RequireAll>
permettent de regrouper des
directives d'autorisation dont aucune ne doit échouer, et dont au
moins une doit retourner un résultat positif pour que la directive
<RequireAll>
retourne elle-même
un résultat positif.
Si aucune des directives contenues dans la directive <RequireAll>
n'échoue, et si au moins une
retourne un résultat positif, alors la directive <RequireAll>
retourne elle-même un résultat
positif. Si aucune ne retourne un résultat positif, et si aucune
n'échoue, la directive globale retourne un résultat neutre. Dans
tous les autres cas, elle échoue.
Voir aussi
Directive <RequireAny>
Description: | Regroupe des directives d'autorisation dont au moins une doit retourner un résultat positif pour que la directive globale retourne elle-même un résultat positif. |
---|---|
Syntaxe: | <RequireAny> ... </RequireAny> |
Contexte: | répertoire, .htaccess |
AllowOverride: | AuthConfig |
Statut: | Base |
Module: | mod_authz_core |
Les balises <RequireAny>
et
</RequireAny>
permettent de regrouper des
directives d'autorisation dont au moins une doit retourner un
résultat positif pour que la directive <RequireAny>
retourne elle-même un résultat
positif.
Si une ou plusieurs directives contenues dans la directive
<RequireAny>
retournent un
résultat positif, alors la directive <RequireAny>
retourne elle-même un résultat
positif. Si aucune ne retourne un résultat positif et aucune
n'échoue, la directive globale retourne un résultat neutre. Dans
tous les autres cas, elle échoue.
<RequireAny>
(elles pourraient tout au plus
faire échouer la directive dans le cas où elles échoueraient
elles-mêmes, et où
toutes les autres directives retourneraient un résultat neutre).
C'est pourquoi il n'est pas permis d'utiliser les directives
d'autorisation inversées dans une directive <RequireAny>
.Voir aussi
Directive <RequireNone>
Description: | Regroupe des directives d'autorisation dont aucune ne doit retourner un résultat positif pour que la directive globale n'échoue pas. |
---|---|
Syntaxe: | <RequireNone> ... </RequireNone> |
Contexte: | répertoire, .htaccess |
AllowOverride: | AuthConfig |
Statut: | Base |
Module: | mod_authz_core |
Les balises <RequireNone>
et
</RequireNone>
permettent de regrouper des
directives d'autorisation dont aucune ne doit retourner un résultat
positif pour que la directive <RequireNone>
n'échoue pas.
Si une ou plusieurs directives contenues dans la directive
<RequireNone>
retournent un
résultat positif, la directive <RequireNone>
échouera. Dans tous les
autres cas, cette dernière retournera un résultat neutre. Ainsi,
comme pour la directive d'autorisation inversée Require
not
, elle ne peut jamais autoriser une requête de manière
indépendante car elle ne pourra jamais retourner un résultat
positif. Par contre, on peut l'utiliser pour restreindre l'ensemble
des utilisateurs autorisés à accéder à une ressource.
<RequireNone>
.
C'est pourquoi il n'est pas permis d'utiliser les directives
d'autorisation inversées dans une directive <RequireNone>
.