CAS

Arborescence des pages

Vous regardez une version antérieure (v. /wiki/spaces/CAS/pages/1564704779/Retour+de+l+URN+sur+mise+en+place+de+CAS+7.2.2) de cette page.

afficher les différences afficher l'historique de la page

« Afficher la version précédente Vous regardez la version actuelle de cette page. (v. 2) afficher la version suivante »

Contexte

Printemps 2025, l'Université de Rouen Normandie a procédé à une montée de version de son service d'authentification CAS en 7.2.2 

Cette page wiki vient en complément de nos pages Retour de l'URN sur mise en place de CAS 6.0.4, Retour de l'URN sur mise en place de CAS 6.4.1 et Retour de l'URN sur mise en place de CAS 6.6.9Retour de l'URN sur mise en place de CAS 7.0.6

Si la migration s'est plutôt bien déroulée, nous avons du faire quelques ajustements... cette page tente de les retranscrire.

Environnement technique

On est resté sur l'environnement technique bookworm, tomcat10, zulu21 tel que décrit dans  Retour de l'URN sur mise en place de CAS 7.0.6

esup-otp-cas

Une version d'esup-otp-cas est disponible et compatible avec CAS 7.2.

Il faut aussi penser à ajuster cas.properties pour permettre à esup-otp-api de fonctionner dans la page CAS, on a ainsi : 

cas.http-web-request.header.content-security-policy=script-src 'self' 'unsafe-inline' 'unsafe-eval' https://esup-otp-api.univ-rouen.fr https://webstats.univ-rouen.fr; object-src 'none'; worker-src 'self' blob: 'unsafe-inline'

SSO Sessions Actuator Endpoint

Les configurations pour accéder aux actuator changent : 

management.endpoints.web.exposure.include=ssoSessions
management.endpoint.ssoSessions.access=UNRESTRICTED
cas.monitor.endpoints.endpoint.ssoSessions.access[0]=IP_ADDRESS
cas.monitor.endpoints.endpoint.ssoSessions.required-ip-addresses[0]=192\\.168\\.0\\.1

Longueurs des clefs de chiffrement

Les clefs de chiffrement demandent à être ajustés : cf les logs de CAS, leurs tailles sont à augmenter.

Consommation CPU et RAM

Depuis maintenant un certain nombre d'années, on constate que chaque montée de version majeure de Apereo CAS amène une consommation plus importante des ressources système.

La 7.2 n'échappe malheureusement pas à cette règle.

Problème rencontré avec la persistance du cookie TGC (remember-me)

Nous avons constaté un changement de comportement concernant le cookie TGC (Ticket Granting Cookie), responsable du maintien de la session CAS entre le navigateur et le serveur.

En version 7.0, l’interface HTML proposait une case à cocher (<input type="checkbox">) pour l’option "Se souvenir de moi" (remember-me). Cela avait pour effet que, si l’utilisateur ne cochait pas cette case, aucun paramètre rememberme n’était transmis à CAS, et donc la session CAS était associée à un cookie de session navigateur (supprimé à la fermeture du navigateur).

À partir de la version 7.1, l’UI CAS a été modifiée : la case à cocher a été remplacée par un bouton de type "switch" (toggle), qui agit en réalité sur un champ caché (<input type="hidden" name="rememberme">). Résultat : le paramètre rememberme est toujours transmis côté serveur, même lorsqu’il est désactivé.

Or, dans le code de CAS (de la 7.1 à 7.2.2 comprise), la décision de rendre le TGC persistant repose uniquement sur la présence du paramètre rememberme, sans considération de sa valeur. Cela a pour effet de rendre le TGC persistant (cookie à durée de vie fixée), même lorsque l’utilisateur n’a pas demandé à rester connecté. Ce comportement peut poser problème dans des environnements où le navigateur est partagé (ex. : tablettes pour examens), car la session persiste même après fermeture/reprise du navigateur.

Nous avons corrigé ce comportement localement en surchargeant la méthode concernée pour que la persistance du TGC soit conditionnée à la valeur du paramètre rememberme, et non à sa seule présence.

Pull Request

Un pull request a été proposée à Apereo pour corriger cela de manière générique ici : https://github.com/apereo/cas/pull/6872

Modification dans le cas-overlay

Le déploiement par cas-overlay permet de surcharger des classes java.

Exceptionnellement et dans l'attente (et l'espoir) que le problème soit prise en compte et corrigé dans la version officielle d'Apereo CAS, nous avons donc patché localement la classe java.

  1. copie de classe java modifiée dans l'overlay dans src/main/java/org/apereo/cas/web/support/gen/CookieRetrievingCookieGenerator.java
  2. ajout des dépendances dans l'overlay pour la compilation :
    /* pour override de CookieRetrievingCookieGenerator */
    implementation "org.apereo.cas:cas-server-core-cookie-api"
    implementation "org.apereo.cas:cas-server-core-authentication-api"
    implementation "org.apereo.cas:cas-server-core-util-api"
    implementation "org.apereo.cas:cas-server-core-web-api"
  3. puis redéploiement et redémarrage pour prise en compte.




  • Aucune étiquette