Retour des fournisseurs d`identités

Compte­rendu de l'expérimentation Couperin­SDB­ABES­CRU sur l'utilisation de Shibboleth
Compte­rendu de l'expérimentation Couperin­SDB­ABES­CRU sur l'utilisation de Shibboleth pour l'accès à des ressources éditoriales en ligne
Le consortium Couperin, la Sous Direction des Bibliothèques du MENESR, l'ABES et le CRU ont organisé une expérimentation pour évaluer l'intérêt de l'utilisation de Shibboleth pour l'accès à des ressources éditoriales en ligne. Deux ressources en ligne, le portail Sudoc de l'ABES et le portail ScienceDirect d'Elsevier, ont été rendues accessibles à douze établissements d'enseignement supérieur participants (la liste est en annexe 1) via la fédération du CRU (technologie Shibboleth).
Cette expérimentation a débuté en mars 2006 et s'est terminé en décembre 2006. L'objectif était d'évaluer Shibboleth en situation « réelle » (accès par des utilisateurs finaux des établissements à des services en production), notamment pour connaître son 1) intérêt par rapport à d'autres solutions déjà mises en place dans les établissements pour l'accès à des ressources éditoriales, 2) les efforts à fournir pour l'installer et le configurer, 3) sa capacité à s'intégrer dans un système d'information, l'expérience concrète d'utilisation.
Une description générale de Shibboleth et de la fédération du CRU est donnée en annexe 2, ainsi que l'intérêt de Shibboleth pour des fournisseurs de ressources, les établissements d'enseignement supérieur et les utilisateurs.
Retour des fournisseurs d'identités
Déploiement de la brique fournisseur d'identités
Le travail à réaliser pour ces établissements était l'installation de la brique technique Shibboleth fournisseur d'identités et l'inscription à la fédération du CRU. Neuf établissements sur les douze participants ont réalisé ceci. Tous ces établissements avaient déjà un annuaire, un SSO et un ENT (en production ou en déploiement).
La majorité des établissements a installé et configuré la brique Shibboleth en quelques jours. Pour deux établissements cela a été beaucoup plus long, car l'environnement logiciel (Tomcat, Apache, JAVA) était plus ou moins nouveau. La complexité de l'architecture du produit a été souligné par beaucoup. L'installation et la configuration de Shibboleth apparaissent à la portée des établissements, surtout quand ils ont déjà acquis des compétences sur les technologies pré requises, par exemple en ayant déjà déployé un ENT et un SSO.
Accès effectif aux ressources via Shibboleth
Six établissements candidats proposent à leurs usagers un accès via Shibboleth au portail ScienceDirect. Trois ne le font pas soit par manque de temps pour mettre en production cet accès, Comité Réseau des Universités – février 2007
Page 1
Compte­rendu de l'expérimentation Couperin­SDB­ABES­CRU sur l'utilisation de Shibboleth
soit car la solution actuelle suffit. Tous les établissements ont conservé les méthodes d'accès pré existantes (principalement par IP ou reverse proxy) sauf un établissement qui a abandonné à cette occasion l'accès par login. En comparaison avec ces méthodes, le nombre d'accès via Shibboleth reste pour le moment anecdotique.
Quatre établissements candidats proposent à leurs usagers un accès via Shibboleth au portail Sudoc. Les autres ne le font pas, soit par manque de temps pour mettre en production ce service, soit car la solution actuelle suffit, soit à cause de problèmes techniques.
Problème ergonomique du WAYF
Le WAYF est une brique logicielle de l'architecture Shibboleth qui permet à un fournisseur de services d'orienter un utilisateur vers son établissement de rattachement afin que l'utilisateur s'y authentifie. En général un WAYF se matérialise sous la forme d'un menu déroulant listant des établissements, et où l'utilisateur doit sélectionner son établissement avant de pouvoir accéder au service.
Le passage par le WAYF pour accéder aux ressources via Shibboleth pose un problème ergonomique majeur. En effet l'usager accède à une ressource extérieure publiée depuis son ENT (où il s'est déjà authentifié) mais doit ensuite sélectionner son établissement dans un menu déroulant avant de pouvoir accéder effectivement à la ressource. C'est une étape qui lui apparaît totalement inutile, car il lui semble que la ressource devrait savoir de quel établissement il vient puisqu'il arrive depuis son ENT. Ce passage par le WAYF est une régression par rapport à d'autres méthodes d'accès.
Ce problème ergonomique du WAYF est désormais résolu, il n'est plus nécessaire de passer par le WAYF quand on accède à une ressource extérieure depuis un ENT. Pour cela il suffit d'utiliser une URL particulière d'accès à la ressource. Le gestionnaire d'un ENT peut consulter le site du CRU pour obtenir cette URL1.
Shibboleth et extraction de statistiques d'utilisation des ressources
L'expérimentation a mis à jour l'inadéquation de Shibboleth pour l'extraction par un établissement de statistiques sur l'utilisation des ressources. En effet, contrairement à un reverse proxy, les accès à une ressource extérieure via Shibboleth ne transitent par l'établissement que lors de l'accès initial de l'usager. Tout son parcours subséquent sur le site de la ressource a lieu directement entre son navigateur et le site de la ressource, l'établissement n'a donc aucun moyen de connaître les pages qu'il a consultées.
Cette limitation de Shibboleth est intrinsèque à son architecture distribuée, il n'y a pas de solution à ce problème.
1 Voir http://www.cru.fr/wiki/faq/federation/questions_reponses_pour_les_wayf#court­
circuiter_le_wayf Comité Réseau des Universités – février 2007
Page 2
Compte­rendu de l'expérimentation Couperin­SDB­ABES­CRU sur l'utilisation de Shibboleth
Shibboleth en comparaison avec un système de reverse proxy
Les systèmes de reverse proxy sont déployés dans les établissements, notamment pour gérer l'accès à des ressources éditoriales en ligne. Pour l'usager Shibboleth n'apporte pas d'avantages par rapport au reverse proxy quand ce dernier autorise déjà un accès nomade aux ressources (c'est généralement le cas quand il est intégré dans l'ENT par exemple). Pour le gestionnaire de ressources actuellement il reste plus simple de contrôler l'accès sur la base d'une adresse IP de reverse proxy ou d'un login/mot de passe que d'adapter son service à Shibboleth qui nécessite un investissement certain. Cependant, si le fournisseur investit sur Shibboleth, l'utilisation de Shibboleth lui apportera des gains : possibilité de reconnaître un usager d'une connexion à l'autre (même s'il est anonyme), personnalisation et contrôle d'accès en fonction d'attributs de l'usager, plus besoin de maintenir une liste d'adresses IP autorisées ou un système de login/mot de passe.
Pour l'établissement le reverse proxy est difficile à maintenir, du fait de la variété des méthodes d'accès aux ressources en ligne. Shibboleth au contraire offre une méthode standardisée pour l'accès à des ressources extérieures, et peut être utilisé pour l'accès à tout type de ressources (éditoriales, pédagogiques, métiers). Contrairement à Shibboleth, le reverse proxy permet d'analyser le parcours des usages dans les ressources et ainsi potentiellement d'extraire des statistiques d'usage.
Shibboleth est encore peu adopté par les éditeurs, ce qui limite son intérêt actuel pour l'accès aux ressources éditoriales. Il n'apporte pas d'avantages fonctionnels par rapport aux besoins exprimés actuellement pour le contrôle d'accès à des ressources éditoriales en ligne. Cependant Shibboleth offre une perspective d'une standardisation des modes d'accès aux ressources et des possibilités de contrôle d'accès en fonction du profil des usagers.
Retour des fournisseurs de services
Deux fournisseurs de services ont participé à l'expérimentation : Elsevier avec son portail ScienceDirect et l'ABES avec son portail Sudoc. ScienceDirect est devenu accessible en septembre 2006 en tant que fournisseur de services dans la fédération du CRU. Il était déjà rendu compatible avec Shibboleth pour les besoins de la fédération d'identités académique américaine. Le seul travail a donc été d'adapter sa configuration pour les accès via la fédération du CRU. ScienceDirect ne demande aucun attribut usager à l'établissement pour l'accès, il utilise seulement la fonctionnalité de délégation d'authentification. Elsevier a présenté les intérêts qu'il trouve à Shibboleth dans plusieurs conférences2.
L'ABES a inscrit son portail Sudoc dans la fédération du CRU en tant fournisseur de services en août 2006. L'installation de la brique Shibboleth a duré deux semaines, le travail pour rendre compatible le portail a pris deux autres semaines et l'installation de la brique WAYF a pris trois jours. Le tout se faisait dans un environnement Windows, pour lequel Shibboleth dispose de moins 2 Une présentation est par exemple disponible sur http://seminar.deff.dk/presentations/devries.pdf Comité Réseau des Universités – février 2007
Page 3
Compte­rendu de l'expérimentation Couperin­SDB­ABES­CRU sur l'utilisation de Shibboleth
de documentations. Ceci a compliqué le travail, d'autant plus que les concepts de Shibboleth étaient nouveaux pour l'ABES (SAML, SSO, etc.).
La charge de travail pour rendre compatible une application avec Shibboleth est beaucoup plus important que pour intégrer la fédération en tant que fournisseur d'identités. Il faut en effet adapter une application pour qu'elle ne repose plus (seulement) sur son propre système d'authentification, mais qu'elle soit capable de s'appuyer sur Shibboleth pour déléguer l'authentification et éventuellement récupérer des attributs sur l'usager.
Intérêt de la délégation d'authentification
Les deux fournisseurs de services soulignent le grand intérêt de déléguer l'authentification aux fournisseurs d'identités. Ils se déchargent ainsi d'un travail fastidieux et l'accès au service pour les usagers est simplifié, ce qui favorise son utilisation.
Utilisation des attributs pour les fournisseurs de services
Le portail ScienceDirect n'utilise aucun attribut issu des référentiels d'établissements.
Au contraire l'ABES en utilise plusieurs et souligne la problématique de l'approvisionnement d'attributs (ici SupannRole avec la valeur RESP­DOC­ELEC) dans les référentiels établissement. Une majorité d'établissements n'avaient pas défini ce rôle de responsables de documentation électronique dans leur annuaire. L'alimentation et la mise à jour de ces attributs par les établissement sont également importants, car le fournisseur de services se repose sur eux pour réaliser le contrôle d'accès et attribuer des privilèges différenciés aux usagers.
La structuration du réseau Sudoc repose sur les attributs ILN/RCR. Or ils sont inconnus des annuaires des établissements. L'ABES a donc dû faire une table de correspondance entre la nomenclature ILN/RCR et les codes UAI remontés par l'attribut supannOrganisme. Cependant, outre la lourdeur du maintien de cette table, il n'y a pas de correspondance univoque, les codes UAI ne recouvrent pas toutes les spécificités des bibliothèques.
Ces problèmes rencontrés illustrent les difficultés organisationnelles à exploiter des attributs non triviaux (autres que le nom, prénom, email...) issus des référentiels des établissements pour le contrôle d'accès et l'attribution de privilèges dans un fournisseur de services. La complétude et l'homogénéisation du nommage et des nomenclatures des référentiels des établissements sont complexes, surtout pour les besoins de services qui ont une échelle nationale.
Conclusion
La quasi totalité des établissements qui ont installé la brique Shibboleth fournisseur d'identités font un bilan positif de cette expérimentation. Pour l'accès distant à des ressources éditoriales Shibboleth ne remplace pas dans un établissement d'autres solutions, par exemple un reverse proxy, notamment parce peu d'éditeurs ont adopté Shibboleth pour le moment. L'effort actuel de communication sur Shibboleth auprès des éditeurs doit donc être poursuivi. Comité Réseau des Universités – février 2007
Page 4
Compte­rendu de l'expérimentation Couperin­SDB­ABES­CRU sur l'utilisation de Shibboleth
Cependant devenir fournisseur d'identités a permis aux établissements participants de s'approprier cette technologie applicable pour d'autres types d'usages. Une majorité des participants ont l'intention d'utiliser Shibboleth pour l'accès à des ressources documentaires, pédagogiques, métiers, etc., principalement à l'échelle régionale dans le cadre d'UNR ou de PRES. À cette échelle il est en effet envisageable de rapidement mettre en place un fournisseur d'identités par établissement ; la problématique de normalisation des attributs est également plus simple à traiter à l'échelle régionale .
Les fournisseurs de services participants font également un bon bilan de l'utilisation de Shibboleth. Ils soulignent l'effort pour adapter leur application, l'aspect organisationnel (articuler des aspects métiers spécifiques à un contexte de fédération générique) primant sur l'aspect technique. L'ABES compte généraliser le principe d'authentification fédérée aux applications nationales qu'elle gère.
Références
Agence Bibliographique de l'Enseignement Supérieur, www.abes.fr Comité Réseau des Universités, www.cru.fr Consortium Couperin, www.couperin.org
Sous­direction des bibliothèques et de l'information scientifique, www.sup.adc.education.fr/bib/
Annexe 1 : liste des établissements participants en tant que fournisseurs d'identités
●
IEP de Grenoble
●
INSA de Lyon
●
Université de Bordeaux 1
●
Université de Limoges
●
Université de Lyon 1
●
Université de Nancy 1
●
Université de Nancy 2
●
Université Nice
●
Université de Paris 5
●
Université de Pau
●
Université de Rennes 1
●
Université de Valenciennes
Comité Réseau des Universités – février 2007
Page 5
Compte­rendu de l'expérimentation Couperin­SDB­ABES­CRU sur l'utilisation de Shibboleth
Annexe 2 : description et intérêts de Shibboleth et la fédération
Shibboleth est une norme et un produit conçus pour propager l'authentification3 réalisée au sein d'un établissement (par exemple sur le SSO d'un ENT) vers un site extérieur à l'établissement et qui propose des ressources numériques aux personnes de cet organisme. Shibboleth transmet au site extérieur simplement la preuve (sous forme informatique) que la personne s'est correctement authentifiée dans son établissement, elle ne transmet pas son identifiant et son mot de passe. Une étape ultérieure optionnelle permet au site extérieur d'obtenir, avec l'accord de l'établissement, des informations supplémentaires sur l'utilisateur.
L'établissement est appelée fournisseur d'identités, car c'est lui qui gère des utilisateurs (étudiants, personnels, chercheurs, etc.) et leur fournit un compte et un moyen de s'authentifier. Le site extérieur est appelé fournisseur de services, car il propose une ressource numérique à des utilisateurs. Un fournisseur d'identités doit installer une brique technique Shibboleth, un fournisseur de services aussi. Outre l'installation de ces briques techniques, les fournisseurs d'identités et de services voulant coopérer doivent accepter de suivre des règles organisationnelles communes. L'engagement à suivre ces règles se traduit par la participation à une fédération d'identités.
La fédération du CRU regroupe des fournisseurs d'identités qui sont des établissements d'enseignement supérieur français. Elle intègre également des fournisseurs de services, qui peuvent être également des établissement d'enseignement supérieur, mais aussi tout autre organisme (institution publique, entreprise privée, française ou étrangère) qui gère un ou des ressources en ligne d'intérêt pour les membres (étudiants, personnels, chercheurs, etc.) des fournisseurs d'identités.
Les intérêts de Shibboleth et d'une fédération d'identités sont :
●
●
●
pour les fournisseurs de services (ici l'ABES et Elsevier) : Shibboleth leur permet de s'affranchir d'un système d'authentification pour leur portail, en se reposant sur celui des pour les fournisseurs d'identités. Ils peuvent aussi obtenir de façon contrôlée et sécurisée des informations sur le profil des utilisateurs, afin de contrôler l'accès à leurs ressources ou donner des privilèges applicatifs différenciés selon le profil de l'utilisateur.
pour les fournisseurs d'identités (ici les établissements d'enseignement supérieur) : Shibboleth est une méthode standard pour contrôler l'accès à une ressource extérieure. Elle évite à l'établissement de mettre en place un système spécifique pour chaque fournisseur de services. Elle permet à un établissement de diffuser de façon contrôlée des informations nominatives ou non aux fournisseurs de services.
pour les utilisateurs (ici les étudiants et chercheurs) : pour accéder à une ressource ils s'authentifient sur le SSO de leur établissement. Ils n'ont pas à se souvenir d'un nouvel 3 L'authentification est la vérification qu'une personne est bien celle qu'elle prétend être. Généralement une personne s'authentifie en saisissant un identifiant (login) et un mot de passe. Comité Réseau des Universités – février 2007
Page 6
Compte­rendu de l'expérimentation Couperin­SDB­ABES­CRU sur l'utilisation de Shibboleth
identifiant et mot de passe. Les informations personnelles les concernant restent sous le contrôle de leur établissement de rattachement qui peut les délivrer aux fournisseurs de services.
Le site http://federation.cru.fr détaille le fonctionnement de Shibboleth et de la fédération du CRU.
Comité Réseau des Universités – février 2007
Page 7