Module Apache mod_authn_socache

Langues Disponibles: en | + fr

+ + + + +

Description:	Gère un cache des données d'authentification pour diminuer +la charge des serveurs d'arrière-plan
Statut:	Base
Identificateur de Module:	authn_socache_module
Fichier Source:	mod_authn_socache.c
Compatibilité:	Versions 2.3 et ultérieures

Sommaire

+ +

Maintient un cache des données d'authentification afin que la + recherche d'un nouveau serveur d'arrière-plan pour chaque requête + authentifiée ne soit plus nécessaire.

Sujets

Mise en cache des données d'authentification
Utilisation
La mise en cache avec les modules tiers

Commentaires

Mise en cache des données d'authentification

Certains utilisateurs qui mettent oeuvre une authentification + lourde s'appuyant par exemple sur des requêtes SQL + (mod_authn_dbd) ont signalé une charge induite + inacceptable sur leur fournisseur d'authentification. Cela se + produit typiquement dans le cas où une page HTML contient des + centaines d'objets (images, scripts, pages de styles, media, + etc...), et où une requête pour cette page génère des centaines de + sous-requêtes à effet immédiat pour des contenus supplémentaires + authentifiés.

Pour résoudre ce problème, mod_authn_socache fournit une solution + qui permet de maintenir un cache des données d'authentification.

Utilisation

Le cache d'authentification doit être utilisé lorsque les + requêtes d'authentification induisent une charge significative sur le + serveur, le serveur d'arrière-plan ou le réseau. Cette mise en cache + n'apportera probablement aucune amélioration dans le cas d'une + authentification à base de fichier (mod_authn_file) + ou de base de données dbm (mod_authn_dbm) car ces + méthodes sont de par leur conception rapides et légères (la mise en + cache peut cependant s'avérer utile dans le cas où le fichier est + situé sur un montage réseau). Les fournisseurs d'authentification + basés sur SQL ou LDAP ont plus de chances de tirer parti de cette + mise en cache, en particulier lorsqu'un problème de performances est + détecté. mod_authnz_ldap gérant son propre cache, + seul mod_authn_dbd est concerné par notre sujet.

Les principales règles à appliquer pour la mise en cache sont :

Inclure le fournisseur pour lequel vous voulez effectuer une + mise en cache dans une directive + AuthnCacheProvideFor.
Mettre socache avant le fournisseur pour lequel + vous voulez effectuer une mise en cache dans votre directive + AuthBasicProvider + ou AuthDigestProvider.

Voici un exemple simple permettant d'accélérer + mod_authn_dbd et utilisant dbm comme moteur de la + mise en cache :

+<Directory /usr/www/myhost/private>
+    AuthType Basic
+    AuthName "Cached Authentication Example"
+    AuthBasicProvider socache dbd
+    AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
+    AuthnCacheProvideFor dbd
+    AuthnCacheContext dbd-authn-example
+    AuthnCacheSOCache dbm
+    Require valid-user
+</Directory>
+

+ +

La mise en cache avec les modules tiers

Les développeurs de modules doivent savoir que la mise en cache + avec mod_authn_socache doit être activée dans leurs modules. La + fonction simple de l'API ap_authn_cache_store permet de + mettre en cache les données d'authentification qu'un fournisseur + vient de rechercher ou de générer. Vous trouverez des exemples + d'utilisation à r957072, où trois fournisseurs authn sont activés pour la mise + en cache.

AuthnCacheContext Directive

+ + + + + + + +

Description:	Spécifie une chaîne de contexte à utiliser dans la clé du +cache
Syntaxe:	`AuthnCacheContext directory\|server\|chaîne-personnalisée`
Défaut:	`directory`
Contexte:	répertoire
Statut:	Base
Module:	mod_authn_socache

Cette directive permet de spécifier une chaîne à utiliser avec le + nom d'utilisateur fourni (et le domaine d'authentification - realm - + dans le cas d'une authentification à base de condensés) lors de la + construction d'une clé de cache. Ceci permet de lever l'ambiguïté + entre plusieurs noms d'utilisateurs identiques servant différentes + zones d'authentification sur le serveur.

Il y a deux valeurs spéciales pour le paramètre : directory, + qui utilise le contexte de répertoire de la requête comme chaîne, et + server, qui utilise le nom du serveur virtuel.

La valeur par défaut est directory, qui est aussi la + définition la plus courante. Ceci est cependant loin d'être optimal, + car par exemple, $app-base, $app-base/images, + $app-base/scripts et $app-base/media + possèderont chacun leur propre clé de cache. Il est préférable + d'utiliser le fournisseur de mot de passe : par exemple un fichier + htpasswd ou une table de base de données.

Les contextes peuvent être partagés entre différentes zones du + serveur, où les données d'authentification sont partagées. Ceci est + cependant susceptible de créer des trous de sécurité de type + cross-site ou cross-application, et cette directive n'est donc pas + disponible dans les contextes .htaccess.

+ +

AuthnCacheEnable Directive

+ + + + + + + +

Description:	Active la mise en cache de l'authentification en tout +endroit
Syntaxe:	`AuthnCacheEnable`
Contexte:	configuration du serveur
AllowOverride:	None
Statut:	Base
Module:	mod_authn_socache

Normalement, cette directive n'est pas nécessaire : l'activation + est implicite si la mise en cache de l'authentification a été + activée en tout autre endroit du fichier httpd.conf. Par + contre, si cette mise en cache n'a pas été activée, par défaut, elle + ne sera pas initialisée, et ne sera donc pas disponible dans un + contexte de fichier .htaccess. Cette directive permet + d'être sûr que la mise en cache a bien été activée et pourra + donc être utilisée dans les fichiers .htaccess.

+ +

AuthnCacheProvideFor Directive

+ + + + + + + + +

Description:	Spécifie le fournisseur pour lequel on veut effectuer une +mise en cache
Syntaxe:	`AuthnCacheProvideFor fournisseur-authn [...]`
Défaut:	`None`
Contexte:	répertoire, .htaccess
AllowOverride:	AuthConfig
Statut:	Base
Module:	mod_authn_socache

Cette directive permet de spécifier un ou plusieurs fournisseurs + pour le(s)quel(s) on veut effectuer une mise en cache. Les données + d'authentification trouvées par un fournisseur non spécifié dans une + directive AuthnCacheProvideFor ne seront pas mises en cache.

+ +

Par exemple, pour mettre en cache les données d'authentification + trouvées par mod_authn_dbd ou par un fournisseur + personnalisé mon-fournisseur, et ne pas mettre en cache + celles trouvées par les fournisseurs légers comme file ou dbm :

+AuthnCacheProvideFor dbd mon-fournisseur
+

+ + +

AuthnCacheSOCache Directive

+ + + + + + + +

Description:	Sélectionne le fournisseur socache d'arrière-plan à +utiliser
Syntaxe:	`AuthnCacheSOCache nom-fournisseur`
Contexte:	configuration du serveur
AllowOverride:	None
Statut:	Base
Module:	mod_authn_socache

Cette définition s'applique à l'ensemble du serveur et permet de + sélectionner un fournisseur pour le cache + d'objets partagés. Les fournisseurs disponibles sont "dbm", + "dc", "memcache", ou "shmcb", chacun d'entre eux nécessitant le chargement + du module approprié. Si elle est + absente, c'est la valeur par défaut pour votre plate-forme qui sera + utilisée.

+ +

AuthnCacheTimeout Directive

+ + + + + + + + +

Description:	Définit une durée de vie pour les entrées du cache
Syntaxe:	`AuthnCacheTimeout durée-de-vie (secondes)`
Défaut:	`300 (5 minutes)`
Contexte:	répertoire, .htaccess
AllowOverride:	AuthConfig
Statut:	Base
Module:	mod_authn_socache

La mise en cache des données d'authentification peut constituer + un trou de sécurité, bien qu'un mise en cache de courte durée ne + posera probablement pas de problème. En général, il est conseillé de + conserver les entrées du cache de façon à ce que la charge du serveur + d'arrière-plan reste normale, mais pas plus longtemps, bien + qu'une durée de vie plus longue puisse être nécessaire si les + changements d'utilisateurs et de mots de passe sont peu fréquents. + La durée de vie par défaut de 300 secondes (5 minutes) est à la fois + raisonnable et suffisamment importante pour réduire la charge d'un + serveur d'arrière-plan comme dbd (requêtes SQL).

Cette durée de vie ne doit pas être confondue avec la durée de + vie de session qui est un tout autre sujet. Cependant, vous devez + utiliser votre logiciel de gestion de session pour vérifier si les + données d'authentification mises en cache peuvent allonger + accidentellement une session, et en tenir compte lorsque vous + définissez la durée de vie.

+ +

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.