Quand on achète de la documentation électronique, on fait en sorte qu’elle soit accessible aussi bien en local (=sur les campus) qu’à distance. On utilise pour ce faire un serveur spécifique, un (reverse) proxy. Toutes les URLs des ressources sont enregistrées sur le serveur, afin que l’utilisateur final puisse, de façon transparente, y accéder comme s’il était connecté depuis le réseau local. En gros, le serveur proxy est la porte d’entrée obligatoire pour tous les accès distants. Sauf que, depuis plusieurs années maintenant, se développent d’autres systèmes d’authentification : OpenID entre autres dans le web commercial, Shibboleth dans le monde de la recherche et de l’enseignement. L’idée (en très très simplifié), c’est que l’authentification de la personne qui se connecte est en quelque sorte « déportée » : l’utilisateur peut se connecter directement à la ressource, il lui suffit d’entrer ses identifiants (la correspondance se fait au moyen d' »attributs » échangés entre la fédération d’identité Education-Recherche, qui rassemble, en France, les universités et grandes écoles, et les fournisseurs de services, ie les éditeurs, pour ce qui nous intéresse). Plus besoin de passer par le proxy. L’intérêt, c’est que le bibliothécaire s’affranchit de la maintenance des URLs de chaque ressource, à modifier à chaque changement de plateforme des éditeurs (au mois un par an ces dernières années) dans le paramétrage du serveur proxy. Le problème, c’est que toutes les ressources ne sont pas compatibles Shibboleth : il faut donc quand même garder un serveur proxy.
La question que je me pose – et que je vous pose – c’est : comment signaler ces ressources ? On a souvent le cas de pages de connexion via Shibboleth en anglais, dans lesquelles il est difficile de trouver, si on n’est pas averti, la « french federation », puis son établissement dans la liste qui s’affiche… Je ne dis pas que c’est compliqué, je dis que ce n’est pas naturel, et que ça nécessite un minimum d’explications.
Et j’aimerai savoir comment c’est géré dans les autres universités, où si d’autres se posent aussi ce genre de questions.
[Photo : D.H. Parks]
*mais non, je rigole
Licence
Ce(tte) œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution 3.0 France.
Marlène's corner 
Mêmes questions à Paris5, sachant que le service informatique est aussi favorable au tout Shibboleth.
Notre proxy est BiblioPAM et la société qui nous le gère, Alixen, nous avait promis il y a 2 ans de réfléchir à une solution qui intégrerait les ressources « Shibbolethisables ». Sans nouvelles depuis.
A Toulouse 3, nous disposons comme à Paris 5 du reverse proxy BiblioPAM. Comme du côté de la Lorraine, nous ne faisons pas de publicité pour Shibboleth, parce que:
1) il est plus laborieux de s’identifier à Shibboleth (il faut répéter l’opération à chaque changement de plateforme) que de s’authentifier sur le reverse proxy (1 seule authentification pour toute )
2) 99% de nos ressources électroniques sont accessibles à distance via le reverse proxy, ce qui n’est pas le cas avec Shibboleth.
Ce qui permettrait de simplifier et donc de doper l’utilisation des accès distants via BiblioPAM, ce serait un dispositif technique qui reconnaîtrait automatiquement la provenance de l’IP de l’usager, avec l’alternative suivante:
– IP du campus –> accès local
– IP extérieure au campus –> ouverture automatique d’une fenêtre d’authentification (type CAS de l’établissement) pour se connecter au reverse proxy.
Savez-vous si une elle solution existe ?
BiblioPAM le permet :
Dans l’onglet « configuration » vous remplissez les « Adresses IP internes » (en bas de la page). Il ne vous reste plus qu’à signaler vos url avec le « fork », par exemple https://proxy.univ-paris5.fr/fork?http://www.adresse.de/ma_ressource
Si vous cochez la case « Ne demander aucune authentification pour les adresses IP internes » ça veut dire que vous n’utilisez plus le fork, que tout le monde passe par le proxy, mais simplement les IP interne ne s’identifient pas.
Merci beaucoup pour le tuyau !
On a 30000 étudiants. Est-ce qu’il n’y a pas un risque de faire sauter le serveur si on fait tout passer par le reverse proxy?
Et puis avec Shibboleth autre problème:
dès qu’on passe par une liste A-Z pour les e-revues ou un catalogue de bibliothèque pour les e-books, on ne trouve pas le lien accès distants (il faut retourner dans la liste des fédérations, choisir son établissement etc…), alors qu’avec eZproxy, toutes les urls renvoient vers les bons accès sur place ou à distance selon les cas et directement à la page de la revue ad hoc.
Alors la citabilité de l’url et les reparamétrages en cours d’années ne pèsent pas bien lourd face à la masse des utilisateurs perdus qu’il faut renseigner.
Mais je ne désespère pas de trouver meilleure solution… :-).
Ouè et bien moi je défend l’accès shibboleth tant que tous les usagers des bibliothèques ne sauront pas utiliser un bookmarklet pour se connecter à la volée ou n’auront pas installé un plugin adéquat (fourni par la bib), ne connaîtrons pas l’adresse du proxy pour leur gestionnaire bibliographique, etc. Et comme je suis un presque bibliothécaire 😉 je suis très attaché à ce que des URL citables soient utilisées. Vous le savez sans doute mais lorsque que l’on utilise EZproxy l’URL est réécrite et ne correspond plus d’une institution à l’autre à l’adresse d’origine !
Pour répondre plus directement, je me pose les mêmes questions que Marlène.
Je sais ce que je ne veux pas : qu’un usager trouve une ressource sur le web et ne sache pas comment s’authentifier pour l’accès distant, qu’on lui dise d’aller dans l’ENT pour se connecter, qu’il soit obligé d’aller sur le site de la bibliothèque pour trouver le lien proxifié, qu’il ne sache pas ce qu’il fait réellement.
Je réfléchis (à plusieurs) à ce que je veux…
Avec Ezproxy, il n’y aucun paramétrage côté client. Et côté gestion bibliographique, Zotero détecte tout seul comme un grand l’accès proxy…
Concernant la question des URLs « citables », je ne comprend pas l’intérêt. L’usager veut le lien, pas l’URL. D’autant plus que les URLs « natives » (ie hors proxy) ne sont pas toujours très simples, cf Factiva par exemple.
A Clermont, on privilégie l’accès via EZproxy aussi, même si le CRRI préférerait la solution shibboleth. Cela dit, on a quand même déclaré nos universités auprès des éditeurs qui proposent shibboleth de manière à laisser le choix à certains enseignants-chercheurs qui ne consultent bien souvent qu’une ou deux plateformes (et qu’ils peuvent donc laisser en « favori ») tout en bénéficiant des services du résolveur de liens grâce au ticket CAS en cours.
Pareil ici, exit Shibboleth, vive ez proxy : identification directement à l’accès à la ressource sur l’interface CAS de l’université. une seule méthode d’accès. Point barre. Fini les listes déroulantes interminables dans lesquelles l’établissement n’est jamais nommé de la même façon.
De plus, ça permet d’avoir la main sur ses accès distants, et de ne pas être dépendant du CRI pour les mettre en place.
Oui, en effet, le problème, c’est la pluralité des modes d’accès. Pour le moment, du côté de Clermont, on n’a pas fait de pub pour les accès shibboleth. Mais à l’occasion, on les signale aux enseignants-chercheurs qui utilisent de préférence une ou deux plateformes et qui peuvent ainsi mettre les url en favori. Le CRRI est plutôt favorable au tout shibboleth, mais tant que certains éditeurs ne proposent pas ce mode d’accès…
Et bien du côté de la Lorraine nous allons travailler sur l’exploitations des logs d’EZ Proxy pour en tirer des stats. On va donc faire converger tous les accès (locaux et distants) par EZ Proxy afin d’avoir des données aussi complètes que possible. Et, du coup, pas de pub sur les accès Shibboleth directement sur les plateformes éditeurs.