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
Sommaire
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.