...
Nous avons activé le RememberMe dans CAS.
Mais comme nous souhaitons Nous souhaitions le rendre disponible que uniquement sur 'mobiles'.
Aussi, pour ne laisser la case à cocher (permettant d'activer cette fonctionnalité) affichée que pour les 'mobiles', dans notre surcharge du footer.html on ajoute le bloc thymeleaf/javascript suivant :
...
Aussi sur un espace de 10 secondes (10=30/3), l'utilisateur est 'banni' temporairement à la 4ème tentative (12/3=4).
...
cas.example.com (cad cas) corrrespond au nom de machine et non à un alias. Utiliser l'alias et non le nom de machine est une erreur récurrente dans la mise en place de kerberos (erreur que nous avons faite, e de manière obstinée ...).
A l'URN on a donc non pas saisi cas.univ-rouen.fr mais cast.univ-rouen.fr dans ces lignes de commande (cast étant le nom de machine hébergeant notre CAS : cf "host cas.univ-rouen.fr").
...
| Bloc de code |
|---|
management.endpoints.web.exposure.include=* management.endpoints.enabled-by-default=true cas.monitor.endpoints.endpoint.defaults.access=IP_ADDRESS cas.monitor.endpoints.endpoint.defaults.requiredIpAddresses=10192.0168.01.22,127.0.0.1 |
On a implémenté la destruction des sessions CAS d'un utilisateur ainsi depuis notre application de gestion de comptes (codée en java/spring) :
| Bloc de code |
|---|
public class CasService {
protected Logger log = Logger.getLogger(CasService.class);
RestTemplate restTemplate;
String casSsoSessionsUrl;
String casDestroySsoSessionsUrl;
public void setRestTemplate(RestTemplate restTemplate) {
this.restTemplate = restTemplate;
}
public void setCasUrl(String casUrl) {
casSsoSessionsUrl = casUrl + "/actuator/ssoSessions?type=ALLDIRECT";
casDestroySsoSessionsUrl = casUrl + "/actuator/ssoSessions/{ticketGrantingTicket}";
}
public synchronized String destroySsoSessions(String login) {
String message = "";
CasSsoSessions casSsoSessions = restTemplate.getForObject(casSsoSessionsUrl, CasSsoSessions.class);
for(CasSsoSession casSsoSession : casSsoSessions.activeSsoSessions) {
if(login.equals(casSsoSession.principal)) {
log.info(String.format("Call Cas Destroy ticket %s for user %s", casSsoSession.principal, casSsoSession.ticketGrantingTicket));
Map<String, String> urlVariables = new HashMap<String, String>();
urlVariables.put("ticketGrantingTicket", casSsoSession.ticketGrantingTicket);
CasSsoSessionDestroyResponse casSsoSessionDestroyResponse = restTemplate.postForObject(casDestroySsoSessionsUrl, null, CasSsoSessionDestroyResponse.class, urlVariables);
log.info(String.format("CAS response : %s", casSsoSessionDestroyResponse.toString()));
message += casSsoSessionDestroyResponse.toString() + "\n";
}
}
return message;
}
} |
...
Cf ci-dessus (paragraphe sur le RememberMe ), on souhaite proposer à nos utilisateurs la possibilité de conserveur conserver leur session CAS sous mobile durant 2 semaines (14 jours, soit 1209600 secondes).
Sans rememberme de demandé, on propose une conservation de session CAS comme donné par défaut : c'est à dire 8 heures (28800 secondes).
...
En test nous n'avons pas eu à nous en plaindre, en . En production, celà a bien fonctionné dans un premier temps, mais rapidement ce choix s'est avéré problématique, cf ci-dessous.
...
- chaque TGT prenait 'beaucoup' de place, d'une certaine manière celà nous a conforté dans un premier temps aux choix de JPA et donc de la base de données pour la persistence des tickets.
- mais la base de données ne faisait qu'augmenter ... et donc la purge des tickets ne se faisait vraissemblablement pas correctement - cf ce graphe munin de 24 heures d'exploitation en production :
En regardant les logs CAS, on trouve l'erreur récurrente suivante (ceci est un extrait : on n'a conservé que les lignes 'intéressantes') :
...
- que celà fait suite sans doute à un bug antérieur, notre base n'est plus consistante ici peut-êtreconsistante
- le fait que DefaultTicketRegistryCleaner n'utilise qu'une seule et même transaction doit permettre qu'un update sur un ticket sur lequel on a appelé un delete avant ne pose justement pas de pb (pure spéculation ici, l'usage d'une seule transaction pour nettoyer n tickets laisse perplexe).
...
- la persistence d'un tgt en jpa correspond à une table dont 6 colonnes sont des blobs, et donc finalement des Large Object dans PostgreSql et donc des fichiers sur le système de fichiers
- 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 trigger 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 DefaultTicketRegistryCleanerDefaultTicketRegistryCleaner.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.
...
De même le stockage en ram comme en fichier (fichier de dump) requiert donc finalement peu d'espace. Là où nous avions besoin d'environ 3GB pour 30.000 TGT, c'est 300MB de RAM qu'il nous faut.
Les graphes suivants montrent sur 3 jours l'usage redis en nombre de tickets et RAM utilisée.
A noter que le lundi (15 juillet) on recense environ 15000 visites sur le CAS pour 10000 visiteurs différents et un total de 170000 tickets créés.
On a en fait usuellement 2 fois plus de fréquentation un jour hors période de vacances scolaires.
Rappel également pour donner un ordre de grandeur : notre université accueille environ 30.000 étudiants.
En imaginant que le service soit effectivement utilisé par quelques milliers de personnes depuis leurs mobiles (quasimenet 1 visite sur 2 sur notre CAS se fait actuellement depuis un mobile), on peut imaginer des pics de consommation de RAM de 3GB de RAM pour Redis.
Proposer 14 jours de persistence de Proposer 14 jours de persistence de TGT sur les mobiles pour les utilisateurs qui choissent l'option 'se souvenir de moi' est finalement à portée avec le ticket registry sous Redis.
...
- 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 parait être un choix très risqué de l'utilisé ... il est à déconseiller dans le sens où il ne correspond pas à la logique de développement actuel de CAS.
...
Ainsi l'authentification d'une de nos applications ne fonctionnait plus après le passage sur notre nouveau CAS car celle-ci intègre le CAS dans une iframe. En attendant de corriger celà côté de l'application, on a ajusté (temporairement donc) la chose pour que ça passe à nouveau : suppression de l'entête http X-Frame-Options en positionnant simplement la règle suivante sur notre Apache qui fait office de proxy avec notre Tocmat Tomcat CAS :
| Bloc de code |
|---|
Header unset X-Frame-Options |
...
Cf https://sogo.nu/bugs/view.php?id=2408&nbn=22 cette version est sensible aux réponses CAS et s'attend à avoir dans son sialoguqe dialoguqe ProxyCAS, une réponse HTTP proposant simplement le contenu XML avec un Content-Length correspondant.
...