Fédération d'identité

Mécanisme général

Shibboleth est un mécanisme de fédération d'identités, développé au début des années 2000 par le consortium Internet2.

L'objectif de la propagation d'identités est double : déléguer l'authentification à l'établissement d'origine de l'utilisateur et obtenir certains attributs de l'utilisateur (pour gérer le contrôle d'accès ou personnaliser les contenus).

La délégation de l'authentification réutilise les techniques de Single Sign-On web (redirection, cookies…). Lors de l'accès initial à une ressource numérique, l'utilisateur est redirigé vers le service de découverte de la fédération, d'où il sélectionne son établissement d'origine ; il est ensuite renvoyé vers son fournisseur d'identités. Le prérequis pour le fournisseur d'identités est de disposer d'un service d'authentification global tel que Central Authentication Service (CAS) (pas forcément d'un SSO).

À l'issue de la phase d'authentification, le fournisseur de services prend connaissance de l'identifiant de l'utilisateur qui lui permettra, lors d'une deuxième phase, d'obtenir ses attributs. Le fournisseur d'identités a la possibilité de définir, de façon différenciée pour chaque interlocuteur, quels attributs utilisateur pourront être dévoilés.

De façon concrète, pour accéder à une ressource électronique, un étudiant pourra se connecter sur le site d'un éditeur au moyen des codes personnels attribués par son université pour les autres services usuels (sans avoir à se connecter au préalable sur le site de sa bibliothèque universitaire, qui redirigeait ensuite sur le site de l'éditeur).

Données transmises lors de l'utilisation d'une fédération d'identité pour accéder à un service

Lorsque vous vous connectez à un service via une fédération d'identité, plusieurs données sont transmises par cette dernière à l'opérateur du service.

Ces données sont "nom", "prénom", "adresse mail" et "affiliation". Votre affiliation peut être "administratif", "enseignant", "étudiant", "chercheur", "externe". Elle permet de personnaliser les services auxquels vous accédez via un connexion par fédération d'identité

Le référentiel utilisé pour lire ces données est l'annuaire (LDAP) de l’École polytechnique. Les données du LDAP utilisées dans ce cadre sont collectées selon des processus pilotés : pour les étudiants ces données sont collectées via les portails d’inscription administrative et pour tous les autres personnels elles le sont via le circuit d’onboarding et ses processus « nouveaux arrivant » et « réentrance ».

Le serveur Shibboleth de l'Ecole polytechnique (egide.polytechnique.fr) est enregistré auprès de 4 fédérations

Fédération d'identité de l'enseignement et recherche
Edugain
Fédération d'identité de l'Université Paris Saclay
Fédération d'identité d'IP Paris

Ses métadonnées sont consultables ici

https://registry.federation.renater.fr/entities/view/7744

Notez qu'un ancien serveur (idp.polytechnique.fr) est également toujours en activité pour quelques services

https://registry.federation.renater.fr/entities/view/4352

En savoir plus sur la connexion à un service via une fédération d'identité : article Renater
En cas de question ou de difficulté, créez un ticket sur le portail d'assistance

Procédure de mise en place d'un nouveau service

Afin de traiter au mieux votre demande, merci de nous préciser au mieux le contexte en indiquant si c’est un besoin ponctuel, une demande personnelle ou plus étendue.
A partir de ces éléments, le Directeur Technique (CTO) de la DSI peut lister les attributs nécessaires pour la synchronisation
Définition du sponsor qui sera responsable de l'échange de données :
- s'il s'agit d'une demande transversale -> DSI (CTO)
- s'il s'agit d'une demande localisée -> le ou la responsable de Service, voire son directeur ou sa directrice
Validation par le RSSI avec ces éléments
Validation par le DPO avec ces éléments
Si le sponsor est la DSI (CTO), nous déclarerons le service au registre de traitement
Si le sponsor n’est pas à la DSI, il devra se rapprocher du DPO afin qu’il déclare l’accès à ce nouveau service :
- Dans la mesure où des données personnelles seront transmises, il faut impérativement une validation du DPO
- Déclarer un nouveau registre de traitement (utilisateur avec le DPO en soutien)
Validation de la DSI (CTO)
Nous mettons alors à jour une tableau (avec colonne attributs synchronisés, validation RSSI, DPO et CTO, date et autre jugé nécessaire)
Transférons le ticket avec tous ces éléments à l'équipe Système pour mise en place ou résolution