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

• Le projet CAS

Quelques liens introductifs aux notions techniques :

• Les handlers de l'IdP Shibboleth, Internet2
• Le handler UserPassword utilise l'API JAAS, Internet2
• IdP Authentication and Sessions, Internet2
• documentation d'installation d'un IdP Shibboleth, RENATER (voir chapitre 8)
• Single Logout Issues, Internet2

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.

• Un Handler CAS pour l'authentification forcée, RENATER
• Login Handler Extensions, Internet2
• Creating Custom IdP Extensions, Internet2
• Javadoc des login handlers de l'IdP Shibboleth

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.

• Rendre compatible une application avec Shibboleth, RENATER

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.

• CASShib

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.