Infrastructures et configuration des établissements

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

Ecole Centrale de Lille

• 2 HAProxy derrière une VIP
• 2 serveurs CAS en round robin avec sticky session
• tickets registry : mongodb répliqué sur les 3 serveurs esup-otp en replicaset
  
• Authentification avec esup-otp

Université Paris 1 Panthéon-Sorbonne

• 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)

RECIA

Architecture infra:

• 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
• configuration CAS :  fichiers avec git (distinct du git service registry)
• Ferme OpenLdap 2 master + 3 slave en interrogation

Fonctionnalités:

• CAS IDP:
  • protocoles utilisés pour les services: CAS, SAML, OIDC 
  • SAML: FER, GAR
  • OIDC: ProConnect
• CAS SP (délégation d'auth): 
  • CAS: pour les tests
  • SAML: EduConnect, guichets agents EN, guichets collectivités
  • OIDC: à venir
• SCIM pour idRuide
• MFA: protocole mfa-gauth + VaultWarden pour gestion OTP (à venir gestion multi-device via UI CAS-management pour laisser au choix de l'utilisateur le "device")
• Interrupt: scripts groovy pour rediriger l'utilisateur selon le cas: Validation CGU, gestion sur le bon domaine de service (gestion multi-domaine des services), etc.
• Gestion de logout partiel pour le cas du changement du contexte d'établissement pour un utilisateur sur plusieurs établissements.

Sources customisées: https://github.com/GIP-RECIA/cas-war-overlay

Documentations: https://github.com/GIP-RECIA/cas-war-overlay/tree/master/docs

Université de Technologie de Compiègne

3 serveurs debian. Sur chacun :

• nginx + tomcat
• apereo cas
• esup-otp-manager
• mongod (toutes les données sauf les conf services en fichier json)

Disponibilité : 

• Les serveurs CAS et esup-otp-manager sont en actif/passif avec une IP virtuelle maintenue par keepalived.
• Les serveurs mongodb sont en replicaset.

Méthodes MFA : 

• webauthn (usages les plus courants : windows hello par code pin ou biométrie, touchid...)
• TOTP

Build de l'overlay avec un script bash pour automatiser des changements de textes dans les fichiers de localisation et faire un tout petit peu d'édition de templates

INRIA

• 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