2.2.2.3 FONCTIONNEMENT DE
SHIBBOLETH AVEC SSO
Dans le modèle de CAS, l'authentification n'est
pas directement prise en charge par le service d'authentification de
l'IdP.Celui-ci ne fait que rediriger le navigateur vers le serveur de SSO, qui
renvoie alors à l'utilisateur un formulaire d'authentification.
Figure 21 : redirection du
navigateur vers le serveur de SSO
251684864
Une fois le formulaire remplit, le navigateur effectue
une nouvelle requête vers le serveur SSO, qui le redirige vers l'IdP. Le
service d'authentification de l'IdP, client SSO, effectue alors une nouvelle
redirection vers le SP et l'authentification se déroule ensuite comme vu
précédemment.
Figure 22 : fonctionnement de
Shibboleth avec SSO
251685888
.
Requêtes suivantes au même
SP
Comme vu précédemment, une session étant
mise en place entre le navigateur et le SP, ni l'IdP ni le serveur SSO
n'interviennent par la suite pour l'accès au même SP.
Figure 23 : requete suivant
le meme SP
251686912
Requêtes suivantes vers un autre
SP
Lorsque l'utilisateur est déjà
authentifié auprès du serveur SSO, le navigateur dispose d'un
identificateur de session (par exemple un TGC pour CAS) qui lui permet de ne
pas avoir à s'authentifier à nouveau.
Figure 24 :
délégation d'authentification vers un autre SP
251687936
2.2.2.4 FONCTIONNEMENT DE
SHIBBOLETH DANS UNE FEDERATION
Considérons le cas où un SP est
accessible à des utilisateurs rattachés à des
établissements différents. C'est par exemple le cas d'une
université souhaitant mettre à disposition de tous les personnels
de l'enseignement supérieur de sa région les archives de ses
thèses et publications scientifiques.
Le problème qui se pose alors est que le SP ne sait pas
vers quel IdP rediriger le navigateur pour l'authentification. Il est
résolu grâce au WAYF, dont le rôle est d'orienter les
utilisateurs pour sélectionner leur IdP.
Première requête vers un
SP
Lors de la première requête au SP, celui-ci ne
sachant pas quel IdP sera utilisé, le SP redirige le navigateur vers le
WAYF.
Figure 25 : redirection
transparente vers le WAYF
251688960
Le WAYF affiche alors à l'utilisateur alors une liste
d'IdP possibles. La requête suivante, vers le WAYF, redirige le
navigateur vers l'IdP choisi par l'utilisateur, qui à son tour redirige
le navigateur vers le serveur SSO, qui propose alors un formulaire
d'authentification.
Figure 26 : redirection du
WAYF vers le serveur de SSO
251689984
Le navigateur s'authentifie alors auprès du serveur
SSO, et l'authentification se déroule ensuite comme vu
précédemment.
Figure 27 : réponse du
SP après authentification du serveur SSO
251691008
Requêtes suivantes vers le même
SP
Comme vu précédemment, une session étant
mise en place entre le navigateur et le SP, ni le WAYF, ni l'IdP ni le serveur
SSO n'interviennent par la suite pour l'accès au même SP.
Figure 28 : réponse du
SP sans authentification
251692032
Requêtes suivantes vers un autre
SP
Lors du choix de l'IdP par l'utilisateur, il est possible pour
le WAYF de mémoriser ce choix dans le navigateur (à l'aide d'un
cookie). Dans ce cas, le WAYF peut utiliser ultérieurement cette
information, et faire en sorte que les requêtes suivantes soient non
bloquantes (en redirigeant automatiquement vers l'IdP choisi la première
fois). La figure montre comment, dans ce cas, l'authentification de
l'utilisateur est totalement transparente lors de l'accès à un
autre SP.
Figure 29 : le WAYF en action
dans une fédération
251693056
| 
