Vous êtes sur la page 1sur 14

Single Sign-On open-source avec CAS (Central Authentication Service)

Vincent Mathieu
Universit de Nancy 2
vi ncent . mat hi eu@uni v- nancy2. f r
Pascal Aubry
IFSIC - Universit de Rennes 1
pascal . aubr y@uni v- r ennes1. f r
J ulien Marchal
Universit de Nancy 2
j ul i en. mar chal @uni v- nancy2. f r

Date : 12 Octobre 2003
Rsum
Luniversalit du protocole HTTP a depuis longtemps sduit les dveloppeurs ; les applications portes sur le web sont de
plus en plus nombreuses.
La mise en place dannuaires (LDAP par exemple) a pargn la tte des utilisateurs en ne leur faisant mmoriser quun
seul mot de passe, mais leurs doigts sont encore durement sollicits car ils doivent sauthentifier chaque fois quil accdent
une application.
Plusieurs solutions de Single Sign-On (authentification unique et unifie) sont dores et dj disponibles dans le commerce.
Cet article dcrit une solution libre, simple, riche et sre : CAS (Central Authentication Service), dveloppe par
lUniversit de Yale, et adopte par le projet ESUP-Portail.
Mots clefs
Single Sign-On, open-source, web, scurit, authentification.
1 Pourquoi le Single Sign-On ?
Les services numriques accessibles par le web (intranet, courrier lectronique, forums, agendas, applications spcifiques)
disposition des tudiants, enseignants, personnels administratifs se sont multiplis en quelques annes. Ces services
ncessitent trs souvent une authentification.

L'utilisation de techniques de synchronisation entre domaines d'authentification htrognes, 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 progrs. Se posent
maintenant les problmes suivants :

- authentifications multiples : il est ncessaire d'entrer son login/mot de passe lors de l'accs chaque application.
- scurit : le compte tant unique, le vol de celui-ci entrane un risque trs important. La scurisation de l'authentification
devient donc primordiale. Il est galement fortement souhaitable que les applications n'aient pas connaissance du mot de
passe.
- diffrents mcanismes 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 remplace terme
par autre chose, et que certaines politiques d'tablissement exigent l'utilisation de bases de donnes additionnelles. Il
semble donc intressant de disposer d'un service d'abstraction par rapport au(x) mcanisme(s) d'authentification
local(aux).
- aspects multi-tablissements : le compte d'un utilisateur est unique l'intrieur de l'tablissement ; il serait souhaitable
que l'accs des ressources informatiques d'un autre tablissement puisse se faire l'aide du mme compte.
- autorisations : il est ncessaire pour certaines applications de pouvoir disposer dinformations dfinissant les rles des
utilisateurs.

Les mcanismes de SSO (Single Sign-On : authentification unique, et une seule fois) [3] tentent de rpondre ces
problmatiques, 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 dauthentification, puis
du serveur vers les applications.
- le passage dinformations entre le serveur dauthentification et les applications laide de cookies [4], et/ou de
paramtres CGI de requtes HTTP (GET ou POST).

Parmi les diffrentes solutions commerciales offertes aux administrateurs et dveloppeurs mergent Sun ONE Identity
Server [5] et MicroSoft Passport [6]. Cet article se propose de montrer qu'une solution libre permet d'implmenter un
mcanisme de SSO puissant, sr et souple pour les applications web.
2 Le choix de CAS
Dvelopp 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 lists ci-dessous.

- La scurit est assure par les dispositifs suivants :
o le mot de passe de l'utilisateur ne circule qu'entre le navigateur client et le serveur dauthentification,
ncessairement travers un canal crypt.
o Les r-authentifications suivantes sont faites de manire transparente l'utilisateur, sous rserve de l'acceptation
dun cookie priv et protg. Seul le serveur d'authentification peut lire et crire ce cookie, qui ne contient qu'un
identifiant de session.
o L'application reoit du serveur d'authentification un ticket opaque qui n'est pas porteur d'information
personnelle. Ce ticket circule en clair via le navigateur (en paramtre CGI) ; il n'est pas rejouable, a une dure 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 accs au mot de passe (schma pourtant classique
de pratiquement tous les mcanismes de SSO).
- Les mcanismes classiques imposent une communication entre le navigateur web et lapplication, ce qui exclut les
configurations n-tiers, o une application doit directement interroger un service ncessitant authentification (c'est le cas
par exemple pour un portail accdant un web service). CAS, dans sa version 2.0, rsout ce problme en proposant un
mcanisme de mandataires (proxies). Des tickets ddis permettent des applications tierces, nayant aucune
communication avec le navigateur client, dtre assures de lauthentification de lutilisateur. Cette fonctionnalit est
assurment le point fort de CAS.
- Le package propos implmente 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 dauthentification. Cela laisse la libert dimplmenter
exactement lauthentification souhaite (LDAP, Kerberos [8], certificats X509, NIS, un panachage, ...).
- Des librairies clientes en Java, Perl, J SP, ASP, PL/SQL et PHP sont livres. Cela permet une grande souplesse sur les
serveurs d'applications. Lintgration dans des outils utiliss dans le monde universitaire est dores et dj faite, comme
celle duPortal [9].
- L'utilisation de cookies exclusivement privs dans CAS (passage de tickets entre serveur dauthentification et
applications uniquement sous forme de paramtres de GET HTTP) permet CAS d'tre oprationnel sur des serveurs
situs dans des domaines DNS diffrents.
- Un module Apache (mod_cas) permet d'utiliser CAS pour protger l'accs des documents web statiques, les librairies
clientes ne pouvant tre utilises 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 Universits amricaines, avec des authentifications internes Kerberos ou
LDAP, ce qui permet dtre confiant sur sa fiabilit
1
.

Nous vous proposons de dtailler dans cet article le fonctionnement d'une implmentation de SSO avec CAS, en nous
attachant prsenter les avantages et inconvnients de cette solution.
3 Le mcanisme CAS
3.1 Architecture
3.1.1 Le serveur CAS
L'authentification est centralise sur une machine unique, le serveur CAS. Ce serveur est le seul acteur du mcanisme CAS
avoir connaissance des mots de passe des utilisateurs. Son rle est double :
- authentifier les utilisateurs ;
- transmettre et certifier l'identit de la personne authentifie (aux clients CAS).
3.1.2 Les navigateurs (web)
Les navigateurs doivent satisfaire les contraintes suivantes pour bnficier de tout le confort de CAS
2
:

1
lUniversit dIndiana, CAS contrle environ 80 applications web destines une centaine de milliers dutilisateurs ; Le serveur CAS y effectue une
moyenne de 9000 authentifications par jour.

- disposer d'un moteur de chiffrement leur permettant d'utiliser le protocole HTTPS ;
- savoir effectuer des redirections HTTP (accder une page donne dans une entte Location lors d'une rponse 30x
une premire requte HTTP) et interprter le langage JavaScript ;
- savoir stocker des cookies, comme dfini par [4]. En particulier, les cookies privs ne devront tre retransmis qu'au
serveur les ayant mis pour garantir la scurit du mcanisme CAS.

Ces exigences sont satisfaites par tous les navigateurs classiquement utiliss, 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 dlivre les ressources qu'aprs stre assur que le navigateur qui l'accde se soit authentifi auprs du serveur
CAS.

Parmi les clients CAS, on trouve :
- des librairies correspondant aux langages communment employs en programmation web dynamique (Perl, Java, J SP,
PHP, ASP) ;
- un module Apache, qui permet de protger des documents statiques ;
- un module PAM, qui permet d'authentifier les utilisateurs au niveau systme.
3.2 Fonctionnement de base
3.2.1 Authentification d'un utilisateur
Un utilisateur non dj prcdemment authentifi, ou dont l'authentification a expir, et qui accde 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 :
serveur CAS
navigateur
formulaire
dauthentification
(HTTPS)

Figure 1 : Premier accs 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) :
serveur CAS
navigateur
rfrentiel
utilisateur
authentification
(HTTPS)
TGC
login
password

Figure 2 : Authentification d'un navigateur auprs du serveur CAS
Le Ticket Granting Cookie (TGC) est le passeport de lutilisateur auprs du serveur CAS. Le TGC, dure de vie
limite (typiquement quelques heures), est le moyen pour les navigateurs d'obtenir auprs 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 protg (toutes les requtes des navigateurs vers le serveur CAS se font sous HTTPS). Comme tous les tickets
utiliss dans le mcanisme 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 Accs une ressource protge aprs authentification
Lors de l'accs une ressource protge 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, prcdemment authentifi auprs du serveur CAS, lui prsente le
TGC (rappel : un cookie).

2
Si le moteur de chiffrement est absolument indispensable pour utiliser CAS, les autres contraintes, si elles ne sont pas satisfaites, n'empchent pas le
mcanisme CAS de fonctionner. Un navigateur ne sachant pas effectuer les redirections ou n'interprtant pas le langage J avaScript forcera l'utilisateur
effectuer un clic chaque redirection (qui ne sera alors plus transparente). Un navigateur ne stockant pas les cookies forcera l'utilisateur entrer ses
informations d'authentification chaque passage par le serveur d'authentification.

Sur prsentation du TGC, le serveur CAS dlivre 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 mme temps, il le redirige vers le service demandeur en passant le Service Ticket en paramtre CGI (cf
Figure 4).

serveur CAS
navigateur
client CAS
re
d
ir
e
c
tio
n
TGC
re
q
u

te
n
o
n
a
u
th
e
n
tifi
e

Figure 3 : Redirection vers le serveurCAS d'un
navigateur non authentifi auprs du client CAS
serveur CAS
navigateur
client CAS
a
u
t
h
e
n
t
i
f
i
c
a
t
i
o
n
(
H
T
T
P
S
)
re
d
ir
e
c
tio
n
TGC
TGC
ST
ST
re
q
u

te
n
o
n
a
u
th
e
n
tifi
e re
q
u

te
a
u
th
e
n
tifi
e

Figure 4 : Redirection par le serveur CAS d'un
navigateur vers un client CAS aprs authentification
Le Service Ticket est alors valid auprs du serveur CAS par le client CAS, directement en http, et la ressource peut tre
dlivre au navigateur (cf Figure 5).

Il est noter que toutes les redirections prsentes Figure 5 sont compltement transparentes pour lutilisateur. Celui-ci ne
voit pas les redirections et a l'impression d'accder directement la ressource dsire, sans authentification (cf Figure 6).

serveur CAS
navigateur
client CAS
a
u
t
h
e
n
t
i
f
i
c
a
t
i
o
n
(
H
T
T
P
S
)
re
d
ir
e
c
tio
n
demandedevalidation
ST
TGC
TGC
ST
ST
validation
re
q
u

te
n
o
n
a
u
th
e
n
tifi
e
r
p
o
n
s
e
re
q
u

te
a
u
th
e
n
tifi
e

Figure 5 : Validation d'un Service Ticket par
un client CAS auprs du serveur CAS
serveur CAS
navigateur
client CAS
TGC
re
q
u

te
n
o
n
a
u
th
e
n
tifi
e
r
p
o
n
s
e

Figure 6 : Vision par lutilisateur du
mcanisme dauthentification

Le Service Ticket (ST) est le passeport de lutilisateur auprs d'un client CAS. Il est non rejouable (ne peut tre prsent
qu'une seule fois au serveur CAS), limit un seul client CAS et sa dure de vie est trs limite dans le temps (typiquement
quelques secondes).
3.2.3 Accs une ressource protge sans authentification pralable
Si lutilisateur n'est pas dj authentifi auprs du serveur CAS avant d'accder une ressource, son navigateur est, comme
prcdemment, redirig vers le serveur CAS, qui lui propose alors un formulaire d'authentification.

Lors de la soumission du formulaire par le navigateur au serveur CAS, si les informations fournies sont correctes, le serveur
CAS :
- dlivre un TGC (Ticket Granting Cookie) au client, qui lui permettra ultrieurement de ne pas avoir se r-authentifier ;
- dlivre au client un Service Ticket destination du client CAS ;
- redirige le client vers le client CAS.

On voit ainsi qu'il n'est pas ncessaire d'tre pralablement authentifi pour accder une ressource protge.
3.3 Fonctionnement multi-tiers
3.3.1 Les mandataires (proxies) CAS
Le fonctionnement n-tiers de CAS consiste en la possibilit, pour un client CAS, de se comporter comme un navigateur. Un
tel client CAS est alors appel mandataire (proxy) CAS.

Les exemples d'utilisation de mandataires sont divers :
- un portail web, pour lequel l'utilisateur s'est authentifi, peut avoir besoin d'interroger une application externe sous
l'identit de l'utilisateur connect (un web service [11] par exemple) ;
- une passerelle web de courrier lectronique (webmail), laquelle un utilisateur sest authentifi, a besoin de se connecter
un serveur IMAP pour relever le courrier lectronique de l'utilisateur, sous son identit.

Dans le fonctionnement de base, le client CAS est toujours en lien direct avec le navigateur. Dans un fonctionnement n-
tiers, le navigateur accde un client CAS travers un mandataire CAS. Le mcanisme de redirection vu dans le
fonctionnement de base n'est alors plus applicable.
3.3.2 Fonctionnement 2-tiers
Un mandataire CAS, lorsqu'il valide un Service Ticket pour authentifier un utilisateur, effectue, dans le mme temps, une
demande de PGT (Proxy Granting Ticket) (cf Figure 7).

Le Proxy Granting Ticket (PGT) est le passeport dun mandataire CAS, pour un utilisateur, auprs du serveur CAS.
Le PGT est opaque, rejouable, et obtenu du serveur CAS par un canal chiffr (et un mcanisme de callback assurant son
intgrit). Comme le TGC, il est dure de vie limite (typiquement quelques heures).

Le PGT est l'quivalent, pour les mandataires CAS, des TGCs pour les navigateurs. Il permet d'authentifier lutilisateur
auprs du serveur CAS, et dobtenir ultrieurement du serveur CAS des Proxy Tickets, quivalents pour les mandataires des
Service Tickets pour les navigateurs.

Les Proxy Tickets (PT) sont, comme les Service Tickets, valids par le serveur CAS pour donner accs des ressources
protges (cf Figure 8).
serveur CAS
mandataire CAS
d
e
m
a
n
d
e
d
e

v
a
l
i
d
a
t
i
o
n
PGT
PGT
ST
v
a
l
i
d
a
t
i
o
n
navigateur
client CAS (service)

Figure 7 : Rcupration d'un PGT par un
mandataire CAS auprs du serveur CAS
serveur CAS
mandataire CAS
client CAS (service)
d
e
m
a
n
d
e

d
e

P
T
demandedevalidation
PGT
PGT
PT
PT
validation
PT
navigateur

Figure 8 : Validation d'un PT par un client
CAS accd par un mandataire CAS
Le Proxy Ticket (PT) est le passeport des mandataires CAS auprs des clients CAS. Il est opaque, non rejouable, et
dure de vie trs limite (comme le Service Ticket, typiquement quelques secondes).
3.3.3 Fonctionnement n-tiers
On voit aisment que le client CAS accd par le mandataire CAS du fonctionnement 2-tiers peut galement tre mandataire
son tour. Les mandataires peuvent ainsi tre chans (cf Figure 9).
CAS est notre connaissance, le seul mcanisme de SSO proposant un tel fonctionnement multi-tiers sans aucune
propagation de mot de passe.
navigateur Mandataire
CAS n1
mandataire
CAS n2
client CAS

Figure 9 : Schma de fonctionnement n-tiers
4 Lauthentification sous CAS
CAS, dans sa distribution originale, ne propose pas de classe d'authentification : les mthodes d'authentification sont la
charge de l'administrateur du serveur CAS
3
.

Dveloppe au sein du projet ESUP-Portail [12], la classe GenericHandler [13] permet l'implmentation de plusieurs
mthodes d'authentification plus ou moins traditionnelles : annuaires LDAP, bases de donnes, domaines NIS, et fichiers.
Cette classe peut tre aisment tendue d'autres mthodes d'authentification, selon les besoins des administrateurs de sites
(Novell, Kerberos, Active Directory, ...)
4
.

La configuration du serveur se fait simplement en renseignant un fichier au format XML. Une ou plusieurs mthodes
d'authentification sont spcifies, et testes squentiellement jusqu' authentification de l'utilisateur.
4.1 Authentification sur un annuaire LDAP
Parce que LDAP est devenu un (le) standard de rfrentiel utilisateur, l'authentification sur un annuaire LDAP est
aujourd'hui la mthode la plus souvent utilise.

Deux modes d'accs l'annuaire sont proposs, selon la structure interne de l'annuaire.
4.1.1 Accs direct l'annuaire (ldap_fastbind)
Le mode ldap_fastbind peut tre utilis pour les annuaires dont le DN (Distinguished Name) d'un utilisateur peut tre
directement dduit de son nom de login. Pratiquement, il s'agit des annuaires dont tous les utilisateurs sont stocks au mme
niveau hirarchique.

CAS tente alors une connexion l'annuaire sur le DN de l'utilisateur et le mot de passe fourni. Lutilisateur est considr
comme authentifi si la connexion russit.

On utilisera par exemple :
<authentication>
<ldap version="3" timeout="5">
<ldap_fastbind filter="uid=%u,ou=people,dc=univ-rennes1,dc=fr" />
<ldap_server host="ldap.ifsic.univ-rennes1.fr" port="389" secured="no" />
</ldap>
< /authentication>
4.1.2 Recherche dans l'annuaire (ldap_bind)
Lorsque la dduction du DN de lutilisateur partir de son nom de connexion est impossible
5
, il faut alors utiliser le mode
ldap_bind, qui effectue une recherche du DN de l'utilisateur dans l'annuaire avant de tenter une connexion.

On utilisera par exemple :

3
Une classe dauthentification basique est fourni avec la distribution cas-server, et dautres classes taient disponibles, nanmoins simplistes, ce qui a
conduit au dveloppement de GenericHandler par le projet ESUP-Portail.
4
Les modules dauthentification sappuyant sur des certificats X509, ainsi que un domaine Windows NT, sont en cours de dveloppement.
5
Par exemple lorsque les utilisateurs de l'annuaire sont situs dans des hirarchies diffrentes.
<authentication>
<ldap version="3" timeout="5">
<ldap_bind search_base="dc=univ-rennes1,dc=fr" scope="sub" filter="uid=%u" bind_dn="admin" bind_pw="secret" />
<ldap_server host="ldap.ifsic.univ-rennes1.fr" port="389" secured="no" />
</ldap>
< /authentication>
4.1.3 Redondance des annuaires
Afin d'assurer la tolrance aux fautes de l'annuaire LDAP, il est possible de spcifier non pas un seul annuaire LDAP, mais
une liste d'annuaires, qui sont alors considrs comme des rplicas. La panne d'un annuaire est alors pallie par la prsence
de ses rplicas
6
.
4.2 Autres modes dauthentification
4.2.1 Sur une base de donnes
Cette mthode est essentiellement destine des organisations dont certains utilisateurs, pour des raisons techniques ou
organisationnelles, ne sont pas enregistrs dans leur annuaire LDAP mais dans une base de donnes
7
. Comme pour
l'authentification LDAP, la tolrance aux fautes est assure par redondance des serveurs de donnes, et deux modes sont
proposs :

- Pour le mode connexion (database_bind), les utilisateurs authentifier doivent tre galement utilisateurs dclars
de la base de donnes. L'authentification est russie si les informations de connexion fournis par l'utilisateur permettent
de se connecter la base de donnes.
- Le mode recherche (database_search) utilise une connexion privilgie la base, et les informations de connexion
des utilisateurs sont stockes dans une table. L'authentification est russie lorsque qu'une correspondance est tablie entre
les informations fournies par l'utilisateur et celles contenues dans la base de donnes.
4.2.2 Sur des certificats personnels x509
Les certificats personnels x509 sont communment utiliss pour l'authentification des applications web. Lorsqu'un certificat
est transmis par le navigateur au serveur CAS, il peut servir d'authentification pour son utilisateur. Lorsqu'un utilisateur
prsente un certificat x509, le serveur CAS :

- contrle la validit du certificat (au sens des PKI) ;
- recherche lidentit de lutilisateur, en sappuyant sur un annuaire LDAP ou une base de donnes.
4.2.3 Sur un domaine Kerberos
Ce mode nest pas implment dans la version courante de GenericHandler, mais lauthentification Kerberos fonctionne
dans plusieurs universits amricaines.
4.2.4 Sur un domaine NIS
Les organisations ne disposant pas (encore) d'un annuaire LDAP peuvent utiliser CAS en vrifiant l'authentification des
utilisateurs sur un domaine NIS.
La connexion du serveur CAS au domaine NIS est fait soit directement en spcifiant un ou plusieurs serveurs NIS
(redondants), soit par broadcast si aucun serveur n'est spcifi.
4.2.5 Sur domaine Windows NT
CAS peut galement dlguer l'authentification un domaine Windows NT. La connexion du serveur CAS au domaine
Windows NT se fait vers un ou plusieurs contrleurs de domaine (redondants, natifs NT ou Samba).
4.2.6 Sur un fichier
GenericHandler offre enfin ( l'origine des fins de test, mais cette mthode d'authentification peut tre utilise en
production pour des cas trs particuliers) la possibilit d'authentifier les utilisateurs sur un fichier d'utilisateurs de type
passwd Unix (gnrs par htpasswd par exemple).

6
En cas d'authentification infructueuse sur un des annuaires, l'utilisateur n'est pas authentifi puisque les annuaires sont senss contenir les mme donnes.
7
Les gestionnaires MySQL et PostGreSQL sont supports et le support de Oracle8 est en cours de dveloppement.
5 CAS-ification d'une application web
La CAS-ification d'une application web est une chose aise et lgre. Des librairies clientes sont disponibles afin de faciliter
cette opration.

On distingue trois types d'applications :

- les applications client CAS simples : elles ont juste besoin d'authentifier une personne ;
- les applications mandataires (ou proxies) CAS : elles on besoin d'authentifier la personne, et font galement appel
des services tiers ayant besoin d'authentifier (un web service, par exemple). Ces applications doivent donc demander un
Proxy Granting Ticket auprs du serveur CAS pour cet utilisateur ; ce PGT permettra l'application de requrir
ultrieurement un Proxy Ticket qu'elle passera au service tiers ;
- les services tiers, qui obtiennent un Proxy Ticket d'un mandataire CAS ; ce PT sera exploit par le service tiers de la
mme faon qu'un Service Ticket, afin d'obtenir l'identit de lutilisateur.
5.1 Les applications client CAS simples
Le principe est de disposer d'une fonction ou mthode, qui, lorsqu'elle est appele, droule le mcanisme d'authentification
CAS et retourne l'identifiant de l'utilisateur.

Cette fonction doit donc raliser les oprations suivantes :

- si lutilisateur nest pas dj authentifi, rediriger le navigateur web vers le serveur CAS, en passant en paramtre une
URL de retour ;
- tre en attente sur lURL de retour, afin de rcuprer un Service Ticket ;
- valider le Service Ticket auprs du serveur CAS en gnrant une requte HTTP(S). Le serveur CAS renvoie alors
lidentifiant de lutilisateur, certifi.

Afin d'illustrer la simplicit du code ncessaire, un exemple PHP ralisant ces oprations est donn ci-aprs. Dans une
application relle, c'est une librairie qui serait utilise, comme dcrit ensuite.
5.1.1 Un exemple simple en PHP
Nous montrons ci-dessous comment un client CAS (scr i pt . php) peut tre simplement crit en PHP.

Si ce script est appel sans paramtre (par ex. ht t p: / / t est . uni v. f r / scr i pt . php), il redirige le navigateur web vers le
serveur CAS, en passant sa propre URL en paramtre ; l'URL d'appel est alors la suivante :
https://cas.univ.fr/login?service=http://test.univ.fr/script.php

L'utilisateur s'authentifie auprs du serveur CAS ; le navigateur est redirig vers l'URL de retour, avec en paramtre le
Service Ticket . lURL de retour est alors (par exemple) :
http://test.univ.fr/script.php?ticket=ST-2-uw2KEWinSFeZ9fotZIio

Le script scr i pt . php va alors valider ce ticket auprs du serveur CAS, directement en HTTP(S) ; l'URL appele est :
http(s)://auth.univ.fr/serviceValidate?service=http://test.univ.fr/script.php&ticket=ST-2-uw2KEWinSFeZ9fotZIio

Le serveur CAS valide ce ticket, et retourne alors l'identit de la personne, dans un format XML :
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:authenticationSuccess>
<cas:user>vmathieu</cas:user>
</cas:authenticationSuccess>
</cas:serviceResponse>

Un code possible pour lexemple dcrit ci-dessus est le suivant :

<?php /* ------ exemple de client CAS crit en PHP --------*/

// localisation du serveur CAS
define('CAS_BASE','https://auth.univ.fr');

// propre URL
$service = 'http://' . $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI'];
/** Cette simple fonction ralise lauthentification CAS.
* @return le login de lutilisateur authentifi, ou FALSE.
*/
function authenticate() {
global $service ;

// rcupration du ticket (retour du serveur CAS)
if (!isset($_GET['ticket'])) {
// pas de ticket : on redirige le navigateur web vers le serveur CAS
header('Location: ' . CAS_BASE . '/login?service=' . $service));
exit() ;
}
// un ticket a t transmis, on essaie de le valider auprs du serveur CAS
$fpage = fopen (CAS_BASE . '/serviceValidate?service='
. preg_replace('/&/','%26',$service) . '&ticket=' . $ticket, 'r');
if ($fpage) {
while (!feof ($fpage)) { $page .= fgets ($fpage, 1024); }
// analyse de la rponse du serveur CAS
if (preg_match('|<cas:authenticationSuccess>.*</cas:authenticationSuccess>|mis',$page)) {
if(preg_match('|<cas:user>(.*)</cas:user>|',$page,$match)){
return($match[1]);
}
}
}
// problme de validation
return FALSE;
}

$login = authenticate();

if ($login === FALSE ) {
echo 'Requte non authentifie (<a href="'.$service.'"><b>Recommencer</b></a>).';
exit() ;
}

// ce point, lutilisateur est authentifi
echo 'Utilisateur connect : ' . $login . '(<a href="' . CAS_BASE . '/logout"><b>dconnexion</b></a>)';
?>
5.1.2 Utilisation de la librairie CASUtils
CASUtils est une librairie Perl, fournie avec la distribution cliente CAS. Voici un exemple de script Perl (t est cas. cgi )
utilisant cette librairie :

#!/usr/bin/perl

use lib "/var/www/cgi-bin";
use CASUtils;
require CGI;

my $cgi = new CGI;
my $status = &Yale::CASUtils::check_login('http://test/univ.fr/cgi-bin/testcas.cgi');
if ($status == -1) {
printf "Content-type: text/plain\n\nRequte non authentifie";
exit 0;
}

printf "Content-type:text/plain\n\nUtilisateur connect : $status";

La librairie CASUtils est rudimentaire (URLs relatives au serveur CAS codes en dur dans la librairie) mais permet de
CAS-ifier facilement nimporte quelle application crite en Perl.
5.1.3 Utilisation de la librairie phpCAS
La librairie phpCAS [14] a t dveloppe par le projet ESUP-Portail. En voici un exemple d'utilisation :

<?php /* ------ exemple de client CAS utilisant phpCAS --------*/
include_once('CAS.php');
phpCAS::client(CAS_VERSION_2_0,'cas.univ.fr',443,'');
phpCAS::authenticateIfNeeded();
?>
<ht ml >
<body>
<h1>Aut hent i f i cat i on r ussi e&nbsp; ! </ h1>
<p>L ut i l i sat eur aut hent i f i est <b><?php echo phpCAS::getUser(); ?></ b>. </ p>
</ body>
</ ht ml >
5.1.4 Autre librairies
D'autres librairies sont fournies avec la distribution client CAS, pour diffrents langages : ASP, Java, JSP, PL/SQL, et
Python. Elles ne sont pas dtailles ici, mais leur usage est ais.
5.2 Les applications mandataires (proxies) CAS
Le dbut du mcanisme est identique celui d'un client CAS ordinaire : la rcupration d'un Service Ticket.

Ensuite, lors de la validation de ce ST, un paramtre supplmentaire est pass au serveur CAS : une URL de callback. Le
serveur CAS retourne alors :
- l'identifiant de l'utilisateur (comme pour un client CAS non mandataire),
- un PGT par lURL de callback
8
.
Comme vu en 3.3.2 ( Fonctionnement 2-tiers ), ce PGT permet ultrieurement au mandataire de sauthentifier auprs du
serveur CAS pour lutilisateur (identifi par le ST).

Les librairies clientes Java et phpCAS permettent de masquer la complexit lors du dveloppement d'un mandataire CAS.
Voici par exemple limplmentation dun mandataire CAS laide de la librairie phpCAS :

<?php /* ------ exemple de mandataire CAS utilisant phpCAS --------*/
include_once('CAS.php');
phpCAS::proxy(CAS_VERSION_2_0,'auth.univ.fr',443,'');
phpCAS::authenticateIfNeeded();
?>
<html><body>
<p>le login de l'utilisateur est <b><?php echo phpCAS::getUser(); ?></b>.</p>
<?php
flush();
// appel du service tiers
if (phpCAS::serviceWeb('http://test.univ.fr/serviceWeb.php',$err_code,$output)) {
echo 'Reponse du service tiers : <br>' . $output;
}
?>
</body></html>
5.3 Les applications tierces
Les applications tierces sont aussi faciles CAS-ifier quun client CAS simple. Elles font exactement le mme travail quun
client CAS simple, en validant auprs du serveur CAS Proxy Ticket ( la place dun Service Ticket pour les clients CAS).
Ainsi, le service tiers associ l'exemple prcdent serait, en phpCAS :

<?php /* ------ exemple de service CAS utilisant phpCAS --------*/
include_once('CAS.php');
phpCAS::client(CAS_VERSION_2_0,'cas.univ.fr',443,'');
phpCAS::authenticateIfNeeded();

// pour cet exemple, on retourne une petite phrase qui indique que l'authentification est correcte
echo '<p>le login utilisateur est <b>' . phpCAS::getUser() . '</b>.</p>';
?>
5.4 Quelques prcautions prendre lors de la CAS-ification d'applications
5.4.1 Grer des sessions applicatives
Les applications doivent grer des sessions applicatives, pour que le mcanisme CAS ne soit droul qu'une seule fois lors
de l'accs l'application, et non chaque accs, ceci pour des raisons videntes de performances. Cette remarque vaut
galement pour les changes entre mandataires CAS et services tiers.
5.4.2 Risque d'asynchronisme de sessions (pour les mandataires CAS)
On a vu que la rcupration d'un PGT pour un utilisateur, et de PT est une chose facile, en utilisant les libraires adquates.
Le dveloppeur d'une application mandataire doit cependant prendre certaines prcautions. Prenons l'exemple d'un portail
web, qui serait mandataire CAS.

L'utilisateur se connecte dans son portail ; il s'authentifie donc via le serveur CAS, et le portail rcupre un PGT propre
cet utilisateur. Une session applicative est mise en place entre le portail et lutilisateur, session qui peut durer plusieurs
heures. Imaginons que, pendant cette session applicative, le PGT devienne invalide (expiration du PGT, dconnexion CAS

8
Le PGT est transmis par le serveur CAS grce lURL de callback, un canal indpendant et chiffr, ce qui assure sa scurit.
depuis une autre fentre de navigateur, ...) ; on se trouve alors dans un cas de figure o l'utilisateur a une session active
auprs le portail, celui-ci tant dans l'impossibilit de rcuprer un PT pour accder un service tiers.

Ce cas de figure doit tre trait par les applications mandataires, par une dconnexion force de l'utilisateur.
5.5 Authentification CAS pour des pages web statiques
Nous avons vu que CAS apportait au dveloppeur des librairies pour authentifier les utilisateurs dapplications web. CAS
permet galement de protger des documents statiques, grce au module Apache mod_cas. laide de simples directives de
configuration dApache, un site ou des parties dun site peuvent ntre rendues accessibles quaprs authentification auprs
dun serveur CAS
9
. On utilisera par exemple les directives :

CASServerHostname cas.univ.fr
CASServerPort 8443
CASServerBaseUri /cas
CASServerCACertFile /etc/x509/cert.root.pem

<Location /protected>
AuthType CAS
Require valid-user
</Location>
6 CAS-ification d'une application non web
L'objectif premier d'un mcanisme de SSO web est bien sr ... d'offrir un service d'authentification unique simple et
performant des applications web. CAS va bien plus loin en permettant de rendre compatibles diffrents services non web
10

tels que IMAP, FTP, ... avec son propre mcanisme.

Il suffit pour cela que ces services sappuient sur PAM (Pluggable Authentication Module) [10], comme savent le faire la
plupart des services de base sous Unix.
6.1 Le module PAM pam_cas
Le module pam_cas est fourni avec la distribution client CAS. Il est la fois trs puissant et lger (environ 300 lignes de
code C, dont les deux tiers partags avec le module Apache mod_cas).

Il permet ainsi un service Unix d'authentifier une personne en recevant un identifiant (comme dhabitude) et un ticket
(Service Ticket ou Proxy Ticket) la place du mot de passe. Le ticket reu par le service est valid par pam_cas auprs du
serveur CAS
11
.

Notons que lon ne conoit lutilisation de pam_cas que dans un fonctionnement multi-tiers, le service Unix ntant accd
que par un client (mandataire) CAS, qui fournit au service un Proxy Ticket. Il est en effet inconcevable de demander un
utilisateur humain (dun service FTP par exemple) un ticket CAS.

Heureusement, le fonctionnement modulaire de PAM permet dajouter un service un mode dauthentification tout en
conservant les autres modes, comme le montre lexemple suivant.
6.2 Exemple : utilisation de pam_cas pour un serveur IMAP
L'objectif est de rendre un serveur IMAP compatible avec CAS, afin d'autoriser des accs depuis un portail web, ou un
webmail, tout en continuant autoriser les clients de messagerie traditionnels utiliser le mot de passe utilisateur, et non un
ticket.

Sous rserve que le serveur IMAP soit compatible avec PAM (ce qui est gnralement le cas), le fichier de configuration de
PAM pour IMAP pourra par exemple ressembler :

auth sufficient /lib/security/pam_cas.so \
-simap://mail.univ.fr \
-phttps://ent.univ.fr/uPortal/CasProxyServlet
auth sufficient /lib/security/pam_ldap
auth required /lib/security/pam_pwdb.so shadow nullok

9
Les utilisateurs non authentifis se voient redirigs vers le serveur CAS, comme lors de laccs une application. En ce sens, mod_cas est un client CAS.
10
Laccs ces services non web doit nanmoins se faire partir dune application web (un mandataire CAS).
11
Afin de limiter les requtes vers le serveur CAS, la validation par pam_cas nest effectue que lorsque le mot de passe fourni a la forme dun ticket
(commence par ST- ou PT- ).

Dans notre exemple, une premire authentification est tente via pam_cas ; si cette authentification choue, une seconde
tentative est tente via pam_ldap ; enfin, en cas de nouvel chec, une authentification Unix traditionnelle va tre tente.
PAM
p
a
m
_
c
a
s
p
a
m
_
x
x
x
serveur CAS
rfrentiel
utilisateurs
(LDAP par ex.)
dmon imapd
login + password
login + PT
client de
messagerie
traditionnel
mandataire
CAS

Figure 10 : Utilisation de pam_cas pour un serveur IMAP
6.3 CAS-ification du serveur Cyrus-IMAP
Le cas du protocole IMAP est trs particulier, et certainement un des plus dlicats mettre en oeuvre : les clients IMAP et
principalement les webmails ont la fcheuse tendance gnrer de trs nombreuses requtes, avec rupture et r-ouverture de
connexions, donc nouvelles demandes d'authentification.

Dans le cadre d'un simple webmail, cela a pour consquence une charge plus importante du serveur web. Dans le cadre
dune authentification CAS, puisqu chaque requte IMAP est associe une authentification, la charge est galement
supporte par le serveur CAS, ce qui peut tre rdhibitoire.

En l'absence d'un mcanisme de cache ct serveur IMAP, et pour chaque nouvelle connexion, l'application cliente (le
webmail) doit demander un Proxy Ticket auprs du serveur CAS, puis le module pam_cas doit valider ce ticket. Le
mcanisme est simple mettre en oeuvre, mais on en voit rapidement la limite en terme de performances. Un cache est
indispensable.

La mise en uvre dun tel cache est possible, en standard, avec le serveur Cyrus-IMAP (cf Figure 11). En effet, Cyrus-
IMAP s'appuie sur Cyrus-SASL pour l'authentification ; or, Cyrus-SASL peut utiliser directement diffrents mcanismes
d'authentification (PAM, LDAP, Kerberos, fichier DBM, ...) ou encore faire appel un dmon Unix ddi cet effet,
saslauthd.

Ce dmon, qui communique avec Cyrus-SASL via une socket Unix, prsente un double intrt :
- il peut tre excut par un super-utilisateur (root), ce qui permet l'authentification Unix, tout en continuant excuter
le dmon IMAP avec un compte privilges limits (pour des raisons videntes de scurit).
- il propose un mcanisme de cache.

Grce au cache de saslauthd, l'application cliente IMAP est capable de rejouer le mme Proxy Ticket, saslauthd n'ayant plus
besoin de faire appel PAM pour s'assurer de la validit du ticket une fois celui-ci stock dans son cache (flche 2 Figure
11). Lutilisation du cache permet de solliciter au minimum le serveur CAS
12
.

12
La mise en uvre du cache de saslauthd a montr une efficacit de plus de 95% (moins de 5% des PT donnent lieu une validation auprs du serveur
CAS, soit une rduction de sa charge dun facteur suprieur 20).
dmon imapd (Cyrus)
PAM
p
a
m
_
c
a
s
p
a
m
_
x
x
x
sasl
cache
serveur CAS
rfrentiel
utilisateurs
(LDAP par ex.)
3
2
4
1
dmon sasl_authd
socket Unix
login + password
login + PT
client de
messagerie
traditionnel
mandataire
CAS

Figure 11 : CAS-ification du serveur Cyrus-IMAP
6.4 Application : webmail en SSO avec IMP
Le cas du webmail est trs difficile traiter du fait des nombreuses requtes d'ouverture de connexion gnres.

Dans un premier temps, il faut adapter le webmail (en l'occurrence, IMP) en lui donnant les fonctionnalits de mandataire
CAS. C'est une chose aise, grce la librairie phpCAS (cf 5.2 Les applications mandataires (proxies) CAS ).
Il devient donc capable d'obtenir facilement un Proxy Ticket pour permettre au service IMAP d'authentifier l'utilisateur.

Il faut ensuite modifier le comportement du webmail pour tenir compte de la versatilit de ce nouveau type de mot de passe.
En effet, le PT est manipul comme un mot de passe par le webmail, mais sa dure de validit est limite. Le webmail peut
ainsi tre amen utiliser plusieurs fois le mme PT (grce au cache IMAP), comme un mot de passe traditionnel.

Malheureusement, il n'est pas exclu quun utilisateur, durant sa session webmail, lance galement une requte IMAP par une
autre voie, son portail d'accs ou son client de messagerie habituel par exemple. Dans ce cas, le PT qui tait mmoris par le
cache IMAP est cras par un autre PT, voire par le mot de passe de l'utilisateur.

Lors de la tentative suivante de la part du webmail avec l'ancien PT, la connexion IMAP est refuse. Il faut alors que le
webmail soit capable de traiter ce refus sans clore la session de l'utilisateur, cest--dire de redemander un nouveau PT et de
retenter une nouvelle connexion IMAP.

Ce problme, complexe comprendre, nen est pas moins difficile rsoudre ;-). Les librairies clientes sont de ce fait
beaucoup plus complexes que nous lavons laiss penser en 5.1.1 ( Un exemple simple en PHP ).
7 Limitations actuelles et perspectives
Nous avons vu tout l'intrt de CAS pour mettre en uvre une plate-forme de SSO :
- open-source et libre,
- trs bon niveau de scurit,
- mise en oeuvre aise du serveur CAS,
- fonctionnement multi-tiers,
- CAS-ification aise des applications web.

Nous abordons maintenant les limitations de CAS, ou certains points plus dlicats, et les perspectives permettant un certain
optimisme.
7.1 CAS est un SSO, limit une authentification locale
CAS est propos comme mcanisme de SSO web, et nous avons vu qu'il sait aller au del, grce pam_cas. En revanche, il
se limite l'authentification des utilisateurs ; Il ne traite absolument pas les besoins lis aux autorisations (droits applicatifs)
ni au transport d'attributs
13
.

En outre, la base dauthentification est locale, au niveau de ltablissement. Les aspects inter-tablissements ne sont donc
pas pris en compte.

13
Dans les recommandations du groupe de travail AAS [16] (annexe du SDET [17]), la gestion des autorisations est confi un service ddi, comme lest
le serveur CAS pour lauthentification.
Le projet Shibboleth [19] est un projet open-source dInternet2 trs actif qui propose un mcanisme de transport dattributs
et dauthentification inter-tablissements. Il ne propose pas pour le moment le SSO local, laiss linitiative de chaque
tablissement. De rcentes discussions autour de Shibboleth laissent entendre quun mcanisme de SSO pourrait tre
propos par dfaut ; CAS fait partie des implmentations pressenties pour cela, ce qui pallierait les limitations actuelles
14
.
7.2 Monte en charge et tolrance aux pannes
Dans un environnement CAS, tout accs une application web ncessitant authentification passe ncessairement par le
serveur CAS. Sa disponibilit et son bon fonctionnement deviennent critiques pour le fonctionnement des applicatifs.

Dans l'tat actuel, CAS ne permet pas d'envisager un partage de charge entre plusieurs serveurs. En effet, les diffrents
objets manipuls (essentiellement les tickets) sont maintenus en mmoire du processus serveur CAS, ceci a priori pour des
raisons d'efficacit et de simplicit. Ce fonctionnement rend impossible le partage de charge (load balacing) entre plusieurs
serveurs rendant le service dauthentification
15
.

Dans la pratique, les universits ayant dploy CAS nont pas rencontr de problme de monte en charge, les processus
mis en uvre tant relativement simples. Le problme de la tolrance aux fautes est en revanche, au vu de la criticit du
service dauthentification, beaucoup plus crucial.

Il est certes possible de maintenir en tat de veille un serveur CAS de secours (spare), qui pourra tre utilis en cas de
dfaillance du serveur principal ou simplement de maintenance. Dans le cas, par exemple, o un serveur Apache est mis en
frontal du serveur J 2EE (Tomcat au autre) supportant le serveur CAS ; la bascule d'un serveur CAS vers un autre est
extrmement simple.
Elle n'est cependant pas transparente : tous les tickets valides (TGC et PGT notamment) sont alors perdus, ce qui entrane
une r-authentification de l'utilisateur lors de l'accs une nouvelle application ou un nouveau service.

Une solution, consistant mmoriser les tickets de type granting (TGC et PGT) dans une base de donne, serait facilement
envisageable
16
. Dans ce cas, la bascule dun serveur CAS un autre (sappuyant sur la mme base de donnes) aurait des
consquences ngligeables.
Ceci permettrait denvisager plus sereinement une maintenance sur la machine hbergeant le serveur CAS.
Rfrences
[1] Autorit de certification CNRS. http://igc.services.cnrs.fr/CNRS-Test/
[2] Autorit de certification du CRU, http://pki.cru.fr
[3] Introduction aux architectures web de Signe Sign-On, Olivier Salaun, J RES2003
[4] Persistent client state (HTTP cookies). http://wp.netscape.com/newsref/std/cookie_spec.html
[5] Sun One Identity Server. http://www.sun.com
[6] Microsoft .NET Passport: One easy way to sign in online. http://www.passport.com
[7] ITS Central Authentication Service, http://www.yale.edu/tp/cas/
[8] Kerberos: The Network Authentication Protocol, http://web.mit.edu/kerberos/www/
[9] J ASIG (J ava Architectures Special Interest Group), Evolving portal implementations. http://mis105.mis.udel.edu/ja-
sig/uportal/
[10] Linux-PAM: Pluggable Authentication Modules for Linux, www.us.kernel.org/pub/linux/libs/pam/Linux-PAM-html/
[11] Web Services, http://www.w3.org/2002/ws/
[12] ESUP-Portail, http://www.esup-portail.org
[13] CAS GenericHandler, http://esup-casgeneric.sourceforge.net
[14] PhpCAS, http://esup-phpcas.sourceforge.net
[15] The Horde Project, http://www.horde.org
[16] Recommandations pour la gestion de lauthentification-autorisation-SSO, J uillet 2003,
http://www.educnet.education.fr/equip/sdet.htm
[17] Schma Directeur des Espaces numriques de Travail, juillet 2003, http://www.educnet.education.fr/equip/sdet.htm
[18] Sympa Mailing List Manager, http://www.sympa.org
[19] The Shibboleth Project, http://shibboleth.internet2.edu/


14
Les travaux rcents de Serge Aumont sur Sympa [18] montrent quil est possible pour un client CAS de sappuyer sur plusieurs serveurs CAS, mais sans
aucune communication ni relation de confiance entre ces serveurs.
15
Les tickets tant stocks en mmoire, il faut quun ticket soit valid par le serveur qui la mis.
16
Cette solution serait en effet trs peu pnalisante en terme de performances, car les tickets de type granting sont beaucoup plus rares que les PT et ST.