Cache des identités et annuaires sans notification

Chaque serveur TOSIAM garde en mémoire les identités qu’il a lues dans l’annuaire. Ce cache est tenu à jour par les notifications de l’annuaire : quand une entrée change, l’annuaire prévient TOSIAM, qui retire l’entrée de son cache. Certains magasins d’identités ne reçoivent pas ces notifications. Cette page décrit ce que fait alors TOSIAM, ce qui reste périmé pendant un temps, et les propriétés qui règlent ce délai.

Quand un magasin d’identités est-il sans notification ?#

Un magasin d’identités LDAP reçoit les modifications de l’annuaire par l’un de ces trois mécanismes :

Un magasin est sans notification dans deux cas :

• l’annuaire ne prend en charge aucun des trois mécanismes. C’est le cas d’un OpenLDAP sans l’overlay syncprov : voir Annuaire OpenLDAP pour l’activer ;
• le DN de base de la recherche persistante du magasin (sun-idrepo-ldapv3-config-psearchbase) est vide, ce qui désactive la recherche persistante, quel que soit l’annuaire.

Pour savoir ce que prend en charge un annuaire, lisez la liste de ses contrôles :

ldapsearch -H ldaps://annuaire.example.fr:636 \
  -D "cn=admin,dc=example,dc=fr" -W \
  -b "" -s base "(objectClass=*)" supportedControl

Si aucun des trois identifiants du tableau n’apparaît dans la réponse, le magasin est sans notification.

Ce que cela change#

Sans notification, un serveur TOSIAM ne voit que les modifications qu’il fait lui-même. Il ne voit pas :

• les modifications faites par un autre serveur TOSIAM de la ferme ;
• les modifications faites directement dans l’annuaire : outil d’administration, script, synchronisation depuis un référentiel RH.

Dès qu’un magasin sans notification est utilisé, TOSIAM applique deux mesures.

Les entrées du cache expirent. Une identité en cache est relue dans l’annuaire après 15 minutes pour un utilisateur, 30 minutes pour les autres types (groupes, rôles). Ces délais sont réglables : voir Propriétés.

Les attributs de verrouillage et de statut sont toujours relus. Ces attributs ne sont jamais servis depuis le cache, pour qu’un compte verrouillé ou désactivé sur un serveur le soit aussitôt sur les autres :

Les deux mesures s’appliquent à tous les magasins du serveur dès que l’un d’eux est sans notification, et cessent quand le dernier magasin sans notification est supprimé ou retrouve ses notifications.

Ce qui reste périmé jusqu’à l’expiration#

Tous les autres attributs sont servis depuis le cache jusqu’à l’expiration de l’entrée. Pendant ce délai, un serveur peut donc travailler avec une valeur ancienne pour :

• l’appartenance aux groupes, utilisée par les politiques d’autorisation et les privilèges d’administration ;
• les attributs de profil repris dans les claims OpenID Connect ou les assertions SAML ;
• les attributs lus par les nœuds d’authentification (adresse électronique, numéro de téléphone, appareils MFA).

Coût#

Les attributs de statut et de verrouillage sont relus dans la même opération LDAP que les autres contrôles du compte : cette relecture n’ajoute pas d’opération. Mesure sur une ferme de deux serveurs TOSIAM et deux annuaires TosDJ, connexion par identifiant et mot de passe suivie d’un flux OAuth 2.0 :

Le coût du mode sans notification est ailleurs : chaque identité est relue en entier à l’expiration de son entrée.

Message dans les journaux#

Au premier usage d’un magasin sans notification, TOSIAM écrit ce message dans le journal IdRepo.log du répertoire debug de l’instance, au niveau error pour qu’il soit visible avec le niveau de journalisation par défaut :

No change notification for the data store with persistent search base DN dc=example,dc=fr
(not supported by the directory): the identity cache is not invalidated when an entry is
modified by another server or directly in the directory. The cached entries expire (15 min
for users, 30 min otherwise) and the account lockout and status attributes are read from
the data store.

La parenthèse du message indique la cause :

Ce message signale un fonctionnement dégradé, pas une panne : le serveur démarre et authentifie normalement. Il est écrit une fois à chaque chargement du magasin : au démarrage, puis après chaque modification de sa configuration.

Propriétés#

Les trois propriétés se définissent dans les propriétés avancées du serveur. Elles sont lues au démarrage : redémarrez TOSIAM après une modification.

La première propriété a trois états :

Pour raccourcir le délai à 5 minutes pour les utilisateurs et 10 minutes pour les autres entrées, sur tous les serveurs :

ssoadm update-server-cfg --servername default \
  --adminid amadmin --password-file /chemin/vers/pwd.txt \
  --attributevalues \
    "com.sun.identity.idm.cache.entry.user.expire.time=5" \
    "com.sun.identity.idm.cache.entry.default.expire.time=10"

Un délai plus court réduit la durée pendant laquelle une valeur est périmée et augmente le nombre de lectures dans l’annuaire : chaque utilisateur actif est relu une fois par délai.

Rétablir les notifications#

Si l’annuaire prend en charge la recherche persistante et que le message indique (persistent search base DN is missing), renseignez le DN de base de la recherche persistante du magasin :

ssoadm update-datastore --realm /employees --name users \
  --adminid amadmin --password-file /chemin/vers/pwd.txt \
  --attributevalues "sun-idrepo-ldapv3-config-psearchbase=dc=example,dc=fr"

La modification est prise en compte à chaud. Le compte de service du magasin doit avoir le droit d’utiliser le contrôle de recherche persistante dans l’annuaire.

Avec OpenLDAP, les notifications demandent l’overlay syncprov dans l’annuaire et TOSIAM 3.38.0 : voir Annuaire OpenLDAP. Sans cela, choisissez les délais d’expiration en fonction du temps pendant lequel une appartenance à un groupe ou un attribut de profil peut rester périmé dans votre contexte.

Pour aller plus loin#

• Annuaire OpenLDAP : cache des DN, attributs de verrouillage et notifications par la RFC 4533.
• Modèle d’identité : types d’identité et magasins d’identités.
• LDAP : le protocole, la recherche et les magasins d’identités de TOSIAM.
• Scalabilité & haute disponibilité : ferme de serveurs et réplication des annuaires.