2.2.2 LE MECANISME DE SHIBBOLETH
L'objectif est de montrer les interactions entre les
acteurs du système qui permettent la délégation de
l'authentification et la propagation des attributs utilisateurs. Afin de mieux
appréhender un fonctionnement globalement complexe, nous
présentons d'abord les acteurs du système, puis détaillons
les interactions entre les acteurs du système lors de l'accès par
un navigateur à une ressource web.
2.2.2.1 ARCHITECTURE
ü Le navigateur
Le premier acteur de l'architecture Shibboleth [2]
est donc logiquement le navigateur de l'utilisateur. Le navigateur doit
répondre aux exigences habituelles en matière de navigation web,
notamment l'interprétation des codes de retour HTTP (redirections),
ainsi que l'acceptation et la transmission des cookies selon les
normes en vigueur.
ü Le fournisseur de services (Service Provider ou
SP)
C'est une entité proposant des ressources web
sur la base d'un contexte de sécurité SAML et sera par la suite
nommée SP (Service Provider). Le fournisseur de ressource a en
particulier la charge de donner ou non l'accès aux ressources, en
fonction des attributs utilisateur.
ü Le fournisseur d'identités (Identity
Provider ou IdP)
C'est une entité authentifiant les utilisateurs
et fournissant leurs attributs. Elle sera par la suite notée IdP. Le
fournisseur d'identités s'appuie sur le SI de l'établissement,
tant pour l'authentification que pour la récupération des
attributs utilisateur à propager. De ce fait, il est en
général situé au plus proche du SI.
ü Le WAYF
Le WAYF (pour Where Are You From?, « d'où
êtes-vous ? ») est un service dont le but est d'orienter
l'utilisateur vers son IdP.
Seul l'objectif du WAYF est défini dans les
spécifications de Shibboleth :
- Proposer aux utilisateurs une liste d'IdP, parmi lesquels
les utilisateurs sont invités à sélectionner celui de leur
établissement de rattachement ;
- Une fois le choix effectué, il redirige les
utilisateurs vers l'IdP correspondant à leur choix.
L'architecture d'une offre applicative d'un
établissement dont l'authentification est confiée à
Shibboleth sera donc souvent celle décrite par la figure :
Figure 15 : fonctionnement du
WAYF
2.2.2.2 FONCTIONNEMENT DE SHIBBOLETH SANS CAS
Dans ce premier cas d'étude, nous
considérons que le SP connaît l'établissement de
rattachement de l'utilisateur, c'est-à-dire l'établissement qui
pourra l'authentifier. Le navigateur effectue donc une requête HTTP vers
le SP afin d'accéder à une ressource et le SP, sans information
d'authentification, le redirige vers l'IdP de l'établissement de
rattachement de l'utilisateur.
Figure 16 : requête du
navigateur vers le fournisseur de service
La réponse de l'IdP est une demande d'authentification,
sous la forme d'une erreur 401 Unauthorized ou d'un
formulaire web. L'utilisateur entre alors son identifiant et son mot de passe.
Une fois authentifié, l'IdP redirige alors le navigateur vers le SP,
accompagné d'une assertion SAML. Cette assertion signée par
l'IdP, le SP pourra donc faire confiance à l'assertion. Elle contient un
identifiant appelé nameIdentifier.
Figure 17 : redirection de
l'IdP vers le SP
Cet identifiant est opaque, c'est-à-dire qu'il ne
contient pas d'information personnelle concernant l'utilisateur. Il n'est
utilisé que dans le cadre des échanges entre les
différentes briques de Shibboleth, et n'est connu ni de la ressource
accédée ni du SI de l'établissement. Un exemple de
nameIdentifier est montré ci-dessous.
<saml:NameIdentifier
Format="urn:mace:shibboleth:1.0:nameIdentifier"
NameQualifier="https://idp.iut-fv.cm/shibboleth">
3f7b3dcf-1674-4ecd-92c8-1544f346baf8
</saml:NameIdentifier>
C'est cet identifiant opaque qui va permettre au SP de
récupérer les attributs de l'utilisateur auprès de l'IdP.
Ces attributs de l'utilisateur sont transmis au SP par l'IdP, via l'appel d'un
Web Service, l'échange du nameIdentifier.
Figure 18 : le SP demande les
attributs de l'utilisateur
Le SP peut alors effectuer le contrôle d'accès,
éventuellement utiliser les attributs de l'utilisateur dans la logique
applicative, puis retourner une réponse au navigateur.
Figure 19 : réponse du
SP au navigateur
Architecture logique du fournisseur de services
(SP)
Le fournisseur de services est composé de trois briques
logicielles :
- Le consommateur d'assertions (Assertion Consumer
Service),
- Le demandeur d'attributs (Attribute Requester),
- Le contrôleur d'accès.
Le consommateur d'assertions agit comme un
pré-filtre. C'est lui qui redirige vers l'IdP lorsque l'utilisateur
n'est pas authentifié. Il peut être implémenté au
niveau du serveur HTTP (par un module Apache ou un filtre J2EE par exemple).
Lorsque l'utilisateur est authentifié, alors le consommateur
d'assertions transmet le nameIdentifier au demandeur d'attributs.
Le demandeur d'attributs est chargé de
la récupération des attributs des utilisateurs auprès de
l'IdP. Il peut être implémenté comme un démon
(dédié, interrogeable par les processus du SP) ou par une
librairie, interrogeable par un applicatif web. Les attributs
récupérés par le demandeur d'attributs sont fournis au
contrôleur d'accès.
Le contrôleur d'accès est
chargé d'autoriser ou non l'accès aux ressources
demandées. Il peut être implémenté au niveau du
serveur HTTP (par un module Apache ou un filtre J2EE par exemple) ou encore par
une librairie, appelée par un applicatif web.
Architecture logique du fournisseur d'identités
(IdP)
Un fournisseur d'identités est composé de trois
briques logicielles :
- Le service d'authentification (Authentication Service),
- L'autorité d'authentification (Authentication
Authority),
- L'autorité d'attributs (Attribute Authrority).
Le service d'authentification est
chargé de l'authentification des utilisateurs vis-à-vis de
l'ensemble de l'IdP. C'est lui qui, par exemple, demande à l'utilisateur
un couple user/password, puis le valide auprès de la base
d'authentification du SI. Les implémentations du service
d'authentification peuvent être très variées, depuis un
module Apache authentifiant les utilisateurs auprès d'un annuaire LDAP,
jusqu'à un client de Single Sign-On comme nous le verrons
ultérieurement.
L'autorité d'authentification associe
le nameIdentifier à l'identifiant de l'utilisateur.
Figure 20 : fonctionnement de
Shibboleth sans CAS
L'autorité d'attributs délivre,
en réponse à une demande d'un SP, les attributs de l'utilisateur
correspondant à un nameIdentifier. L'association entre l'identifiant de
l'utilisateur et le nameIdentifier étant maintenue par l'autorité
d'authentification.
Figure 20 :
fonctionnement de Shibboleth sans CAS
| 
