...
On peut espérer que le DefaultTicketRegistryCleaner appelle le ticketRegistry Redis pour supprimer les TGTs stockés dans ces clefs CAS_PRINCIPAL:uid ... mais force est de constater que ça en ne semble pas être le cas sur notre installation.
Comme on avait pu le constater avec le JPA Ticket Registry (cf notre retour de 2019 à ce propos) le fonctionnement du Ticket Registry semble avoir été pensé pour déléguer les tâches d'expiration des données au système de stockage (registry) choisi.
Jusque-là le Redis Ticket Registry fonctionnait bien ainsi, mais l'apparition de ces entrées CAS_PRINCIPAL:uid (sorte de rustine ayant pour but de retrouver rapidement les tickets d'un utilisateur donné) vient casser ce système et il semble aventureux de fonctionner ainsi.
Notre CAS avec esup-otp utilisant dès à présent pour certaines données une base MongoDB, on a naturellement basculé sur le Ticket Registry sous mongodb.
Passage au Ticket Registry MongoDB
Dans le build.gradle de l'overlay on remplace
| Bloc de code | ||
|---|---|---|
| ||
org.apereo.cas:cas-server-support-redis-ticket-registry |
par
| Bloc de code | ||
|---|---|---|
| ||
org.apereo.cas:cas-server-support-mongo-ticket-registry |
Puis dans /etc/cas/config/cas.properties on commente les paramètres du ticket-registry redis pour ajouter ceux de mongodb
| Bloc de code | ||
|---|---|---|
| ||
cas.ticket.registry.mongo.client-uri=mongodb://localhost/cas-ticketregistry
cas.ticket.registry.mongo.crypto.enabled=true
cas.ticket.registry.mongo.crypto.signing.key=clef-generee-au-premier-demarrage
cas.ticket.registry.mongo.crypto.encryption.key=clef-generee-au-premier-demarrage |
Un redémarrage CAS suffit à passer sur le nouveau ticket registry, évidemment toutes les sessions sont perdues lors de cette bascule.
Notes supplémentaires
CAS positionne bien un expireAt (TTL) propre à MongoDB dans les enregistrements, notamment les TGT (collection ticketGrantingTicketsCollection).
Notre installation/configuration faisait que ces TGT étaient, même sans le remember-le d'actifs, de 14 jours.
On avait en effet positionné le cas.ticket.tgt.primary.max-time-to-live-in-seconds à 14 jours, pour correspondre à cas.ticket.tgt.remember-me.time-to-kill-in-seconds
Si c'était peut-être une configuration adéquate, ça ne l'est plus (au moins en 6.6.9 et avec le ticket registry mongo)
On a modifié cas.ticket.tgt.primary.max-time-to-live-in-seconds pour correspondre à 8H20
On a ainsi les configurations suivantes à ce sujet:
| Bloc de code |
|---|
cas.ticket.tgt.primary.max-time-to-live-in-seconds=30000
cas.ticket.tgt.primary.time-to-kill-in-seconds=28800
cas.ticket.tgt.remember-me.enabled=true
cas.ticket.tgt.remember-me.time-to-kill-in-seconds=1209600 |
Les expireAt (TTL) des TGT sont maintenant positionnés à 8H20 quand le RememberMe n'est pas actionné, et 8H20 sinon.
On graphe dès à présent quelques métriques mongo via munin et https://github.com/comerford/mongo-munin (dont on a converti les scripts en python3 via 2to3).
D'ici quelques jours, on espère pouvoir ajouter à cette page wiki des graphes montrant que tout va bien sur notre CAS avec le ticket registry sous mongo.