WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Mise en oeuvre système d'authentification centralisé SSO avec fournisseur d'identités

( Télécharger le fichier original )
par Narcisse Kapdjou et Eric Marc Modo Nga
Université de Dschang/iut-fv de Bandjoun - Licence de technologie en ingénierie de RT 2012
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

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

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Il ne faut pas de tout pour faire un monde. Il faut du bonheur et rien d'autre"   Paul Eluard