Shibboleth et CAS

CAS est un système de Single Sign-On web d'établissement fortement déployé dans la communauté éducation-recherche française. La version 3 du serveur CAS implémente des fonctionnalités intéressantes : protocole SAML, Single Logout, transport d'attributs utilisateur (versus un identifiant uniquement).

Quelques liens introductifs aux notions techniques :

Un IdP (Identity Provider) Shibboleth doit rendre la fonction d'authentification de l'utilisateur. Pour cela, l'IdP Shibboleth 2.x propose plusieurs handlers d'authentification : UserPassword (LDAP, Kerberos), RemoteUser, etc. Il est possible de déléguer l'authentification utilisateur à un serveur CAS. Dans ce cas, l'IdP est configuré pour utiliser le handler RemoteUser ; un filtre CAS est configuré en amont.

Avantage de cette approche : une seule session SSO est utilisé dans les contextes Shibboleth et CAS. Si l'utilisateur est connecté sur son ENT, il accèdera à une ressources distante Shibbolisée sans devoir se réauthentifier.

Dans l'architecture décrite ci-dessus, le couplage entre le client CAS (filtre J2E) et l'IdP Shibboleth est très faible. Le filtre positionne la variable d'environnement REMOTE_USER, consommé par l'IdP Shibboleth. L'IdP Shibboleth ne connait pas la nature du mode d'authentification en amont.

Ce couplage faible ne permet pas d'exploiter certaines fonctionnalités existantes ou à venir de l'IdP Shibboleth : Single Logout, transport de la méthode d'authentification, authentification non-bloquante (isPassive) et réauthentification. Les développeurs de l'IdP Shibboleth annoncent l'implémentation de la fonction SLO (Single Logout) dans l'IdP Shibboleth pour sa version 2.3 ; le SLO ne fonctionnerait que pour les modes d'authentification natifs (UserPassword), pas pour le handler RemoteUser.

Dans le cas où des SP utilisent la fonctionnalité force authentication, les IdP utilisant le handler RemoteUser déclencheront une erreur côté SP. RENATER a développé une extension dans le cadre d'une contribution au projet Shibboleth IdP qui permet de propager l'authentification forcée au serveur CAS. Voir le lien dans le paragraphe suivant.

Pour améliorer le couplage entre CAS et un IdP Shibboleth, il est a priori nécessaire d'écrire un nouveau login handler pour l'IdP Shibboleth.

L'université de Washington a fait un travail de ce type pour leur SSO PubCookie ; on pourrait s'inspirer de leur expérience.

Pour fonctionner avec CAS ou Shibboleth, une application web doit être adaptée (exploitation des attributs utilisateur, déclenchement du login, logout, etc). Le travail d'adaptation à réaliser dans les deux cas (CAS et Shibboleth) n'est pas le même.

Spécificités du travail de CASification :

  • en général utilisation d'une librairie cliente CAS (disponible en Java, Perl, Php). Il est également envisageable d'utiliser le module d'authentification Apache mod_cas ou un filtre J2E CAS ;
  • le serveur CAS ne transmet que l'identifiant de l'utilisateur, pas d'autres attributs. Remarque : le serveur CAS v3 gère les attributs utilisateur.

Spécificités du travail de Shibbolisation :

  • la fonction est rendue par le module pour Apache mod_shib (fourni avec le SP Shibboleth) ;
  • le module transmet les attributs utilisateurs sous forme de variables d'environnement ;
  • le mécanisme des lazy sessions permet à l'application de déclencher l'authentification.

Beaucoup d'applications web ont déjà été CASifiées. Aujourd'hui certaines de ces applications doivent pouvoir fonctionner avec Shibboleth. Il est donc nécessaire de modifier/adapter l'application à nouveau.

Le projet CASShib vise à bénéficier d'une application CASifier, dans un contexte de fédération d'identités. Le principe de fonctionnement consiste à coupler un SP Shibboleth avec un serveur CAS.

Les points noirs de cette solution :

  1. sauf utilisation de l'implémentation v3 de CAS, le client CAS utilisé dans l'application ne permet probablement pas d'exploiter les attributs utilisateurs remontés par Shibboleth ;
  2. au-delà de l'économie (en terme de développement) que présente l'utilisation de CASShib, on n'économise pas la mise en œuvre d'un SP Shibboleth, à administrer. Il sera également nécessaire d'administrer la brique supplémentaire CASShib(= serveur CAS) ;
  3. des problèmes de sécurités sont évoqués, lire Service_registration_and_security.
  • federation/documentation/generale/shib-cas.txt
  • Dernière modification : 2021/05/17 13:28
  • de guillaume.rousse@renater.fr