"RegexRegisteredService" doit être remplacé par "CasRegisteredService".
Le msg de log indique que "RegexRegisteredService" est déprécié, mais en fait il ne fonctionne plus.
Réf : commit cassant RegexRegisteredService
Ce commit a modifié le comportement en cas où plusieurs tickets sont émis pour le même service (notamment avec des query parameters différents)
Pour revenir au comportement précédent :
cas.ticket.tgt.core.only-track-most-recent-session=false
NB : cela implique qu'un utilisateur se reconnectant sur la même application conservera tous les tickets dans le TGT ticket registry. Donc potentiellement des implications sur la taille...
Cf "Danger du cache attribute-repository" sur la page Paramétres importants de la configuration CAS.
Voir le retour de l'URN sur mise en place de CAS 6.0.4
tl;dr :
Détails :
RememberMeDelegatingExpirationPolicy peut choisir des ExpirationPolicy en fonction du TicketState
. C'est notamment utilisé par la méthode isExpired
.
quand le ticket registry cleaner est actif, il utilise isExpired
mais pas de "ticket registry cleaner" avec memcache (contrairement à redis) (ref : MemcachedTicketRegistryConfiguration)
à l'ajout du ticket dans memcache (pareil pour redis), c'est le default policy qui est utilisé (cf MemcachedTicketRegistry et BaseDelegatingExpirationPolicy ). La durée de mise en memcache est indépendante de la case rememberMe...
Donc avec redis,
cas.ticket.tgt.primary.max-time-to-live-in-seconds
(appelé cas.ticket.tgt.hardTimeout.timeToKillInSeconds
en CAS 5.3) qui sera utilisé dans rediscas.ticket.registry.cleaner.schedule.repeatInterval
qui est toutes les 2 min par défaut)Lorsqu'une application redirige vers CAS, le fragment d'url est ajouté par le navigateur. Par contre le form POST de la mire CAS peut perdre le fragment.
Depuis CAS 5.2, CAS tente de conserver le fragment, mais ce fragment est ajouté deux fois, ce qui perturbe certaines applications (Horde notamment)
Correctif : https://github.com/apereo/cas/pull/5371/commits/f41689c05b8ab62921f4a21635f40c8d99025312
Cf https://github.com/apereo/cas/pull/5371
NB : le fix a été accepté et est inclus en 6.4.5
CAS 6.4 intègre pac4j >= 5.1.4, or pac4j oidc ne fonctionne pas avec nimbus oidc < 9.14 :
java.lang.IllegalAccessError: class org.pac4j.oidc.profile.creator.OidcProfileCreator tried to access protected method com.nimbusds.oauth2.sdk.ProtectedResourceRequest.<init>(Ljava/net/URI;Lcom/nimbusds/oauth2/sdk/token/AccessToken;)V (org.pac4j.oidc.profile.creator.OidcProfileCreator and com.nimbusds.oauth2.sdk.ProtectedResourceRequest are in unnamed module of loader 'app')
Solution : modifiez build.gradle :
+ // pour délégation : + // ( https://github.com/apereo/cas/pull/5334 ) + implementation "com.nimbusds:oauth2-oidc-sdk:9.14" + implementation "org.apereo.cas:cas-server-support-pac4j-webflow" @@ -562,17 +559,17 @@ bootWar { cas { from "org.apereo.cas:cas-server-webapp${project.appServer}:${project.'cas.version'}@war" provided = false - excludes = ["WEB-INF/lib/servlet-api-2*.jar"] + excludes = ["WEB-INF/lib/servlet-api-2*.jar", "WEB-INF/lib/oauth2-oidc-sdk-9.13.jar"] |
Détails : https://github.com/apereo/cas/pull/5334
cas-server-support-trusted-mfa-redis seems to trigger spring-boot RedisRepositoriesAutoConfiguration, which fails to start with a "redisTemplate" error.
Solution : ajouter ceci dans cas.properties :
spring.data.redis.repositories.enabled: false