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 (Traitement 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.
• 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 local
• 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