Single Sign-On open-source avec CAS (Central Authentication Service)
Vincent Mathieu -Université de Nancy 2 - vincent.mathieu@univ-nancy2.fr
Pascal Aubry - IFSIC - Université de Rennes 1 - pascal.aubry@univ-rennes1.fr
Julien Marchal - Université de Nancy 2 - julien.marchal@univ-nancy2.fr
Cet article peut également être lu au format PDF.
Résumé
L’universalité du protocole HTTP a depuis longtemps séduit les développeurs ; les applications portées sur le web sont de plus en plus nombreuses.
La mise en place d’annuaires (LDAP par exemple) a épargné la tête des utilisateurs en ne leur faisant mémoriser qu’un seul mot de passe, mais leurs doigts sont encore durement sollicités car ils doivent s’authentifier chaque fois qu’il accèdent une application.
Plusieurs solutions de Single Sign-On (authentification unique et unifiée) sont d’ores et déjà disponibles dans le commerce. Cet article décrit une solution libre, simple, riche et sûre : CAS (Central Authentication Service), développée par l’Université de Yale, et adoptée par le projet ESUP-Portail.
Mots clefs
Single Sign-On, open-source, web, sécurité, authentification.
Table des matières
1 Pourquoi
le Single Sign-On ?
3.3 Fonctionnement
multi-tiers
4.1 Authentification sur un
annuaire LDAP
4.2 Autres modes
d’authentification
5 CAS-ification
d'une application web
5.1 Les applications client
CAS « simples »
5.2 Les applications
mandataires (proxies) CAS
5.4 Quelques précautions à
prendre lors de la CAS-ification d'applications
5.5 Authentification CAS
pour des pages web statiques
6 CAS-ification
d'une application non web
6.2 Exemple :
utilisation de pam_cas pour un serveur IMAP
6.3 CAS-ification du
serveur Cyrus-IMAP
6.4 Application : webmail
en SSO avec IMP
7 Limitations
actuelles et perspectives
7.1 CAS est un SSO, limité
à une authentification locale
7.2 Montée en charge et
tolérance aux pannes
1 Pourquoi le Single Sign-On ?
Les services numériques accessibles par le web (intranet, courrier électronique, forums, agendas, applications spécifiques) à disposition des étudiants, enseignants, personnels administratifs se sont multipliés en quelques années. Ces services nécessitent très souvent une authentification.
L'utilisation de techniques de synchronisation entre domaines d'authentification hétérogènes, puis de serveurs LDAP a permis la mise en oeuvre d'un compte unique (login / mot de passe) pour chaque utilisateur, ce qui est un progrès. Se posent maintenant les problèmes suivants :
- authentifications multiples : il est nécessaire d'entrer son login/mot de passe lors de l'accès à chaque application.
- sécurité : le compte étant unique, le vol de celui-ci entraîne un risque très important. La sécurisation de l'authentification devient donc primordiale. Il est également fortement souhaitable que les applications n'aient pas connaissance du mot de passe.
- différents mécanismes d'authentification : certains utilisateurs disposent de certificats X509 [1][2], qui pourraient servir à l'authentification. En outre, il n'est pas exclu que l'utilisation de LDAP à cette fin ne soit pas remplacée à terme par autre chose, et que certaines politiques d'établissement exigent l'utilisation de bases de données additionnelles. Il semble donc intéressant de disposer d'un service d'abstraction par rapport au(x) mécanisme(s) d'authentification local(aux).
- aspects multi-établissements : le compte d'un utilisateur est unique à l'intérieur de l'établissement ; il serait souhaitable que l'accès à des ressources informatiques d'un autre établissement puisse se faire à l'aide du même compte.
- autorisations : il est nécessaire pour certaines applications de pouvoir disposer d’informations définissant les rôles des utilisateurs.
Les mécanismes de SSO (Single Sign-On : authentification unique, et une seule fois) [3] tentent de répondre à ces problématiques, en utilisant tous des techniques assez semblables, à savoir :
- une centralisation de l'authentification sur un serveur qui est le seul à recueillir les mots de passe des utilisateurs, à travers un canal chiffré ;
- des redirections HTTP transparentes du navigateur client, depuis les applications vers le serveur d’authentification, puis du serveur vers les applications.
- le passage d’informations entre le serveur d’authentification et les applications à l’aide de cookies [4], et/ou de paramètres CGI de requêtes HTTP (GET ou POST).
Parmi les différentes solutions commerciales offertes aux administrateurs et développeurs émergent Sun ONE Identity Server [5] et MicroSoft Passport [6]. Cet article se propose de montrer qu'une solution libre permet d'implémenter un mécanisme de SSO puissant, sûr et souple pour les applications web.
2 Le choix de CAS
Développé par l'Université de Yale, CAS (Central Authentication Service [7]) met en oeuvre un serveur d'authentification accessible par W3, composé de servlets java, qui fonctionne sur tout moteur de servlets (Tomcat par exemple), et dont les points forts sont listés ci-dessous.
- La sécurité est assurée par les dispositifs suivants :
o le mot de passe de l'utilisateur ne circule qu'entre le navigateur client et le serveur d’authentification, nécessairement à travers un canal crypté.
o Les ré-authentifications suivantes sont faites de manière transparente à l'utilisateur, sous réserve de l'acceptation d’un cookie privé et protégé. Seul le serveur d'authentification peut lire et écrire ce cookie, qui ne contient qu'un identifiant de session.
o L'application reçoit du serveur d'authentification un « ticket opaque » qui n'est pas porteur d'information personnelle. Ce ticket circule en clair via le navigateur (en paramètre CGI) ; il n'est pas rejouable, a une durée de vie courte, est n'est utilisable que par l'application qui l'a demandé. L'application va ensuite contacter directement (en http) le serveur CAS afin de faire valider (et expirer) ce ticket ; le serveur CAS va retourner à l'application l'identifiant de la personne, validé. L'application n'a ainsi jamais accès au mot de passe (schéma pourtant classique de pratiquement tous les mécanismes de SSO).
- Les mécanismes classiques imposent une communication entre le navigateur web et l’application, ce qui exclut les configurations n-tiers, où une application doit directement interroger un service nécessitant authentification (c'est le cas par exemple pour un portail accédant à un web service). CAS, dans sa version 2.0, résout ce problème en proposant un mécanisme de mandataires (proxies). Des tickets dédiés permettent à des applications tierces, n’ayant aucune communication avec le navigateur client, d’être assurées de l’authentification de l’utilisateur. Cette fonctionnalité est assurément le point fort de CAS.
- Le package proposé implémente tout le protocole de mise en oeuvre du SSO, à l'exception du module d'authentification locale qui est à la charge de l'administrateur du serveur d’authentification. Cela laisse la liberté d’implémenter exactement l’authentification souhaitée (LDAP, Kerberos [8], certificats X509, NIS, un panachage, ...).
- Des librairies clientes en Java, Perl, JSP, ASP, PL/SQL et PHP sont livrées. Cela permet une grande souplesse sur les serveurs d'applications. L’intégration dans des outils utilisés dans le monde universitaire est d’ores et déjà faite, comme celle d’uPortal [9].
- L'utilisation de cookies exclusivement privés dans CAS (passage de tickets entre serveur d’authentification et applications uniquement sous forme de paramètres de GET HTTP) permet à CAS d'être opérationnel sur des serveurs situés dans des domaines DNS différents.
- Un module Apache (mod_cas) permet d'utiliser CAS pour protéger l'accès à des documents web statiques, les librairies clientes ne pouvant être utilisées dans ce cas.
- Un module PAM [10] (pam_cas) permet de « CAS-ifier » des services non web, tels que FTP, IMAP, ...
- Enfin, CAS est en production dans plusieurs Universités américaines, avec des authentifications internes Kerberos ou LDAP, ce qui permet d’être confiant sur sa fiabilité[1].
Nous vous proposons de détailler dans cet article le fonctionnement d'une implémentation de SSO avec CAS, en nous attachant à présenter les avantages et inconvénients de cette solution.
3 Le mécanisme CAS
3.1 Architecture
3.1.1 Le serveur CAS
L'authentification est centralisée sur une machine unique, le serveur CAS. Ce serveur est le seul acteur du mécanisme CAS à avoir connaissance des mots de passe des utilisateurs. Son rôle est double :
- authentifier les utilisateurs ;
- transmettre et certifier l'identité de la personne authentifiée (aux clients CAS).
3.1.2 Les navigateurs (web)
Les navigateurs doivent satisfaire les contraintes suivantes pour bénéficier de tout le confort de CAS[2] :
- disposer d'un moteur de chiffrement leur permettant d'utiliser le protocole HTTPS ;
- savoir effectuer des redirections HTTP (accéder à une page donnée dans une entête Location lors d'une réponse 30x à une première requête HTTP) et interpréter le langage JavaScript ;
- savoir stocker des cookies, comme défini par [4]. En particulier, les cookies privés ne devront être retransmis qu'au serveur les ayant émis pour garantir la sécurité du mécanisme CAS.
Ces exigences sont satisfaites par tous les navigateurs classiquement utilisés, à savoir MicroSoft Internet Explorer (depuis 5.0), Netscape Navigator (depuis 4.7) et Mozilla.
3.1.3 Les clients CAS
Une application web muni d'une librairie cliente ou un serveur web utilisant le module mod_cas est alors appelé « client CAS ». Il ne délivre les ressources qu'après s’être assuré que le navigateur qui l'accède se soit authentifié auprès du serveur CAS.
Parmi les clients CAS, on trouve :
- des librairies correspondant aux langages communément employés en programmation web dynamique (Perl, Java, JSP, PHP, ASP) ;
- un module Apache, qui permet de protéger des documents statiques ;
- un module PAM, qui permet d'authentifier les utilisateurs au niveau système.
3.2 Fonctionnement de base
3.2.1 Authentification d'un utilisateur
Un utilisateur non déjà précédemment authentifié, ou dont l'authentification a expiré, et qui accède au serveur CAS se voit proposer un formulaire d'authentification, dans lequel il est invité à entrer son nom de connexion et son mot de passe :
Figure 1 : Premier accès d'un navigateur au serveur CAS (sans TGC)
Si les informations sont correctes, le serveur renvoie au navigateur un cookie appelé TGC (Ticket Granting Cookie) :
Figure 2 : Authentification d'un navigateur auprès du serveur CAS
Le Ticket Granting Cookie (TGC) est le passeport de l’utilisateur auprès du serveur CAS. Le TGC, à durée de vie limitée (typiquement quelques heures), est le moyen pour les navigateurs d'obtenir auprès du serveur CAS des tickets pour les clients CAS sans avoir à se ré-authentifier. C'est un cookie privé (n'est jamais transmis à d'autres serveurs que le serveur CAS) et protégé (toutes les requêtes des navigateurs vers le serveur CAS se font sous HTTPS). Comme tous les tickets utilisés dans le mécanisme CAS, il est opaque (ne contient aucune information sur l'utilisateur authentifié) : c'est un identifiant de session entre le navigateur et le serveur CAS.
3.2.2 Accès à une ressource protégée après authentification
Lors de l'accès à une ressource protégée par un client CAS, celui-ci redirige le navigateur vers le serveur CAS dans le but d'authentifier l'utilisateur (cf Figure 3). Le navigateur, précédemment authentifié auprès du serveur CAS, lui présente le TGC (rappel : un cookie).
Figure 3 : Redirection vers le serveurCAS d'un navigateur non authentifié auprès du client CAS
Sur présentation du TGC, le serveur CAS délivre au navigateur un Service Ticket (ticket de service ou ST) ; c'est un ticket opaque, qui ne transporte aucune information personnelle ; il n'est utilisable que par le « service » (l'URL) qui en a fait la demande. Dans le même temps, il le redirige vers le service demandeur en passant le Service Ticket en paramètre CGI (cf Figure 4).
