Fédération d’identités et propagation d’attributs avec Shibboleth Olivier Salaün, Florent Guilleux Comité Réseau des Universités Pascal Aubry IFSIC – Université de Rennes 1 UNR Bretagne http://federation.cru.fr

Présentation libre Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. http://www.gnu.org/licenses/licenses.html#FDL

Pourquoi une fédération ? Les solutions techniques Le système Shibboleth La fédération pilote du CRU, illustration de la mise en place d’une fédération d’identités Retours d’expérience et perspectives

Plan Pourquoi une fédération ? Problématiques et besoins Scenarii d’utilisation Objectif : vous convaincre que vous en avez besoin ;-)

Plan Pourquoi une fédération ?

Plan Pourquoi une fédération ? Les solutions techniques SAML Liberty Alliance Shibboleth WS-Federation Le choix de Shibboleth Objectif : vous montrer l’environnement technique

Plan Pourquoi une fédération ? Les solutions techniques

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth Fonctionnement sans SSO Fonctionnement avec SSO Fonctionnement avec SSO et WAYF À propos du WAYF Objectif : vous faire comprendre comment ça marche techniquement

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth Fonctionnement sans SSO Fonctionnement avec SSO Fonctionnement avec SSO et WAYF La délégation avec Shibboleth À propos du WAYF

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth Fonctionnement sans SSO Fonctionnement avec SSO Fonctionnement avec SSO et WAYF La délégation avec Shibboleth À propos du WAYF Les briques Shibbotleth Configuration d’un fournisseur d’identités Configuration d’un fournisseur de services Relations de confiance, aspects techniques Objectif : vous montrer comment on configure les briques logicielles de Shibboleth

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth La fédération pilote du CRU, illustration de la mise en place d’une fédération d’identités Relations de confiance La fédération pilote du CRU Nommage et sémantique des attributs Déclaration CNIL et respect de la vie privée Rejoindre la fédération du CRU Périmètre Objectif : vous faire comprendre ce qu’est une fédération

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth La fédération pilote du CRU, illustration de la mise en place d’une fédération d’identités

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth La fédération pilote du CRU, illustration de la mise en place d’une fédération d’identités Retours d’expérience et perspectives SWITCHaai, fédération académique Suisse Projets en France Délégation dans un contexte multi tiers Fournisseur d’identités virtuel Grilles de calcul Objectif : vous montrer ce qui marche aujourd’hui et ce qui pourrait marcher demain

Plan Pourquoi une fédération ?

Plan Pourquoi une fédération ? Problématique et besoins Scenarii d’utilisation

Le besoin Problématique Contexte Gérer l’accès à des ressources web Pour des utilisateurs d’autres établissements Contexte Mise en place de Single Sign-On dans les établissements Besoins de collaboration entre établissements Ces services ne sont pas interopérables

Avant c’était la zone… Certaines ressources pas protégées du tout Contrôle d’accès par adresses IP souvent utilisé Problèmes de gestion des utilisateurs au niveau de la ressource Multiplication des procédures de login Multiplication des comptes donc des mots de passe Difficultés de mise en place de ressources inter-établissements Université A Copyright SWITCHaai Sympa Moodle Bibliothèque B Périodiques Fond docu. Université C Thèses Moodle Gestion utilisateurs / Authentification Contrôle d’accès Ressource

Avec le SSO, c’était un peu mieux Université A Copyright SWITCHaai Sympa Moodle Bibliothèque B Périodiques Fond docu. Université C Thèses Moodle Gestion utilisateurs / Authentification Contrôle d’accès Ressource

Avec le SSO, c’était un peu mieux au niveau local… …mais pareil pour le reste ! Université A Copyright SWITCHaai Sympa SSO Moodle Bibliothèque B Périodiques Fond docu. Université C Thèses SSO Moodle Gestion utilisateurs / Authentification Contrôle d’accès Ressource

Heureusement, la fédération est arrivée ! Université A Copyright SWITCHaai Sympa SSO Moodle Bibliothèque B Périodiques Fond docu. Université C Thèses SSO Moodle Gestion utilisateurs / Authentification Contrôle d’accès Ressource

Heureusement, la fédération est arrivée ! Aucune tâche de gestion des utilisateurs au niveau de la ressource L’utilisateur s’authentifie une seule fois, dans son établissement L’utilisateur a accès à de nouvelles ressources Les ressources ont une plus grande audience Université A Copyright SWITCHaai Sympa SSO Moodle Bibliothèque B Périodiques Fond docu. Université C Thèses SSO Moodle Gestion utilisateurs / Authentification Contrôle d’accès Ressource

Articulation avec l’existant Shibboleth ne remplace ni un annuaire LDAP, ni un SSO Shibboleth a besoin de l’annuaire LDAP et du SSO

Plan Pourquoi une fédération ? Problématique et besoins Scenarii d’utilisation

Cas général Un établissement donne accès à des contenus en ligne Accès restreints aux utilisateurs des autres établissements de la communauté enseignement / recherche Mais les cas d’utilisation vont au-delà de ce cas standard…

Scenario n°1 Intranet pour un groupe de travail Les membres sont disséminés Chercheur, étudiants, association On délègue l’authentification

Scenario n°2 Contrôle d’accès en fonction du profil de l’utilisateur Exemple : étudiant en pharmacie Plus besoin de gérer la liste des utilisateurs potentiels

Scenario n°3 Accès aux périodiques électroniques depuis un ENT Elsevier, OCLC, JSTOR… Le fournisseur de services est hors communauté Pas d’informations nominatives

Plan Pourquoi une fédération ? Les solutions techniques SAML Liberty Alliance Shibboleth WS-Federation Le choix de Shibboleth

Security Assertion Markup Language Standard OASIS en 2002 Répond à un besoin d’interopérabilité Echanges d’assertions de sécurité entre services Indépendant des mécanismes d’authentification SAML

Types d’assertions SAML Authentification Échange d’attributs Décisions d’autorisation SAML

Exemple d’assertion SAML <saml:Assertion MajorVersion=”1” MinorVersion=”0” AssertionID=”128.9.167.32.12345678” Issuer=”Comite Reseau des Universites” IssueInstant=”2002-03-21T10:02:00Z”> <saml:Conditions NotBefore=”2002-03-21T10:02:00Z” NotAfter=”2002-03-21T10:07:00Z” /> <saml:AuthenticationStatement AuthenticationMethod=”password” AuthenticationInstant=”2002-03-21T10:02:00Z”> <saml:Subject> <saml:NameIdentifier SecurityDomain=”www.cru.fr” Name=”osalaun” /> </saml:Subject> </saml:AuthenticationStatement> SAML

Liberty Alliance SAML Liberty Alliance n’est pas un produit Consortium d’industriels produisant des spécifications sur la gestion d’identités S’appuie sur SAML Implémenté dans de nombreux produits Retenu par l’ADAE pour « Mon Service Public » SourceID Sun LASSO Liberty Alliance SAML

Les frameworks de Liberty Alliance ID-FF (Federation Framefork) Fédération de comptes Délégation d’authentification Single logout ID-WSF (Web Services Framework) Propagation d’attributs utilisateur Recherche de services d’identités Échange de méta données SourceID Sun LASSO Liberty Alliance SAML

Shibboleth SAML Norme et produit développé par Internet2 Open source Première version en 2002 Basé sur SAML (bibliothèque OpenSAML) Utilisé par la communauté enseignement/recherche en production en Suisse, USA, Angleterre, Finlande, Australie en cours de déploiement en Belgique, Allemagne Shibboleth SourceID Sun LASSO Shibboleth Liberty Alliance SAML

Shibboleth SAML Conçu pour interconnecter les SSO des établissements Fonctionnalités Délégation d’authentification WAYF pour orienter l’utilisateur Propagation des attributs utilisateur Partage de méta données Définition de règles de confiance Shibboleth SourceID Sun LASSO Shibboleth Liberty Alliance SAML

D’autres normes basées sur SAML Shibboleth SourceID Sun LASSO Shibboleth Liberty Alliance Oblix SAML

WS-Federation SAML Draft porté par Microsoft et IBM, 2003 Basée sur les spécifications WS-* WS-Security, WS-Trust, WS-Policy, WS-MetadataExchange Définit l’échange d’identités et d’attributs entre domaines de sécurité Shibboleth SourceID Sun LASSO ADFS Shibboleth Liberty Alliance Oblix WS-Federation SAML WS-*

Plan Pourquoi une fédération ? Les solutions techniques SAML Liberty Alliance Shibboleth WS-Federation Le choix de Shibboleth

Nos critères de choix Besoins fonctionnels Gestion d’attributs, anonymat, gestion de la confiance, single logout Adaptation à notre environnement Fournisseurs d’identités multiples Interopérabilité Intégration dans un SI, interopérabilité avec d’autres produits Solution open source Adaptabilité, pérennité, support, communauté des utilisateurs

Notre choix : Shibboleth Le CRU a évalué 2 solutions Shibboleth Lasso / SourceID Les raisons du choix de Shibboleth Shibboleth est un produit ; Lasso/SourceID sont des bibliothèques Modèle adapté à N fournisseurs d’identités Fonctionnalités avancées (gestion de la confiance) Solution non intrusive De nombreuses applications déjà « shibbolisées » Choix partagé par nos homologues

Interopérabilité de Shibboleth SAML : naturellement compatible Liberty Alliance : base commune SAML, Shibboleth 2.0 s’appuiera sur SAML 2.0 WS-Federation : intégration dans Shibboleth en cours Burton Group Catalyst Conference Interop Demo Test d’interopérabilité organisé par le Burton Group, juillet 2005 Résultats concluant entre Shibboleth (SAML 1.1) et Trustgenix, Sun, BMC, CA (Netegrity), HP et Datapower

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth Fonctionnement sans SSO Fonctionnement avec SSO Fonctionnement avec SSO et WAYF La délégation avec Shibboleth À propos du WAYF Les briques Shibbotleth Configuration d’un fournisseur d’identités Configuration d’un fournisseur de services Relations de confiance, aspects techniques

Shibboleth, c’est simple ;-) Serveur SSO ssoId Navigateur ticket ticket ticket userId nameId Consommateur d’assertions Demandeur d’attributs Contrôleur d’accès Ressource Service d’authentification Fournisseur de service WAYF nameId Autorité d’authentification attributes attributes userId Autorité d’attributs attributes De nombreux acteurs Référentiel utilisateurs De nombreuses interactions

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth Fonctionnement sans SSO Fonctionnement avec SSO Fonctionnement avec SSO et WAYF La délégation avec Shibboleth À propos du WAYF Les briques Shibbotleth Configuration d’un fournisseur d’identités Configuration d’un fournisseur de services Relations de confiance, aspects techniques

Fournisseur de services Sans SSO Navigateur Fournisseur de services (SP)

Sans SSO (première requête vers un SP) Navigateur Fournisseur d’identités (IdP) Fournisseur de services (SP)

Sans SSO (première requête vers un SP) Navigateur userId password nameId nameId Fournisseur d’identités (IdP) Fournisseur de services (SP) nameId attributes

Sans SSO (première requête vers un SP) Navigateur 4 3 2 1 userId password Fournisseur d’identités (IdP) Fournisseur de services (SP)

Sans SSO (requêtes suivantes vers le même SP) Navigateur Fournisseur d’identités (IdP) Fournisseur de services (SP)

Architecture logique du SP Navigateur userId password nameId nameId Consommateur d’assertions Demandeur d’attributs Contrôleur d’accès Ressource Fournisseur d’identités (IdP) Fournisseur de service nameId attributes attributes

Architecture logique de l’IdP Navigateur Base d’authentification userId password nameId nameId Fournisseur d’identités Service d’authentification Consommateur d’assertions userId nameId Demandeur d’attributs Autorité d’authentification nameId attributes attributes Contrôleur d’accès Autorité d’attributs userId Ressource attributes Référentiel utilisateurs

Base d’authentification Shibboleth, c’est quoi ? Navigateur Base d’authentification userId password nameId nameId Service d’authentification Fournisseur d’identités Consommateur d’assertions Shibboleth userId nameId Demandeur d’attributs Autorité d’authentification Shibboleth nameId attributes attributes Contrôleur d’accès Autorité d’attributs userId Ressource attributes Référentiel utilisateurs

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth Fonctionnement sans SSO Fonctionnement avec SSO Fonctionnement avec SSO et WAYF La délégation avec Shibboleth À propos du WAYF Les briques Shibboleth Configuration d’un fournisseur d’identités Configuration d’un fournisseur de services Relations de confiance, aspects techniques

Avec SSO (première requête vers un SP) Serveur SSO Navigateur Service d’authentification Consommateur d’assertions Demandeur d’attributs Autorité d’authentification Contrôleur d’accès Autorité d’attributs Ressource Référentiel utilisateurs

Avec SSO (première requête vers un SP) Serveur SSO userId password Navigateur ticket ticket ticket userId nameId nameId Service d’authentification Consommateur d’assertions nameId Demandeur d’attributs Autorité d’authentification nameId attributes attributes Contrôleur d’accès Autorité d’attributs userId Ressource attributes Référentiel utilisateurs

Avec SSO (le point de vue de l’utilisateur) Serveur SSO 3 userId password Navigateur 2 4 1 Service d’authentification Consommateur d’assertions Demandeur d’attributs Autorité d’authentification Contrôleur d’accès Autorité d’attributs Ressource Référentiel utilisateurs

Avec SSO (requêtes suivantes vers le même SP) Serveur SSO Navigateur Service d’authentification Consommateur d’assertions Demandeur d’attributs Autorité d’authentification Contrôleur d’accès Autorité d’attributs Ressource Référentiel utilisateurs

Avec SSO (première requête vers un autre SP) Serveur SSO ssoId Navigateur ticket ticket userId nameId nameId Service d’authentification Consommateur d’assertions nameId Demandeur d’attributs Autorité d’authentification nameId attributes attributes Contrôleur d’accès Autorité d’attributs userId Ressource attributes Référentiel utilisateurs

Avec SSO (première requête vers un autre SP) Serveur SSO userId ssoId ticket nameId attributes Navigateur Service d’authentification Consommateur d’assertions Demandeur d’attributs Autorité d’authentification Contrôleur d’accès Autorité d’attributs Ressource Référentiel utilisateurs

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth Fonctionnement sans SSO Fonctionnement avec SSO Fonctionnement avec SSO et WAYF La délégation avec Shibboleth À propos du WAYF Les briques Shibboleth Configuration d’un fournisseur d’identités Configuration d’un fournisseur de services Relations de confiance, aspects techniques

Avec SSO et WAYF (première requête vers un SP) Serveur SSO Navigateur Service d’authentification Consommateur d’assertions WAYF Demandeur d’attributs Autorité d’authentification Contrôleur d’accès Autorité d’attributs Ressource Référentiel utilisateurs

Avec SSO et WAYF (première requête vers un SP) Serveur SSO Navigateur Service d’authentification Consommateur d’assertions WAYF Demandeur d’attributs Autorité d’authentification Contrôleur d’accès Autorité d’attributs Ressource Référentiel utilisateurs

Avec SSO et WAYF (première requête vers un SP) Serveur SSO userId password Navigateur ticket ticket ticket userId nameId nameId Service d’authentification Consommateur d’assertions WAYF nameId Demandeur d’attributs Autorité d’authentification nameId attributes attributes Contrôleur d’accès Autorité d’attributs userId Ressource attributes Référentiel utilisateurs

Avec SSO et WAYF (le point de vue de l’utilisateur) Serveur SSO 5 userId password Navigateur 4 6 3 2 1 Service d’authentification Consommateur d’assertions WAYF Demandeur d’attributs Autorité d’authentification Contrôleur d’accès Autorité d’attributs Ressource Référentiel utilisateurs

Avec SSO et WAYF (requêtes suivantes vers le même SP) Serveur SSO Navigateur Service d’authentification Consommateur d’assertions WAYF Demandeur d’attributs Autorité d’authentification Contrôleur d’accès Autorité d’attributs Ressource Référentiel utilisateurs

Avec SSO et WAYF (requêtes suivantes vers un autre SP) Serveur SSO Navigateur Service d’authentification Consommateur d’assertions WAYF Demandeur d’attributs Autorité d’authentification Contrôleur d’accès Autorité d’attributs Ressource Référentiel utilisateurs

Avec SSO et WAYF (requêtes suivantes vers un autre SP) Serveur SSO ssoId Navigateur ticket ticket userId nameId nameId Service d’authentification Consommateur d’assertions WAYF nameId Demandeur d’attributs Autorité d’authentification nameId attributes attributes Contrôleur d’accès Autorité d’attributs userId Ressource attributes Référentiel utilisateurs

Avec SSO et WAYF (requêtes suivantes vers un autre SP) Serveur SSO Navigateur 4 3 2 1 Service d’authentification Consommateur d’assertions WAYF Demandeur d’attributs Autorité d’authentification Contrôleur d’accès Autorité d’attributs Ressource Référentiel utilisateurs

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth Fonctionnement sans SSO Fonctionnement avec SSO Fonctionnement avec SSO et WAYF La délégation avec Shibboleth À propos du WAYF Les briques Shibboleth Configuration d’un fournisseur d’identités Configuration d’un fournisseur de services Relations de confiance, aspects techniques

Délégation dans un contexte multi tiers Navigateur nameId Fournisseur d’identités nameId Fournisseur de services n°1 Fournisseur de services n°2 attributes for SP#1 (encrypted) attributes for SP#2 (encrypted) attributes for SP#2

Une application : la méta recherche . . . Fournisseur de contenus 1 Fournisseur de contenus 2 Fournisseur de contenus n Portail documentaire Navigateur

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth Fonctionnement sans SSO Fonctionnement avec SSO Fonctionnement avec SSO et WAYF À propos du WAYF Les briques Shibboleth Configuration d’un fournisseur d’identités Configuration d’un fournisseur de services Relations de confiance, aspects techniques

WAYF et topologie Service critique Objectifs Disponibilité du service maximale Maintenance minimale À quoi sert un SP sans WAYF ?

WAYF et topologie établissement A SP SP SP IdP A WAYF établissement B établissement C IdP B IdP C Navigateur

WAYF et ergonomie Simplicité Ergonomie Fiabilité Le service est utilisé par des dizaines de milliers d’utilisateurs Ergonomie Les listes déroulantes sont très limitantes Soyons attractifs ! Fiabilité Le service est critique

Démonstration

Demain peut-être ? À tout de suite, Après la pause…

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth Fonctionnement sans SSO Fonctionnement avec SSO Fonctionnement avec SSO et WAYF À propos du WAYF Les briques Shibboleth Configuration d’un fournisseur d’identités Configuration d’un fournisseur de services Relations de confiance, aspects techniques

Installation des briques Shibboleth Navigateur Fournisseur d’identités Fournisseur de service Application J2EE Nécessite Tomcat Module d’authentification Pour Apache Filtre ISAPI Pour IIS Version Java Actuellement en version bêta

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth Fonctionnement sans SSO Fonctionnement avec SSO Fonctionnement avec SSO et WAYF À propos du WAYF Les briques Shibboleth Configuration d’un fournisseur d’identités Configuration d’un fournisseur de services Relations de confiance, aspects techniques

Intégration dans le SI d’un fournisseur d’identités Serveur SSO Navigateur ticket userId Service d’authentification Fournisseur de service nameId Autorité d’authentification nameId Autorité d’attributs userId attributes Référentiel utilisateurs

Connexion avec le système d’authentification Serveur SSO Navigateur Intégration Filtre J2EE Module Apache Couplage faible Champ d’entête HTTP ticket userId Service d’authentification Fournisseur de service nameId Autorité d’authentification nameId Autorité d’attributs userId attributes Référentiel utilisateurs

Connexion avec le référentiel utilisateurs Serveur SSO Navigateur Des sources multiples Bases de données Annuaires LDAP Autres sources ticket userId Service d’authentification Fournisseur de service nameId Autorité d’authentification nameId Autorité d’attributs userId attributes Référentiel utilisateurs

Contrôle de la diffusion des attributs utilisateur Serveur SSO Navigateur Attribute Release Policy Filtrage des attributs par Fournisseur de services Valeur de l’attribut ticket userId Service d’authentification Fournisseur de service nameId Autorité d’authentification nameId Autorité d’attributs ARP userId attributes Référentiel utilisateurs

Exemple d’attributs diffusés Serveur SSO Navigateur supannOrganisme eduPersonAffiliation edupersonPrincipalName supannRole mail ticket userId Fournisseur de service A Service d’authentification nameId Fournisseur de service B Autorité d’authentification nameId Autorité d’attributs ARP userId Fournisseur de service C attributes Référentiel utilisateurs

Accès anonyme à un fournisseur de services On peut donc transmettre le profil de l’utilisateur sans aucune donnée nominative Si besoin, un identifiant opaque mais persistant (targetedId) peut être fourni L’UID de l’utilisateur ou son identifiant institutionnel sont gérés comme les autres attributs

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth Fonctionnement sans SSO Fonctionnement avec SSO Fonctionnement avec SSO et WAYF À propos du WAYF Les briques Shibboleth Configuration d’un fournisseur d’identités Configuration d’un fournisseur de services Relations de confiance, aspects techniques

Intégration dans le SI d’un fournisseur de services Navigateur Transmission attributs Champs entête HTTP Type de contrôle d’accès require affiliation student@univ-x.fr require user jdupont@univ-y.fr require group etudiantsUnr Fournisseur d’identités Consommateur d’assertions Demandeur d’attributs attributes Contrôleur d’accès Ressource

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth Fonctionnement sans SSO Fonctionnement avec SSO Fonctionnement avec SSO et WAYF À propos du WAYF Les briques Shibboleth Configuration d’un fournisseur d’identités Configuration d’un fournisseur de services Relations de confiance, aspects techniques

Confiance du point de vue du fournisseur de services Navigateur nameId Assertion SAML signée X.509 Vérifications Intégrité assertion Identité émetteur Service d’authentification Consommateur d’assertions Demandeur d’attributs Autorité d’authentification Contrôleur d’accès Autorité d’attributs Ressource

Confiance du point de vue du fournisseur d’identités Authentification SOAP sur HTTPS Autorisation Navigateur nameId Service d’authentification Consommateur d’assertions Demandeur d’attributs Autorité d’authentification nameId attributes Contrôleur d’accès Autorité d’attributs Ressource

Les méta données Concrétisent les relations de confiance au sein du cercle de confiance Liste des fournisseurs d’identités et des fournisseurs de services Certificat, Identifiant, URL, Organisme, Contacts Synchronisation au niveau de chaque site

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth La fédération pilote du CRU, illustration de la mise en place d’une fédération d’identités Relations de confiance La fédération pilote du CRU Nommage et sémantique des attributs Déclaration CNIL et respect de la vie privée Rejoindre la fédération du CRU Périmètre

Schématisation d’une fédération Université A Université B Université E Ressources documentaires Application métier Université D Université C Cours en ligne

Relations entre fournisseurs Un fournisseur d’identités choisit à quels fournisseurs de services ses utilisateurs accèdent Un fournisseur de services choisit à quels fournisseurs d’identités il ouvre l’accès La fédération = niveau de confiance minimal partagé entre les fournisseurs

Confiance accordée par un fournisseur de services Qualité de l’authentification des utilisateurs Qualité des attributs propagés Disponibilité des services d’authentification et de propagation d’attributs

Confiance accordée par un fournisseur d’identités Les attributs propagés ne servent qu’aux usages initialement prévus Shibboleth permet l’accès authentifié mais anonyme

Formalisation des relations de confiance But : établir un niveau de confiance minimal Exemples d’engagements pour un fournisseur d’identités Disponibilité et sécurisation du service d’authentification Bon approvisionnement et mise à jour du référentiel … Plusieurs formes possibles Respect de bonnes pratiques Engagement contractuel

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth La fédération pilote du CRU, illustration de la mise en place d’une fédération d’identités Relations de confiance La fédération pilote du CRU Nommage et sémantique des attributs Déclaration CNIL et respect de la vie privée Rejoindre la fédération du CRU Périmètre

Historique 2003 2004 2005 2002 2006 USA : Shibboleth, fédération Fédération pilote du CRU Suisse : fédération 2003 2004 2005 2002 2006 France : SUPANN, ENT, SSO, UNR Premiers services CRU : étude Shibboleth et Liberty Alliance

Les acteurs Fournisseurs d’identités Fournisseurs de services Le CRU Établissements d’enseignement supérieur Fournisseurs de services Enseignement supérieur et recherche, autres administrations, prestataires privés Le CRU

Travaux du CRU au sein de la fédération Nommage et la sémantique communs des attributs Assistance et conseil aux fournisseurs Distribution des méta données Formaliser les relations de confiance

Relations de confiance Simple engagement à respecter des bonnes pratiques Formalisation légère Signature d’une convention Documents publiés en janvier 2006 Susceptibles d’évoluer

C’est un service technique Aspects non couverts : administratifs, financiers, fonctionnels, etc. La fédération du CRU n’est pas signataire d’un contrat qui peut lier un fournisseur de services à des fournisseurs d’identités

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth La fédération pilote du CRU, illustration de la mise en place d’une fédération d’identités Relations de confiance La fédération pilote du CRU Nommage et sémantique des attributs Déclaration CNIL et respect de la vie privée Rejoindre la fédération du CRU Périmètre

Besoin d’un nommage commun Etablissement A Etablissement B Etablissement C Discipline disc. Discipline filière Discipline AUTORISATION BASÉE SUR LA DISCIPLINE DE L’ÉTUDIANT Cours en ligne réservé aux étudiants en mathématiques

Besoin d’une sémantique commune Etablissement A Etablissement B Etablissement C Discipline = mathématiques Discipline = maths Discipline = Sc. Mathématiques AUTORISATION BASÉE SUR LA DISCIPLINE DE L’ÉTUDIANT Cours en ligne réservé aux étudiants en mathématiques

Nommage et sémantique communs des attributs Les fournisseurs de service peuvent contrôler l’accès avec les attributs propagés par les fournisseurs d’identités Pour que ce mécanisme soit efficace avec de multiples fournisseurs d’identités, les attributs propagés qu’ils propagent doivent être nommés de façon identique et suivre la même sémantique

Attributs au sein de la fédération du CRU Base d’attributs : SUPANN sn, mail, eduPersonPrincipalName, eduPersonAffiliation, supannOrganisme… Évolution en fonction des besoins des fournisseurs de services

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth La fédération pilote du CRU, illustration de la mise en place d’une fédération d’identités Relations de confiance La fédération pilote du CRU Nommage et sémantique des attributs Déclaration CNIL et respect de la vie privée Rejoindre la fédération du CRU Périmètre

Déclaration CNIL pour le référentiel Diffusion d’attributs hors de l’établissement : nouvelle déclaration CNIL ? Contacts avec la CNIL en cours Cette diffusion est bien encadrée Sous le contrôle de l’établissement En fonction du fournisseur de services Anonymisation possible Uniquement lors d’une session utilisateur

Respect de la vie privée (privacy) Un utilisateur peut refuser la propagation d’attributs le concernant vers un tiers (réglementation européenne) Contraintes ergonomiques et d’usages fortes Contrôle au niveau d’une interface dédiée Plutôt que dans Shibboleth

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth La fédération pilote du CRU, illustration de la mise en place d’une fédération d’identités Relations de confiance La fédération pilote du CRU Nommage et sémantique des attributs Déclaration CNIL et respect de la vie privée Rejoindre la fédération pilote du CRU Périmètre

Pour un fournisseur d’identités Mon établissement peut-il respecter les bonnes pratiques ? Pré requis Un service central d’authentification Un ou plusieurs référentiels avec nommage et sémantique corrects Démarche Tester la mise en place technique avec la fédération de test S’inscrire au sein de la fédération pilote

Pour un fournisseur de services (1) Utilisateurs concernés Appartiennent-ils tous à un établissement d’enseignement supérieur ? Ces établissements sont-ils dans la fédération ? Si non, une solution : le fournisseur d’identités virtuel

Fournisseur d’identités virtuel IdP virtuel Université A Université A Université B Université B Université E W A Y F Application métier Université D Université C

Pour un fournisseur de services (2) Utilisation d’attributs propagés ? Vérifier que ces attributs existent dans la fédération Utilisations possibles : Contrôle d’accès Privilèges applicatifs Personnalisation « Shibboliser » l’application Blackboard, JSTOR, Moodle, OCLC, OLAT, Sympa, TWiki, WebCT… Démarche Tester la mise en place technique avec la fédération de test S’inscrire au sein de la fédération pilote

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth La fédération pilote du CRU, illustration de la mise en place d’une fédération d’identités Relations de confiance La fédération pilote du CRU Nommage et sémantique des attributs Déclaration CNIL et respect de la vie privée Rejoindre la fédération du CRU Périmètre

Faut-il plusieurs fédérations ? Université A Université B Université E Ressources documentaires Application métier Université D Université C Application UNR Cours en ligne

Coexistence de fédérations Pas de problème technique Shibboleth permet à un fournisseur d’appartenir à plusieurs fédérations Organisationnel Simple pour un fournisseur de services Plus compliqué pour un fournisseur d’identités Surcharge administrative Multiplication des engagements de confiance Plusieurs jeux d’attributs à gérer Fédération spécifique si besoin de confiance spécifique

Du point de vue de l’utilisateur… C’est le WAYF qui concrétise la notion de fédération Il peut (doit ?) être placé au niveau d’un fournisseur de services Liste de fournisseurs d’identités restreinte Visuel adapté au contexte (par ex. UNR) On simule ainsi des « fédérations virtuelles »

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth La fédération pilote du CRU, illustration de la mise en place d’une fédération d’identités Retours d’expérience et perspectives SWITCHaai, fédération académique Suisse Projets en France Perspectives

SWITCHaai En production depuis 2003 10 fournisseurs d’identités, 10 000 utilisateurs actifs Ressources Plates-formes d’enseignement à distance (OLAT, WebCT, Moddle) Documentations électroniques (Elsevier, SpringerLink) via EZproxy / Shibboleth Retour d’expérience très positif

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth La fédération pilote du CRU, illustration de la mise en place d’une fédération d’identités Retours d’expérience et perspectives SWITCHaai, fédération académique Suisse Projets en France Perspectives

Projets en France Région bordelaise UNR Bretagne Accès WI-FI inter-établissements UNR Bretagne Plate-forme d’enseignement à distance Moodle Candisup : application d’inscription en première année d’enseignement supérieur Expérimentation Couperin Accès à des fournisseurs de contenu électronique

Accès aux fournisseurs de contenu Actuellement par adresse IP Nomadisme impossible sauf proxy Contrôle d’accès impossible Pas d'identification Pas de quantification des accès Intérêt de Shibboleth Nomadisme permis Contrôle d’accès basé sur les attributs Anonymisation possible au niveau du fournisseur de services Identification et quantification possibles au niveau du fournisseur d’identités

Expérimentation Couperin Objectifs Améliorer et standardiser l’accès aux documentations électroniques Valider l’intérêt de Shibboleth, retour d’expérience 12 établissements y participent Un ou deux fournisseurs de contenus : Elsevier, EBSCO Expérimentation au premier trimestre 2006

Perspectives accès aux documentations électroniques Les fournisseurs de contenu sont en train d’adopter Shibboleth La généralisation de Shibboleth permettra L’accès à des ressources documentaires gérées par les établissements Une recherche multi fournisseurs via un portail documentaire

Plan Pourquoi une fédération ? Les solutions techniques Le système Shibboleth La fédération pilote du CRU, illustration de la mise en place d’une fédération d’identités Retours d’expérience et perspectives SWITCHaai, fédération académique Suisse Projets en France Perspectives

Perspectives Délégation multi-tiers Grilles de calcul : GridShib Intégrer Globus Toolkit et Shibboleth http://gridshib.globus.org

Ce qu’il faut retenir Ça marche, dès maintenant Ce n’est pas si compliqué Pour faire une fédération, il faut être plusieurs ;-)

CRU NEEDS YOU! http://federation.cru.fr