2.2CONCEPTION
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 lenavigateur.
251621376
Figure 8 : architecture du
serveur CAS
251626496
ü 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 Apacheet un
module PAM, qui permet d'authentifier les utilisateurs au niveau
système.
ü Le navigateur
C'est l'élément disposantd'un moteur de
chiffrementleur 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
251627520
Si les informations sont correctes, le serveur renvoie au
navigateur un cookieappelé 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 cookieprivé (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).
2.2.1.3 ACCES A UNE
RESSOURCE PROTEGEE APRESAUTHENTIFICATION
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 (le navigateur),
précédemment authentifié auprès du serveur CAS et
lui présente le TGC.
 
Redirection vers le serveurCAS d'un navigateur non
authentifié auprès du client CAS
Redirection par le serveur CAS d'un
navigateur vers un client CAS après
authentification
251622400
Figure 10 : redirection
transparente vers le serveur CAS
251628544
Sur présentation du TGC, le serveur CAS délivre
au navigateur un Service Ticket(ST).C'est un ticket opaque, qui ne transporte
aucune information personnelle. Iln'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 Ticketen
paramètre.
Le Service Ticketest alors validé auprès du
serveur CAS par le client CAS, directement en http, et la ressource peut
être délivrée au navigateur.
Il est à noter que toutes les redirections
présentées sont complètement transparentes pour
l'utilisateur. Celui-ci ne voit pas les redirections et a l'impression
d'accéder directement à la ressource désirée, sans
authentification.
 
Figure 11 : validation pour
l'accès à une ressource
251629568
Un navigateur ne sachant pas effectuer les redirections ou
n'interprétant pas le langage JavaScript 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.
| 
