Mise en mémoire cache pour le contrôle d'accès

Le contrôle d'accès utilise en interne plusieurs mémoires cache afin d'améliorer les temps de décision. Vous pouvez améliorer les performances du contrôle d'accès pour des scénarios particuliers en définissant la durée de vie et la taille de ces mémoires cache via le service Gestionnaire de cache. Dans la plupart des cas, les paramètres par défaut de la mémoire cache permettent d'obtenir des performances satisfaisantes pour HCL. Cependant, si vous disposez d'un grand nombre de ressources ou de ressources personnalisées, vous pouvez envisager d'ajuster les paramètres de mémoire cache et de réaliser des tests afin d'identifier les compromis liés aux performances optimales.

Comportement d'invalidation de la mémoire cache

Dans la plupart des cas, toutes les mémoires cache de contrôle d'accès requises sont invalidées dès que la configuration du contrôle d'accès est effectuée (par exemple, lors de l'attribution de rôles à un utilisateur). Si vous utilisez une autorisation Externe, il n'est pas possible de synchroniser en continu les mémoires cache avec les modifications apportées aux rôles gérés en externe. Pour que ces dernières soient prises en compte, les utilisateurs déjà authentifiés sur le portail doivent attendre que la mémoire cache arrive à expiration, ou bien fermer leur session et en ouvrir une autre. Cette dernière opération provoque toujours l'invalidation de toutes les mémoires cache liées à l'utilisateur en cours.

Il existe trois autres cas dans lesquels l'invalidation n'est pas immédiate, ce qui oblige l'utilisateur à se reconnecter ou à attendre l'expiration de la mémoire cache :
  • Si un rôle est octroyé à un groupe d'utilisateurs ou révoqué, la modification des droits d'accès n'est pas immédiatement appliquée aux membres de ce groupe actuellement connectés.
  • Si un bloc de rôles est défini ou supprimé, la modification des droits d'accès n'est pas immédiatement appliquée aux utilisateurs actuellement connectés.
  • Si les groupes imbriqués sont activés et si un groupe A est ajouté au groupe B ou supprimé, les modifications des droits d'accès ne sont pas immédiatement appliquées aux membres du groupe A actuellement connectés.
Comme dans le cas externe, les droits d'accès peuvent être actualisés au moyen d'une déconnexion suivie d'une reconnexion de l'utilisateur. Vous pouvez également modifier les propriétés suivantes du fichier wp_profile_root/PortalServer/config/CacheManagerService.properties pour changer le comportement de la mise en mémoire cache :
  • Pour la désactiver complètement et permettre la propagation immédiate de toutes les modifications apportées aux autorisations, supprimez la marque de commentaire de la propriété cacheinstance.com.ibm.wps.ac.AccessControlUserContextCache.enabled et affectez la valeur false. Cette opération peut avoir une incidence importante sur les performances.
  • Pour accélérer l'actualisation des autorisations via une temporisation, la durée de vie de ce cache peut être écourtée en affectant à la propriété cacheinstance.com.ibm.wps.ac.AccessControlUserContextCache.lifetime une valeur numérique plus faible (en secondes). Ces paramètres peuvent avoir une incidence sur les performances.
  • Dans le cas de groupes imbriqués, vous pouvez également modifier les valeurs des propriétés enabled ou lifetime pour les paramètres cacheinstance.com.ibm.wps.ac.groupmanagement.NestedGroupCache et cacheinstance.com.ibm.wps.ac.groupmanagement.GroupCache. Ces paramètres peuvent avoir une incidence sur les performances.
  • Si vous configurez le contrôle d'accès pour utiliser les groupes imbriqués, désactivez cacheinstance.com.ibm.wps.ac.groupmanagement.GroupCache et modifiez la valeur des propriétés enabled et lifetime pour cacheinstance.com.ibm.wps.ac.groupmanagement.NestedGroupCache.

    Si vous utilisez le cache de groupe, désactivez cacheinstance.com.ibm.wps.ac.groupmanagement.NestedGroupCache et modifiez les valeurs des propriétés enabled et lifetime pour cacheinstance.com.ibm.wps.ac.groupmanagement.GroupCache.

    Ces paramètres peuvent avoir une incidence sur les performances.
  • Toutes les données de cache spécifiques aux utilisateurs et aux groupes d'utilisateurs peuvent être invalidées de manière explicite lors de l'authentification des connexions utilisateur par l'intermédiaire des deux paramètres de configuration suivants, à l'aide de WebSphere®la console Integrated Solutions Console :
    Remarque : Ces deux paramètres augmentent la charge du service de réplication dynamique sur le serveur d'applications d'un environnement en cluster et peuvent donc avoir un impact sur les performances.
    • Accédez à Fournisseurs d'environnement de ressources > WP PACGroupManagementService > Propriétés personnalisées. Ajoutez ou mettez à jour accessControlGroupManagement.invalidateGroupCacheOnLoginLogout avec la valeur true.
    • Accédez à Fournisseurs d'environnement de ressources > WP AccessControlDataManagementService > Propriétés personnalisées. Ajoutez ou mettez à jour accessControlDataManagement.invalidateResourceCacheOnLoginLogout avec la valeur true.
Remarque : Une fois le fichier CacheManagerService.properties modifié, exécutez la tâche suivante dans le répertoire wp_profile_root/ConfigEngine pour appliquer les modifications :
  • UNIX™Linux™ : ./ConfigEngine.sh update-properties -DWasPassword=password
  • IBM® i : ConfigEngine.sh update-properties -DWasPassword=password
  • Windows™ : ConfigEngine.bat update-properties -DWasPassword=password
Remarque : Sous z/OS®, modifiez le fichier CacheManagerService.properties. Ensuite, ouvrez une invite de commande USS (UNIX System Services) ou un client Telnet et exécutez la tâche ./ConfigEngine.sh update-properties -DWasPassword=password, à partir du répertoirewp_profile_root/ConfigEngine, pour appliquer les modifications.