CAS

Arborescence des pages

Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.

...

  • 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 Synchronisation des backends par hook post-commit)

Fonctionnalités :

...

  • 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