2.2
CONCEPTION
2.2.1 LE MECANISME DE CAS
2.2.1.1
ARCHITECTURE
L'architecture de CAS [1] tourne autour de trois
principaux acteurs : le serveur CAS, le client CAS et le navigateur.
![](Mise-en-oeuvre-systeme-dauthentification-centralise-SSO-avec-fournisseur-didentites8.png)
![](Mise-en-oeuvre-systeme-dauthentification-centralise-SSO-avec-fournisseur-didentites9.png)
![](Mise-en-oeuvre-systeme-dauthentification-centralise-SSO-avec-fournisseur-didentites10.png)
![](Mise-en-oeuvre-systeme-dauthentification-centralise-SSO-avec-fournisseur-didentites11.png)
Figure 8 : architecture du
serveur CAS
ü 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 et transmettre certifier
l'identité de la personne authentifiée (aux
clients CAS) : c'est le serveur d'authentification.
ü Le client CAS
C'est l'agent d'authentification. Il peut être une
application web munie d'une librairie cliente ou un serveur web utilisant le
module mod_cas. Il ne délivre les ressources qu'après
s'être assuré que le navigateur qui y accède se soit
authentifié auprès du serveur CAS. Parmi les clients CAS, on
trouve : des librairies (Perl, Java, JSP, PHP, ASP), un module Apache et un
module PAM, qui permet d'authentifier les utilisateurs au niveau
système.
ü Le navigateur
C'est l'élément disposant d'un moteur de
chiffrement leur permettant d'utiliser le protocole HTTPS. Il
doit être capable savoir effectuer des redirections
http, interpréter le langage JavaScript
et savoir stocker des cookies : Il
représente l'utilisateur.
Ces exigences sont en général satisfaites par tous les
navigateurs classiquement utilisés, à savoir MicroSoft Internet
Explorer (depuis 5.0), Netscape Navigator (depuis 4.7) et Mozilla.
2.2.1.2 FONCTIONNEMENT DE BASE
Un utilisateur non 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 9 : fonctionnement de
base de CAS
![](Mise-en-oeuvre-systeme-dauthentification-centralise-SSO-avec-fournisseur-didentites13.png)
Si les informations sont correctes, le serveur renvoie au
navigateur un cookie appelé TGC (Ticket Granting Cookie).
Le 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).
|