Serveur HTTP Apache Version 2.4
Serveur HTTP Apache Version 2.4
| 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 |
Maintient un cache des données d'authentification pour limiter les sollicitations du serveur d'arrière-plan.
Certains utilisateurs qui mettent en 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.
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 :
AuthnCacheProvideFor.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 :
#AuthnCacheSOCache est optionnel. S'il est défini, il l'est pour
#l'ensemble du serveur
AuthnCacheSOCache dbm
<Directory "/usr/www/myhost/private">
AuthType Basic
AuthName "Cached Authentication Example"
AuthBasicProvider socache dbd
AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
AuthnCacheProvideFor dbd
Require valid-user
#Optionnel
AuthnCacheContext dbd-authn-example
</Directory>
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 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.
| Description: | Spécifie une chaîne de contexte à utiliser dans la clé du cache |
|---|---|
| Syntaxe: | AuthnCacheContext directory|server|custom-string |
| Défaut: | AuthnCacheContext 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.
| Description: | Active la mise en cache de l'authentification en tout endroit |
|---|---|
| Syntaxe: | AuthnCacheEnable |
| Contexte: | configuration globale |
| 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 apache2.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.
| 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 |
| Surcharges autorisées: | 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
| Description: | Sélectionne le fournisseur socache d'arrière-plan à utiliser |
|---|---|
| Syntaxe: | AuthnCacheSOCache nom-fournisseur[:arguments-fournisseur] |
| Contexte: | configuration globale |
| Statut: | Base |
| Module: | mod_authn_socache |
| Compatibilité: | Les arguments optionnels du fournisseur sont disponibles à partir de la version 2.4.7 du serveur HTTP Apache |
Cette définition s'applique à l'ensemble du serveur et permet de sélectionner un fournisseur pour le cache d'objets partagés, ainsi que des arguments éventuels pour ce fournisseur. Les fournisseurs disponibles sont, entre autres, "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.
| Description: | Définit une durée de vie pour les entrées du cache |
|---|---|
| Syntaxe: | AuthnCacheTimeout durée-de-vie (secondes) |
| Défaut: | AuthnCacheTimeout 300 (5 minutes) |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | 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 ; une durée de vie plus longue peut être paramétrée 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.