CAS

Arborescence des pages

Contexte

Eté 2024, l'Université de Rouen Normandie a procédé à une montée de version de son service d'authentification CAS en 7.0.6 

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.9

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 passé d'un Apereo CAS 6.6.15.2 à la version 7.0.6. Le CAS était opéré sur une debian bullseye qu'on a mis à jour vers bookworm au passage.

De l'openjdk 11, on est passé à un java zulu 21 (un jdk 21 est requis pour CAS 7.0) :

curl -s https://repos.azul.com/azul-repo.key | sudo gpg --dearmor -o /usr/share/keyrings/azul.gpg
echo "deb [signed-by=/usr/share/keyrings/azul.gpg] https://repos.azul.com/zulu/deb stable main" | sudo tee /etc/apt/sources.list.d/zulu.list
 apt update
apt upgrade
apt install zulu21-jdk-headless

Du tomcat9 proposé par bullseye on est passé au tomcat10 proposé par bookworm (et requis par CAS 7.0)

On continue d'utiliser un tomcat avec un apache en proxy, le lien apache-tomcat se fait via AJP

Nous utilisons les mêmes modules CAS qu'en 6.6.9 : ldap, json-service-registry, mongo-ticket-registry, trusted-mfa-mongo, throttle, reports interrupt-webflow, spnego, esup-otp-cas, agimus-cookie, agimus-logs

Version des protocoles TLS

Le passage à bookworm amène par défaut au niveau d'Apache et OpenSSL une évolution des versions de TLS supportées par défaut : TLS 1.0 et 1.1 sont maintenant désactivés, ce qui peut poser problème avec certains services cassifiés propulsés par des jdk anciens (jdk 1.7 par exemple...).

Les ajustements pour réactiver TLS 1.0 et 1.1 (en plus de 1.2 et 1.3) sont les suivants :

Ajout en fin de fichier de /etc/ssl/openssl.cnf de :

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.1
CipherString = DEFAULT@SECLEVEL=0


Puis côté apache dans /etc/apache2/mods-enabled/ssl.conf : 

SSLProtocol all +TLSv1 +TLSv1.1 +TLSv1.2

Problème de caractères spéciaux dans le password en proxypass http avec le tomcat embedded

Avant de passer sur tomcat10 avec AJP, une tentative d'utiliser directement le tomcat embedded de spring-boot avec un proxypass http nous a posé problème avec certains mots de passes - les mots de passe contenant par exemple les caractères µ ou encore § ne fonctionnaient plus.

L'usage de tomcat10 avec AJP et proxypass en ajp sur apache permet de ne pas avoir  ce problème...

Structure des tickets modifiée - purge de mongodb

Entre CAS 6.6 et CAS 7.0 les tickets n'ont plus la même structure (classes différentes), il faut donc purger les anciens tickets de la base de mongodb lors de la migration sans quoi le DefaultTicketRegistryCleaner ne pourra fonctionner et les tickets s'accumuleront en base, le message d'erreur étant alors : 

ERROR [org.apereo.cas.ticket.registry.DefaultTicketRegistryCleaner] - <java.lang.ClassNotFoundException: org.apereo.cas.authentication.metadata.BasicCredentialMetaData

Une simple suppression de la db des tickets CAS et redémarrage CAS permet d'effectuer cette purge.

Ne pas oublier ensuite de repositionner les index.

Ajustement des paramétrages LDAP

Les requêtes LDAP opérées par CAS sont calculées via la librairie person-directory de apereo via des mécanismes de générations dynamiques relativement complexes.

Ainsi le filtre suivant configuré dans cas.properties :

cas.authn.attributeRepository.ldap[0].searchFilter=(&(uid={user})(objectclass=eduPerson))

peut provoquer une requête ldap où user ne sera pas forcément remplacé par le username de l'utilisateur (uid) mais par un autre attribut faisant partie des attributs demandés.

Par rapport à notre configuration donnée dans notre retour sur le passage en CAS 6.4, nous avons ajusté 2 paramètres ainsi : 


cas.authn.ldap[0].principalAttributeId=uid
cas.authn.attributeRepository.ldap[0].searchFilter=(&(uid={username})(objectclass=eduPerson))

Tout en laissant 

cas.authn.ldap[0].principalAttributeList=

Cela permet de faire en sorte que le filtre soit correctement construit lors de la récupération des attributs.

On note alors un bug (non bloquant) lors d'un accès à un service en oidc : CAS tente de récupérer, en plus des attributs de l'utilisateur connecté, les attributs de l'utilisateur correspondant au clientId de service oidc 

On aura alors dans les logs simplement quelque chose comme :

WARN [org.apereo.cas.authentication.attribute.PrincipalAttributeRepositoryFetcher] - <No person records were fetched from attribute repositories for [{credentialClass=[OAuth20ClientIdClientSecretCredential], credentialId=[monTestOidcUrn], username=monTestOidcUrn}]>

Pour avoir plus de détails sur la construction des filtres ldap, on peut monter les logs en debug de org.apereo.services.persondir et org.apereo.service.persondir

SSO Sessions Actuator Endpoint

Par défaut on ne peut plus envoyer de paramètre username que sur les réquêtes HTTP en POST.

Notre script permettant la Suppression des sessions CAS d'un utilisateur utilisant le SSO Sessions Actuator Endpoint a du être adapté, il provoquait suite à la mise à jour l'erreur suivante : 

 ERROR [org.apereo.cas.web.support.filters.AbstractSecurityFilter] - <username parameter should only be used in POST requests

Pour que cela refonctionne, on fait maintenant un DELETE directement sur une url en https://cas.example.org/actuator/ssoSessions/users/toto (toto étant le username qu'on n'a plus à passer en paramètre du DELETE http).

Ajustement 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.0 n'échappe malheureusement pas à cette règle.

Nous avons donc ajusté les ressources système de notre VM ainsi :

  • passage de 4 coeurs à 8 coeurs
  • passage de 10GB de RAM à 12GB de RAM

Agimus

Les modules CAS pour ls support d'ESUP-Agimus ont été rendus compatibles avec CAS v7.0.6 : 



  • Aucune étiquette