...
| Info |
|---|
|
Université de Lorraine
Architecture Infra :
- 2 Frontaux :
- serveurs HAproxy (Actif/Actif) pour le loadbalancing
- Pacemaker pour gérer la haute disponibilité
- Roud-robin et stickysession
- 3 Backends CAS :
- Tomcat10
- Mongodb en replicaset pour la gestion des ticketRegistry
Architecture CAS :
Nous disposons d'un projet Git (+submodule) sur notre Gitlab établissement, comprenant :
- Un dépôt pour le build du cas-overlay-template
- Un dépôt pour la configuration globale de notre CAS (cas.properties, log4j2.xml, interrupt.groovy, etc.)
- Un dépôt pour la gestion des Service Registry : fichier JSON en local sur chaque backend (Synchronisation des backends par hook post-commit)
Fonctionnalités :
- authn : ldap
- divers : throttle, interrupt (validation formation cybersecurite interne)
- protocoles utilisés pour les services : CAS, SAML, OIDC
- MFA esup-otp (En POC actuellement)
Télécom SudParis
- 2 HAProxy
- 2 serveurs CAS
- tickets registry : redis
...
- 2 serveurs CAS en blue–green deployment :
- En temps normal, une seule instance fonctionne à la fois
- Quand on doit redémarrer CAS pour appliquer une mise à jour, on démarre une seconde instance, sur laquelle on bascule une fois démarrée. Puis on stoppe la première instance.
- Démarrés dans une image docker tomcat:10-jre21
- ticket registry : mongodb
- service registry : fichiers json avec git local
- authn : ldap ou spnego ou délégation FranceConnect
- divers : remember-me, throttle, interrupt (réconciliation FranceConnect avec ldap)
- protocoles utilisés pour les services : CAS (dont proxyCAS)
...
- frontal HAProxy mutualisé avec Haute dispo
- 3 serveurs CAS en load-balancing (pas de sticky session)
- ticket registry : redis+sentinel (dockerisé et lancé sur les 3 serveurs)
- service registry : fichiers json avec git local
- configuration CAS : fichiers avec git (distinct du git service registry)
- Ferme OpenLdap 2 master + 3 slave en interrogation
...
- 2 serveurs CAS en actif/actif
- VIP keepalive devant assurant la répartition de charge et la bascule en cas de perte d'un noeud
- ticket registry : Hazelcast en cluster sur les deux noeuds
- service registry : fichiers json déployés avec puppet sur tous les noeuds
- authn : ldap
- divers : remember-me, throttle
- protocoles utilisés pour les services : CAS, OAuth, OIDC
- MFA Esup-OTP via le module CAS
- TOTP
- Push
- Fédération d'identité: Shibboleth délègue l'authentification à CAS
- En cours de mise en place: PCA sur un second site en cas de perte du DC principal
- bascule automatique sur le second site via mécanismes BGP
- mode dégradé sans le MFA dans un premier temps
- CAS + Idp pour la fédération d'identité
- Le but étant de pouvoir continuer à utiliser les services externes à l'institut (Saas, Proconnect, tchap...) en cas de perte du DC
Université de Rouen Normandie
Les détails de nos configurations et de notre infrastructure simple d'1 seule VM sont donnés de manière quasi exhaustive dans les retours que l'on a pu faire dans cet espace wiki esup.
Par rapport aux recommandations officielles du projet nous sommes donc dans le scénario 1, à savoir 1 noeud unique avec infrastructure VM avancée (vmware) qui nous garantit la robustesse du déploiement.
Jusque-là nous n'avons pas regretté ce choix, la simplicité est effectivement gage de stabilité ; comme indiqué dans la page apereo cependant, la limite de cette architecture reste qu'un redémarrage (et donc une interruption de service) court est nécessaire lors des mises à jour.
- 1 serveur CAS
- 1 ticket registry : mongodb
- service registry : fichiers json à plat maintenus via simple git
- authn : ldap, spnego (kerberos)
- divers : remember-me, throttle, déclenchement interrupt et mfa via scripts groovy
- protocoles utilisés pour les services : CAS, OIDC
- MFA Esup-OTP via esup-otp-cas
- Fédération d'identité: Shibboleth délègue l'authentification à CAS