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.
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
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).
2.2.1.3 ACCES A UNE RESSOURCE PROTEGEE APRES AUTHENTIFICATION
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.
Figure 10 : redirection transparente vers le serveur CAS
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. Il n’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 Ticket en paramètre.
Le Service Ticket est 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
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.
2.2.1.4 ACCES A UNE RESSOURCE PROTEGEE SANS AUTHENTIFICATION PREALABLE
Si l’utilisateur n’est pas déjà authentifié auprès du serveur CAS avant d’accéder à une ressource, son navigateur est, comme précédemment, 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 :
– délivre un TGC (Ticket Granting Cookie) au client, qui lui permettra ultérieurement de ne pas avoir à se ré-authentifier
– délivre au client un Service Ticket à destination du client CAS
– redirige le client vers le client CAS
Figure 12 : accès à l’application sans authentification
2.2.1.5 PRINCIPE DE MANDAT AVEC CAS
Dans le fonctionnement de base, le client CAS est toujours en lien direct avec le navigateur. Dans un fonctionnement n-tiers, le navigateur accède à un client CAS à travers un mandataire CAS. Le mécanisme de redirection vu dans le fonctionnement de base n’est alors plus applicable.
– Fonctionnement 2-tiers
Un mandataire CAS, lorsqu’il valide un Service Ticket pour authentifier un utilisateur, effectue, dans le même temps, une demande de PGT (Proxy Granting Ticket).
Le PGT est le passeport d’un mandataire CAS, pour un utilisateur, auprès du serveur CAS.
Figure 13 : validation du PT pour l’accès à une ressource
– Fonctionnement n-tiers
On voit aisément que le client CAS accédé par le mandataire CAS du fonctionnement 2-tiers peut également être mandataire à son tour. Les mandataires peuvent ainsi être chaînés.
CAS est à notre connaissance, le seul mécanisme de SSO proposant un tel fonctionnement multi-tiers sans aucune propagation de mot de passe.
Figure 14 : CAS dans l’architecture n-tiers
CAS permet l’implémentation de plusieurs méthodes d’authentification plus ou moins traditionnelles : annuaires LDAP, bases de données, domaines NIS, et fichiers. Cette classe peut être aisément étendue à d’autres méthodes d’authentification, selon les besoins des administrateurs de sites (Novell, Kerberos, Active Directory, …)
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.
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.
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
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
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
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
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
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
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
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
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
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