FEDERATION - Shibboleth : Différence entre versions

De PedroWiki
(Nouvelle page : = Introduction = Fédération d'identité: (A REDIGER, cf notes en fin de TP de formation) Sibboleth, définition: (A REDIGER) = Structure = 2 parties principales: l'IdP et le SP...)
 
m (Fournisseur de service: le SP)
Ligne 19 : Ligne 19 :
 
== Fournisseur de service: le SP ==
 
== Fournisseur de service: le SP ==
  
Un SP pour chaque service utilisant l'authentification Shibboleth (Possibilité d'utiliser un "proxy", 1 SP frontal pour plusieurs services sous-jacents.
+
Un SP pour chaque service utilisant l'authentification Shibboleth (Possibilité d'utiliser un "proxy", 1 SP frontal pour plusieurs services sous-jacents).
  
 
Le SP est un module pluggable dans Apache ou IIS, et qui permet par de la configuration côté serveur de protéger par Shibboleth des services web.
 
Le SP est un module pluggable dans Apache ou IIS, et qui permet par de la configuration côté serveur de protéger par Shibboleth des services web.

Version du 30 octobre 2008 à 14:29

Introduction

Fédération d'identité: (A REDIGER, cf notes en fin de TP de formation)

Sibboleth, définition: (A REDIGER)

Structure

2 parties principales: l'IdP et le SP.

Fournisseur d'Identité: l'IdP

Un IdP pour chaque stucture participant à la fédération.

L'IdP s'appuie sur le système d'authentification de la structure (par exemple SSO CAS).

Il transmet aux SP une validation du login, ainsi que potentiellement des attributs.

Fournisseur de service: le SP

Un SP pour chaque service utilisant l'authentification Shibboleth (Possibilité d'utiliser un "proxy", 1 SP frontal pour plusieurs services sous-jacents).

Le SP est un module pluggable dans Apache ou IIS, et qui permet par de la configuration côté serveur de protéger par Shibboleth des services web.

Remarques

  • L'utilisation du SP pour l'authentification sur un service web est à développer du coté applicatif (service web).
  • L'utilisation de l'authentification Shibboleth occasionne l'ouverture de plusieurs sessions:
    • 1 session du côté SP
    • 1 session du côté IdP
    • 1 session du côté système d'authentification sous-jacent à l'IdP (CAS par exemple).
    • éventuellement 1 session "applicative" du côté service web ayant nécessité l'authentification.
  • SLO: Single LOgout. Mécanisme permettant de clore toutes les sessions ouvertes, annoncé avec la version 2.x de l'IdP mais non encore développée à ce jour. Principe: le logout de l'application, par l'appel à une URL pointant sur le SP, permettrais de déclencher une série de demandes de fermetures vers tous les acteurs cités plus haut. ATTENTION à l'heure actuelle, uniquement fermeture de session du côté SP.

Liens utiles

Les FAQ "Fédération d'identité" du CRU