Module Apache mod_authz_core

Langues Disponibles: en | + fr

+ + + + +

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.

Sujets

Conteneurs d'autorisation
Les directives Require
Création des alias du fournisseur +d'autorisation

Traitement des bugs

Voir aussi

Commentaires

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. Avant la version 2.4.16, les doubles-quotes + étaient prohibées

+ +

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.

+ + + +

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>

+ + + +

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
Surcharges autorisées:	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>.

+ +

La définition de la directive + 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 globale
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.

+ +

Si Require-Parameters comporte plusieurs paramètres, la liste + de ces derniers doit être entourée de guillemets. Dans le cas contraire, + seul le premier paramètre de la liste sera pris en compte.

+ +

# Dans cet exemple, pour que les deux adresses IP soient prises en compte, elles
+# DOIVENT être entourées de guillemets
+<AuthzProviderAlias ip reject-ips "XXX.XXX.XXX.XXX YYY.YYY.YYY.YYY">
+</AuthzProviderAlias>
+
+<Directory "/path/to/dir">
+    <RequireAll>
+        Require not reject-ips
+        Require all granted
+    </RequireAll>
+</Directory>

+ + +

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
Surcharges autorisées:	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.
Require forward-dns dynamic.example.org: Un client dont l'adresse IP est résolue à partir du nom + dynamic.example.org aura l'autorisation d'accès. +

+ +

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
Surcharges autorisées:	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
Surcharges autorisées:	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.

+ +

Comme les directives d'autorisation inversées sont incapables + de retourner un résultat positif, elles ne peuvent pas impacter de + manière significative le résultat d'une directive <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
Surcharges autorisées:	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.

+ +

Comme les directives d'autorisation inversées sont incapables + de retourner un résultat positif, elles ne peuvent pas impacter de + manière significative le résultat d'une directive <RequireNone>. + C'est pourquoi il n'est pas permis d'utiliser les directives + d'autorisation inversées dans une directive <RequireNone>.

+ +