...
Entre nos chainages de proxycas, de clearpass, ... on comprend du log ci-dessus que pour un ticket, le nettoyage ne passe pas : on tente de mettre à jour un ticket qui est en fait supprimé. Si l'opération de suppression était dans la même transaction , ça devrait passer malgré tout ... et c'est d'ailleurs sans doute pour ça qu'on n'a qu'une seule transaction est utilisée sans doute (pour : celà permet qu'un update sur un ticket sur lequel on a appelé un delete avant ne pose pas de pb).
Vu Bref, vu qu'il y a une erreur sur un nettoyage de ticket, c'est toute la transaction qui est avortée. Et donc aucun ticket ne peut être nettoyé. D'où le nombre de tickets qui ne fait qu'augmenter en base.
En tentant de débloquer la situation, on a remarqué les choses suivantes :
- la persistence d'un tgt en jpa correspond à une table dont 6 colonnes sont des blobs, et donc finalement Large Object dans PostgreSql
- malgré celà, la suppression d'un ticket n'entraine pas la suppression des Large Object : pour y remédier, il faudrait alors mettre en place un trugger ou lancer rgulièrement un vacuumlo
A y regarder de plus près, ces stockages sous forme de blob correspondent une logique de programmation où on stocke de la donnée non structurée, 'no-sql'.
L'implémentation du DefaultTicketRegistryCleaner.java nous conforte dans celà : pour récupérer les tickets qui doivent être supprimés, on récupère tous les tickets puis on regarde ceux qui doivent être expirés.
Dans une logique sql, on récupèrerait directement par un select les tickets que l'on doit supprimer.
Enfin la taille de la base de données, et la taille prise donc par la persistence d'un ticket dans postgresql est justifiée par cet usage des Large Object.
Celà nous amène à conclure que l'usage d'un ticket registry CAS en JPA/Postgresql est clairement à éviter.
C'est ce qui est +/- indiqué dans la documentation ici : https://apereo.github.io/cas/6.0.x/ticketing/JPA-Ticket-Registry.html :
| Bloc de code |
|---|
Usage Warning!
Using a relational database as the back-end persistence choice for ticket registry state management is a fairly unnecessary and complicated process. Unless you are already outfitted with clustered database technology and the resources to manage it, the complexity is likely not worth the trouble. |
Redis
Redis est une solution permettant de persister des données simples clef/valeurs. En ce sens elle correspond à cette logique no-sql qu'on a pu observer ci-dessus.
C'est a priori le ticket registry recommandé, et c'est celui que le script de l'AMU donnait par défaut.
Le passage sur Redis est immédiat. Et rapidement on voit que le stockage (complètement en RAM ... et en fichier de dump pour préserver les tickets lors des redémarrages) est en fait peu gourmand.
Simple d'usage, on peut interroger avec redis-cli le serveur redis et observer ce qu'il se passe : les tickets (clef/valeur) sont poussés par CAS avec une date d'expiration gérée en interne par redis lui-même.
Cette durée / date d'expiration correspond au pramètre cas.ticket.tgt.maxTimeToLiveInSeconds - paramètre que nous n'avions en fait pas compris lors de la mise en place de CAS avec JPA / Postgresql puisque une base SQL comme postgresql ne propose pas ce mécanisme d'expiration de la donnée.
Ainsi nous mettons finalement comme péramétrage :
| Bloc de code |
|---|
cas.ticket.tgt.maxTimeToLiveInSeconds=1209600
cas.ticket.tgt.timeToKillInSeconds=28800
cas.ticket.tgt.rememberMe.timeToKillInSeconds=1209600 |
Avec ce paramétrage :
- tous les TGT expirent via les mécanismes redis internes au bout de 1209600 secondes (2 semaines)
- le DefaultTicketRegistryCleaner quant à lui va passer sur tous les tickets pour focer la suppression des tgt en fonction des paramètres timeToKillInSeconds au bout de 2 semaines ou 8 heures.
La souplesse et tolérance des commandes passées par redis font que ça ne bug pas, il n'y a pas de transaction, la récupération de l'ensemble des données pour un tri a postériori convient également à cet usage redis.
De même le stockage en ram comme en fichier (fichier de dump) requiert donc finalement peu d'espace.
Conclusion
Le ticket registry via Redis donne toute satisfaction.
Le ticket registry via jpa/postgresql a peut-être été un choix possible dans les anciennes versions de CAS ; aujourd'hui celà est très risqué de l'utilisé ...
Misc
Via des versions à jour de spring-boot et spring-security, CAS en 6.0.x amène l'usage des dernières technologies web, notamment en matière de sécurité (csp, xss, csrf, xsrf ...) et de protocole (chunked transfer encoding).
...