FLASH INFORMATIQUE FI



Tequila aime Shibboleth




Claude LECOMMANDEUR


La problématique de l’authentification des utilisateurs et du contrôle de l’accès aux ressources est une composante fondamentale de la sécurité informatique. Elle commence à être plus ou moins résolue localement aux institutions, mais le nomadisme grandissant oblige à raisonner au-delà des frontières du campus et même du pays. En effet, d’un côté l’EPFL sécurise l’accès à ses ressources, mais il lui faut en même temps les ouvrir à des chercheurs et étudiants appartenant à d’autres organisations. Réciproquement nos étudiants et chercheurs ont besoin d’accéder à des ressources sur d’autres campus dont l’accès est contrôlé.
Ceci ne peut se faire qu’en travaillant avec les institutions partenaires, suisses et européennes. Plusieurs technologies peuvent cohabiter à condition que soit clairement défini, qui est responsable de fournir les identités, selon quel mode, à qui, etc.
SWITCH (réseau des universités et hautes écoles suisses) a choisi l’outil Shibboleth pour développer son infrastructure d’Authentification et d’Autorisation fédérative (AAI). L’EPFL utilise Tequila pour les applications sécurisées, il était donc nécessaire de faire parler les deux technologies qui travailleront de façon complémentaire : quand une application EPFL (tequilifiée) devra s’ouvrir à des utilisateurs d’une institution de la fédération SWITCH-Shibboleth, il lui suffira de le préciser dans les règles du client Tequila. Réciproquement nos utilisateurs pourront accéder à toute application shibbolethisée les acceptant.

Introduction

Tequila et Shibboleth sont 2 outils d’authentification et de contrôle d’accès ayant des fonctionnalités similaires. Tequila a été développé à l’EPFL alors que Shibboleth est un produit du projet Internet2. Ces 2 outils permettent d’authentifier des utilisateurs d’applications Web, de contrôler l’accès de ces utilisateurs ainsi que d’obtenir des informations sur ces mêmes utilisateurs, et ceci dans un environnement fédéré.
Un environnement fédéré est un ensemble d’organisations qui se mettent d’accord pour donner des accès à leurs applications aux utilisateurs des autres organisations partenaires. Un utilisateur peut être défini comme un username, un moyen d’authentification (souvent un mot de passe) et un certain nombre d’attributs annexes (nom, prénom, statut, ...). La gestion de ces utilisateurs est faite dans leur organisation de rattachement qui est normalement unique, bien qu’un utilisateur puisse appartenir à plusieurs organisations.
Quand une application Web sécurisée veut authentifier un utilisateur, deux cas peuvent se présenter :

  • l’utilisateur appartient à la même organisation que l’application Web, l’authentification est redirigée vers le serveur d’authentification local ;
  • l’utilisateur appartient à une autre organisation membre de la même fédération, l’authentification est redirigée vers le serveur de cette organisation.

De cette manière, l’organisation, mère d’un utilisateur, et elle seule, a les moyens de l’authentifier (pas de divulgation intempestive de mot de passe) et de donner des informations qui le concernent. Les informations personnelles sont gérées au plus près de l’utilisateur.

Comparaison des architectures

Shibboleth

Dans l’architecture Shibboleth, il y a 4 acteurs. Le navigateur de l’utilisateur, le fournisseur de ressources (Application Provider ou AP), le fournisseur d’identités (Identity Provider ou IdP) et le WAYF (Where Are You From).

AP : fournisseur de ressources

Application Web sécurisée. Elle désire authentifier ses utilisateurs et ne fournir ses ressources qu’à des utilisateurs triés sur le volet.

IdP : fournisseur d’identités

Il connaît tous les utilisateurs d’une organisation, sait les authentifier et peut fournir des attributs associés à ces utilisateurs. Seul le fournisseur d’identité d’une organisation peut faire ceci pour les personnes de cette organisation.

WAYF

Il connaît toutes les organisations participantes à la fédération, ainsi que les caractéristiques de leurs serveurs Shibboleth. Il peut donc rediriger les utilisateurs vers le serveur de leur organisation de rattachement pour qu’ils puissent s’authentifier.

Tequila

L’architecture Tequila est très similaire. La différence principale provient du fait que le fournisseur d’identité est confondu avec le WAYF.

Du point de vue du client

Il faut d’abord s’entendre sur le sens du mot client dans ce contexte. Nous considérerons que le client est le fournisseur de ressources. C’est lui qui a les interactions les plus grandes avec le système d’authentification dans son ensemble.

Shibboleth

Shibboleth fournit un module pour le serveur Web (Apache et IIS). Ce module permet de protéger des ressources Web sur le serveur de façon assez sommaire. Si ces ressources sont des scripts, les attributs de l’utilisateur leur seront passés via des variables d’environnement, comme pour CGI.
Tous les fournisseurs de ressources doivent être dûment validés a priori auprès de l’IdP avant de pouvoir l’utiliser, ce qui est une contrainte assez lourde.

Tequila Tequila fournit une interface client beaucoup plus riche. Un module Apache fournit à peu près les mêmes prestations que le module Shibboleth, mais il existe aussi des modules qui peuvent être appelés par différents langages fréquemment utilisés pour écrire des scripts CGI (Perl, PHP, Java et ASP). Ces modules fournissent une API qui permet de paramétrer finement les appels au serveur Tequila.
L’une des possibilités essentielles de Tequila est de pouvoir spécifier des assertions que devra vérifier le serveur avant de donner l’accès à l’utilisateur. Ces assertions se présentent sous la forme d’expressions booléennes portant sur les attributs de l’utilisateur.
Un client Tequila peut utiliser les ressources de son serveur sans en être connu auparavant, ce qui facilite le déploiement.

Intégration Tequila Shibboleth

L’EPFL utilise depuis plusieurs années les services de Tequila. Pour s’intégrer de façon satisfaisante dans une fédération Shibboleth sans perdre les avantages acquis, il faut mettre en place une infrastructure de collaboration active et transparente entre les 2 mondes. Trois scénarios se présentent :

Un utilisateur EPFL veut utiliser une ressource fournie par une autre organisation membre de la fédération Shibboleth

Pour ceci, l’EPFL doit disposer d’un serveur Shibboleth intégré dans la fédération. Ce serveur doit mettre à disposition notre base d’utilisateurs, ainsi qu’un certain nombre d’attributs dont tous les acteurs de la fédération auront compris le sens. Ceci est un point clé. En effet, il est facile de comprendre le sens d’attributs tels que le nom ou le prénom d’une personne, mais ceux-ci ne présentent absolument aucun intérêt du point de vue du contrôle d’accès. Les attributs présentant un intérêt de ce point de vue concernent essentiellement les statuts, droits et rôles qui sont gérés dans notre système d’accréditation et n’ont fait l’objet d’aucun consensus à un niveau plus large que l’EPFL.

Un utilisateur EPFL veut accéder à une ressource interne à l’EPFL

Dans ce cas rien à faire, le système Tequila reste en place comme auparavant. Si le fournisseur de ressource préfère utiliser directement l’interface Shibboleth pour protéger sa ressource, c’est possible, mais il faudra disposer de moyens centraux pour l’enregistrement de ces AP.
Tequila offre un accès facile à tous les attributs internes, entre autres à tous les attributs issus du système d’accréditation et du système de gestion de groupes. Il n’y aura aucune rupture de service dans ce domaine.

Un utilisateur d’une autre organisation membre de la fédération désire utiliser une ressource interne à l’EPFL

C’est là que ça se corse. Si la ressource est protégée directement par Shibboleth, rien à dire. Si la ressource est protégée par Tequila, il est important que cet accès soit transparent et non surprenant pour le fournisseur de ressource.

Transparent

Ne demande peu, voire aucun travail au fournisseur de ressource, tout doit se passer comme avant. Ce sera donc au serveur Tequila d’assurer cette transparence en faisant tout le travail d’interface avec la fédération Shibboleth.

Non surprenant

Un fournisseur de ressource ne doit pas se trouver tout à coup avec des utilisateurs de toute la fédération qui accèdent à son application sans qu’il ait fait quoi que soit pour. Il faut donc que par défaut seuls les utilisateurs EPFL soient visibles, mais que avec un tout petit travail de configuration, on puisse signifier à Tequila que l’on autorise aussi les utilisateurs Shibboleth externes.

Solution

La solution évidente est de configurer le serveur Tequila EPFL comme fournisseur de ressources (AP) au sens Shibboleth. Ceci peut être fait en configurant uniquement ce serveur, donc avec un travail à faire une seule fois. Il y a 2 variantes possibles, soit la fédération Shibboleth dans son ensemble est vue comme une seule organisation extérieure, l’utilisateur sera alors redirigé vers le WAYF central, soit les différents membres de la fédération sont vus directement dans l’interface Tequila, qui devra alors faire office de WAYF.
La seconde variante présente l’avantage d’économiser un écran pour l’utilisateur (l’écran WAYF) et de mieux intégrer la fédération Shibboleth dans la fédération Tequila puisqu’il n’y aura pas de différence visuelle entre les organisations Shibboleth et les organisations Tequila dans l’interface utilisateur.
Dans la pratique, les 2 variantes sont implémentées, mais seule la variante 2 est active. Pour que cette configuration fonctionne, Tequila doit disposer de la liste des serveurs Shibboleth de la fédération ainsi que de leurs caractéristiques, tout ce qu’un bon WAYF doit savoir. Ces données seront mises dans un fichier de configuration du serveur finement nommé Shibboleth.conf, par exemple :

Provider1.id:   urn:mace:switch.ch:aaitest:dukono.switch.ch
Provider1.sso:  https://dukono.switch.ch/shibboleth-idp/SSO
Provider1.name: AAI Test Home Organization,

Provider2.id:   urn:mace:switch.ch:aaitest:epfl.ch
Provider2.sso:  https://shibb-idp.epfl.ch/shibboleth-idp/SSO
Provider2.name: EPFL Test Home Organization

Provider3.id:   urn:mace:switch.ch:aaitest:unifr.ch,
Provider3.sso:  https://siufaaihs.unifr.ch/shibboleth-idp/SSO
Provider3.name: Université de Fribourg Test Home Organization

Provider4.id:   urn:mace:switch.ch:aaitest:usz.ch,
Provider4.sso:  https://aai-logon.unispital.ch/shibboleth-idp/SSO
Provider4.name: USZ Test Home Organization

Les attributs

Pour assurer la transparence au client, il faut fournir une correspondance entre les attributs Tequila usuels et les attributs Shibboleth. Heureusement, la fédération Shibboleth suisse actuelle utilise peu d’attributs. La correspondance d’attributs sera aussi donnée dans le fichier Shibboleth.conf, pour l’instant :

Mapping:               HTTP_SHIB_APPLICATION_ID appid
Mapping:        HTTP_SHIB_AUTHENTICATION_METHOD authmethod
Mapping:            HTTP_SHIB_IDENTITY_PROVIDER identprov
Mapping: HTTP_SHIB_SWISSEP_HOMEORGANIZATIONTYPE orgtype
Mapping:                  HTTP_SHIB_ORIGIN_SITE origsite
Mapping:      HTTP_SHIB_ORGPERSON_POSTALADDRESS postaladdress
Mapping:             HTTP_SHIB_SWISSEP_UNIQUEID username
Mapping:     HTTP_SHIB_SWISSEP_HOMEORGANIZATION org
Mapping:               HTTP_SHIB_PERSON_SURNAME name
Mapping:      HTTP_SHIB_INETORGPERSON_GIVENNAME firstname
Mapping:           HTTP_SHIB_INETORGPERSON_MAIL email
Mapping:       HTTP_SHIB_PERSON_TELEPHONENUMBER phone

Ainsi, le client Tequila, verra l’attribut Shibboleth HTTP_SHIB_SWISSDEP_UNIQUEID comme l’attribut Tequila username qui a au moins le mérite d’une plus grande concision.
Attention, le username Shibboleth est différent du username Tequila. En général, il est de la forme unique_id@organisation. Pour être compatible avec ce schéma, les utilisateurs de l’organisation locale qui pour rigoler se loggent via Shibboleth, auront un username de ce type, soit numero_sciper@epfl.ch dans le cas de l’EPFL.
De même, il faudra se méfier de l’attribut org, sa valeur n’est pas encore entièrement définie. Pour l’instant, elle vaut test.epfl.ch et ça va sans doute changer, mais ce ne sera pas forcément EPFL. Bien entendu, côté client, ces attributs ont toutes les bonnes propriétés des attributs Tequila, on peut les demander au serveur et surtout, on peut imposer la vérification d’assertions portant sur eux. Ils sont indiscernables des attributs Tequila standards.

La non surprise

Si le client ne dit rien, les utilisateurs non-EPFL ne doivent pas être visibles. Pour cela on va utiliser une des possibilités du serveur Tequila qui est d’avoir des restrictions par défaut portant sur la valeur de certains attributs. Actuellement la seule restriction porte sur l’attribut categorie qui est restreint aux valeurs EPFL et EHE. Cette restriction peut être levée par le client à l’aide de la commande Allows. Donc pour faire simple, il a été décidé unilatéralement d’attribuer la valeur SHIBBOLETH à l’attribut categorie aux utilisateurs hors EPFL de la fédération Shibboleth. Ainsi, avec la restriction usuelle, ils ne seront pas vus des applications. Pour les voir, le client doit donc le spécifier explicitement. Par exemple, dans le cas de l’utilisation du module Apache, on pourra dire :

TequilaAllows   categorie=SHIBBOLETH
TequilaAllowIf  firstname=claude

Donnant ainsi accès au document protégé à tous les Claude des universités et hautes écoles suisses. Et en plus, ça marche avec d’autres prénoms que Claude.

Interface utilisateur

Comme les organisations Shibboleth sont vues comme des organisations Tequila, il n’y a pas de différence entre la nouvelle interface et l’ancienne quand il y avait plusieurs organisations dans la cellule Tequila.
Si vous êtes de l’organisation locale (ici EPFL), utilisez la partie du haut, sinon choisissez une organisation dans la partie du bas. Dans le cas ci-dessous il n’y a que des organisations Shibboleth dans le menu, mais s’il y avait d’autres serveurs Tequila dans la cellule, ils seraient mélangés parmi eux.

Conclusions

L’intégration Tequila / Shibboleth ne pose pas de problème particulier, les principes de fonctionnement étant très similaires. Il y a sans doute encore des chausses-trappes que nous n’avons pas encore vues et dans lesquelles nous allons tomber, mais rien de majeur. L’interface Shibboleth du serveur Tequila EPFL de production est déjà opérationnelle. Bien que l’EPFL ne soit pas encore dans la fédération Shibboleth des hautes écoles suisses, il est déjà possible de se familiariser avec ces nouveaux concepts dans une fédération de test.

Références



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.