Shibboleth et la haute disponibilité
Mehdi Hached
RENATER
Campus de Beaulieu - Rennes
Olivier Salaün
Comité Réseau des Universités
Campus de Beaulieu - Rennes
Résumé
Shibboleth est le logiciel utilisé pour déployer les mécanismes de fédération d'identités dans les établissements d'Enseignement supérieur et de Recherche. On distingue deux briques logicielles distinctes distribuées sous l'appellation Shibboleth : le fournisseur d'identités (Identity Provider ou IdP) et le fournisseur de services (Service Provider ou SP). Un logiciel complémentaire, le service de découverte (Where Are You From ou WAYF), permet l'orientation des requêtes du fournisseur de services vers le fournisseur d'identités. Chacun de ces logiciels a des contraintes de disponibilité et des dépendances complexes à déterminer. L'objectif de l'article est d'étudier les problématiques de haute disponibilité pour ces trois services.
Cet article s'adresse principalement aux administrateurs Shibboleth dans les établissements ; il doit les aider à comprendre les contraintes qui s'appliquent aux services de fédération d'identités qu'ils opèrent, à choisir une architecture pour leur service de fédération d'identités et mettre en œuvre une technologie de haute disponibilité adaptée à leurs besoins.
Mots clefs
Haute disponibilité, répartition de charge, tolérance aux pannes, Shibboleth, fédération d'identités, SAML, HTTP.
Le service « fédération d'identités » est aujourd'hui déployé dans la plupart des établissements d'enseignement supérieur et commence à l'être dans les organismes de recherche ; la Fédération Éducation-Recherche [1] contribue à généraliser ce service. Il s'agit d'un mécanisme d'authentification web distribuée, permettant de répondre à des besoins d'échanges inter-établissement. Le principe : pour accéder à une ressource web proposée par un autre établissement, un utilisateur se connecte auprès du service d'authentification de son propre établissement [2]. La fédération d'identités met en œuvre le protocole SAML (Security Assertion Markup Language) [3] pour les échanges d'assertions d'authentification.
Shibboleth [4] est l'implémentation de la fédération d'identités utilisée par les établissements français. Ce logiciel libre, développé par le consortium Internet2, se décline en trois composants logiciels : le fournisseur de services, le fournisseur d'identités et le WAYF ou service de découverte. Notre étude s'applique également à d'autres implémentations du WAYF, notamment celle distribuée par SWITCH [5], car utilisée majoritairement par les établissements français.
La problématique de haute disponibilité des applications web a déjà été étudiée [6], nous verrons que les techniques habituelles de répartition de charge et de tolérance aux pannes s'appliqueront également aux services Shibboleth. Aussi, les auteurs de cet article visent davantage l'analyse détaillée de l'architecture et des contraintes qui reposent sur chacune des trois briques étudiées. Cette étude approfondie s'avère nécessaire, compte-tenu de la relative complexité de l'architecture de fédération d'identités et des multiples dépendances, y compris entre les systèmes d'informations d'établissements différents. Nous proposerons ensuite des objectifs de haute disponibilité adaptés à chaque service Shibboleth, en dissociant les besoins de répartition de charge et de tolérance aux pannes.
Nous présenterons une liste, non exhaustive, de solutions techniques de haute disponibilité applicables à Shibboleth. Nous analyserons les atouts et les limites de chacune, sans rentrer dans les détails de mise en œuvre. Pour conclure nous présenterons un cas concret de mise en œuvre de la haute disponibilité, appliqué au fournisseur d'identités proposant les « comptes CRU ».
La fédération d'identités est un mécanisme d'authentification distribué pour les applications web. Le logiciel client utilisé est donc un navigateur web, les états sont gérés au moyen de cookies HTTP et les échanges entre les différents services passent par des redirections HTTP.
La fédération d'identités se différencie des services de Single Sign-On utilisés dans les établissements (serveurs CAS [7] principalement), par son architecture distribuée : un service fédéré, proposé par un établissement est accessible aux utilisateurs d'un autre établissement. Cette architecture, dépassant le périmètre d'un établissement, nécessite la mise en place d'une confiance technique entre chacune des briques logicielles, à l'échelle nationale. La liste des entités de confiance est maintenue par une structure centrale (le CRU et RENATER dans le cas de la Fédération Éducation-Recherche). L'opérateur de la fédération publie les méta-données de la fédération contenant les informations techniques sur chaque entité membre du cercle de confiance.
Une fédération repose sur trois services : le fournisseur d'identités (ou IdP) gère l'authentification des utilisateurs et la diffusion des attributs les décrivant, le fournisseur de services (ou SP) protège l'accès à une application web, le service de découverte (ou WAYF) assure l'orientation de l'utilisateur vers le fournisseur d'identités dont il dépend.
Lors d'une phase d'authentification standard, un utilisateur accédant à une application web est mis en contact avec les trois services Shibboleth. L'indisponibilité d'un des services empêchera donc l'accès à l'application. On a donc une forte interdépendance de ces briques fonctionnelles, généralement réparties dans des organismes différents.
Le fournisseur d'identités Shibboleth est une application Java (servlet), exécutée par un serveur d'applications (Apache Tomcat ou Jboss AS par exemple). Une seule instance de cette application est installée pour un même organisme. Elle est généralement (selon configuration) dépendante du service d'authentification web de l'organisme (serveur CAS par exemple) et dépend du référentiel utilisateur (annuaire LDAP et bases métier SQL) pour construire les assertions d'attributs SAML. Il est donc nécessaire, au préalable, de rendre les services CAS, LDAP et bases SQL hautement disponibles.
Le fournisseur d'identités Shibboleth a une gestion des sessions dont l'identifiant est le nameID (identifiant échangé dans une assertion SAML). Cette gestion de sessions introduit une notion d'état qui complique le travail pour mettre en place la haute disponibilité.
Outre les attributs utilisateurs extraits des référentiels de l'établissement, le fournisseur d'identités Shibboleth peut générer des attributs dynamiquement. L'attribut eduPersonTargetedId [8] est un cas particulier. Il s'agit d'un identifiant de l'utilisateur persistant et opaque mais stable dans le temps. Pour satisfaire aux besoins de confidentialité, cet identifiant doit par ailleurs avoir une valeur différente, pour un même utilisateur, en fonction du fournisseur de services demandeur. L'implémentation recommandée consiste à stocker les valeurs de l'attribut eduPersonTargetedId dans la base de données du fournisseurs d'identités. Cette base de données devra donc être hautement disponible.
Il importe de bien analyser les contraintes qui reposent sur un fournisseur d'identités : s'il est indisponible, l'accès à de nombreuses applications est impossible pour les utilisateurs dont il gère l'authentification. Le paradoxe est que l'organisme exploitant ce fournisseur d'identités peut ne pas s'en rendre compte puisqu'il donne principalement accès à des applications extérieures à l'organisme.
Le fournisseur de services Shibboleth est un module d'authentification pour le serveur web Apache. Le module intercepte les requêtes HTTP en frontal d'une application et, à l'issue de la phase d'authentification, fournit à l'application les attributs de l'utilisateur. Le fournisseur de services peut être installé à raison d'une instance par serveur web, mais il est envisageable d'en installer une seule instance sur un serveur proxy [9]. Cette architecture permet de ne devoir administrer qu'un seul logiciel. Cependant cela accroît les contraintes de disponibilité sur cette instance.
Cette brique Shibboleth intègre une notion d'états puisqu'elle gère une table des sessions des utilisateurs actifs. Cette table est, par défaut, stockée en mémoire par un processus (le démon shibd). Il est ainsi possible de redémarrer le serveur web, sans perdre la table des sessions actives. Il est également possible de stocker les sessions actives dans une base de données relationnelle via le protocole ODBC (Open DataBase Connectivity). Cette dernière option est intéressante lorsque l'on cherche à améliorer la haute disponibilité du service.
Il est important de considérer la chaîne des dépendances d'un fournisseur de services vis-à-vis des autres services Shibboleth. Le fournisseur de services dépend en premier lieu du service de découverte qui lui est associé, service que nous étudions dans le chapitre suivant. Il existe des cas particuliers où le service de découverte n'est pas utilisé : lorsqu'un fournisseur de services ne reconnaît qu'un seul fournisseur d'identités et lorsqu'un établissement publie des URL d'accès direct au fournisseur d'identités (typiquement les liens vers des ressources fédérées publiées dans l'ENT (Espace Numérique de Travail) d'un établissement) [10]. Le fournisseur de services dépend aussi et surtout des fournisseurs d'identités qui assurent l'authentification des utilisateurs. Le fournisseur d'identités doit être disponible, mais il doit surtout être configuré correctement. Un problème couramment rencontré est celui d'un fournisseur d'identités qui n'aura pas été correctement configuré pour transmettre les attributs demandés par un fournisseur de services. Dans ce cas, l'utilisateur sélectionne son établissement de rattachement, s'authentifie, mais finit par se voir refuser l'accès à la ressource fédérée.
Le service de découverte permet à un fournisseur de services d'orienter chaque utilisateur vers le fournisseur d'identités approprié. Cette application consiste généralement en un menu déroulant où l'utilisateur sélectionne son organisme de rattachement. Ce service a une logique simple et ne gère aucun état, le choix de l'utilisateur est simplement mémorisé dans un cookie HTTP.
Il existe plusieurs implémentations disponibles en PHP, en Java. Par ailleurs, de nombreuses applications clientes de la fédération d'identités vont jusqu'à implémenter la fonction de service de découverte, alors mieux intégrée à l'application. Si la fonction du service de découverte n'est pas intégrée à une application, on trouve plusieurs scénarios de déploiement plus ou moins locaux. Un service de découverte peut être dédié à une application (ou un service) ou mutualisé (au niveau national ou bien à l'échelle d'un établissement, d'une UNR (Université Numérique en Région), etc). L'intérêt principal d'opérer un service de découverte central est d'ordre ergonomique. En effet l'utilisateur est habitué à utiliser ce service et la pré-sélection de son établissement sera valide pour l'accès à tous les services auxquels il se connectera. En contrepartie, un service de découverte mutualisé a des contraintes de disponibilité extrêmement fortes puisque son indisponibilité impactera tous les services fédérés.
Les méta-données concrétisent le cercle de confiance puisqu'elles contiennent la liste des entités de confiance et leurs coordonnées techniques. Ce fichier est maintenu par les opérateurs de la fédération et chaque brique technique synchronise régulièrement sa version du fichier. Comme chaque entité de la fédération peut fonctionner sans les méta-données centrales (du moins au cours de la période de validité des méta-données, fixée à une semaine pour la Fédération Éducation-Recherche).
Il est important de s'attarder sur la gestion des sessions utilisateurs dans chaque brique logicielle de fédération d'identités car elle impacte fortement les objectifs de haute disponibilité qu'il conviendra de mettre en œuvre.
Illustration 1: Les
différentes sessions applicatives au cours de la phase
d'authentification
Soit une application fédérée, protégée par un fournisseur de services Shibboleth, à laquelle un utilisateur veut accéder, ce dernier sera successivement redirigé vers plusieurs services. L'illustration 1, ci-dessus, indique l'enchaînement des redirections de l'utilisateur ainsi que les différentes sessions utilisateur gérées par chaque application. Nous allons nous intéresser aux caractéristiques de ces sessions, notamment le stockage des informations, la durée de vie de la session, l'impact en cas de perte de la session.
La session au niveau d'un serveur CAS est maintenue au moyen d'un Ticket Granting Cookie. La table des sessions est gérée en mémoire. La durée de vie du cookie de session est par défaut de 7200 secondes. Il faut noter qu'un fournisseur d'identités Shibboleth peut se passer de l'utilisation d'un serveur CAS, dans ce cas il implémente son propre « backend » d'authentification.
L'importance de la session gérée par le fournisseur d'identités est à nuancer lorsqu'un serveur CAS est associé : en effet, la perte de la session utilisateur entraînera la redirection de l'utilisateur vers le serveur CAS. Si la session auprès du serveur CAS est toujours active, la perte de session auprès du fournisseur d'identités ne sera pas perçue par l'utilisateur.
Le fournisseur de services Shibboleth propose une configuration avancée de la durée de vie des sessions [11] (notion d'inactivité, paramétrage par attribut). Si la session utilisateur auprès du fournisseur de services expire, l'utilisateur est amené à se ré-authentifier auprès de son fournisseur d'identités ; par défaut la période d'inactivité est fixée à 3600 secondes. Cette phase de ré-authentification peut provoquer la perte de données dans le cas suivant : l'utilisateur s'apprête à soumettre des informations via la méthode POST HTTP ; le fournisseur de services interrompt la soumission de données car la session utilisateur a expiré ; il redirige l'utilisateur vers son fournisseur d'identités en perdant le contenu des données soumises.
La gestion d'une session utilisateur gérée par l'application fédérée doit permettre d'éviter le scénario évoqué ci-dessus ; lors de la phase de connexion, l'application doit exploiter les informations transmises par le fournisseur de services pour initier sa propre session utilisateur.
On constate donc que la perte de la session utilisateur, que peut occasionner la répartition d'un service Shibboleth sur plusieurs serveurs, peut être acceptable dans certains cas, compte-tenu des sessions maintenues par les autres services mis en jeux dans la séquence d'authentification. La perte des sessions actives pourra, par ailleurs, être évitée de plusieurs manières :
en partageant le « backend » de stockage des sessions (possible pour le fournisseur de services avec ODBC) ;
en partageant la mémoire entre les instances du service (l'approche Terracotta, évoquée au chapiltre 5) ;
en orientant toujours les requêtes d'un utilisateur vers la même instance (mode « sticky »).
Après avoir exposé en quoi l'architecture de fédération d'identités nécessite la mise en place de haute disponibilité, et suite à la description des contraintes techniques s'appliquant à chaque service (fournisseur d'identités, fournisseur de services et service de découverte), il est utile de fixer des objectifs raisonnables pour chaque service.
Dans ce cadre, nous dissocierons les objectifs de tolérance aux pannes et de répartition de charge. Dans le cas de la tolérance aux pannes, nous étudierons également l'opportunité de distribuer le service sur des sites géographiques distants. Dans le cas de la répartition de charge, l'embûche est principalement le partage des sessions utilisateurs.
Notez que nous n'abordons pas les bonnes pratiques d'administration d'un fournisseur d'identités Shibboleth qui peuvent tout autant contribuer à la haute disponibilité du service.
Une seule instance du fournisseur d'identités Shibboleth peut gérer la charge pour un gros établissement (les développeurs de Shibboleth annoncent 50 connexions/sec). Il est cependant recommandé de peaufiner la configuration de la machine virtuelle Java [12] notamment pour la gestion de la mémoire et l'optimisation des fonctions de cryptographie. L'objectif de répartition de charge n'est donc pas à considérer pour la majorité des établissements. Il peut l'être dans le cas d'un organisme géographiquement distribué, où on voudra installer une instance du fournisseur d'identités au plus près de chaque site.
Un fournisseur d'identités Shibboleth (tout comme un serveur CAS) est l'objet de fortes dépendances de la part d'un grand nombre d'applications web. Il doit donc être tolérant aux pannes, pannes matérielles ou pannes logicielles/systèmes d'une instance de ce service d'authentification. La difficulté principale concerne la table des sessions actives, gérée en mémoire par le logiciel Shibboleth. Nous verrons par la suite, qu'il est possible de mettre en œuvre une grappe (ou « cluster ») de serveurs avec la technologie Terracotta, permettant de partager la table des sessions entre plusieurs serveurs.
Le maintien des sessions actives est cependant à nuancer, car on pourra accepter de perdre les sessions actives en cas de panne, pourvu qu'une autre instance du fournisseur d'identités assure le service.
Si un fournisseur de services est dédié à une application, on peut lui appliquer les mêmes contraintes de disponibilité que celle de l'application : si l'application n'est pas rendue hautement disponible, il n'est pas utile de renforcer la disponibilité du fournisseur de services. En revanche, un fournisseur de services, mutualisé à l'échelle d'un établissement (agissant en tant que reverse proxy) fera l'objet d'exigences accrues en terme de tenue de charge et de disponibilité car plusieurs applications dépendent de lui. Dans ce cas on voudra naturellement mettre en œuvre la répartition de charge sur plusieurs instances du fournisseur de services. Cette architecture mutualisée est généralement adoptée par les établissements pour n'avoir qu'une seule brique Shibboleth à administrer et configurer, au lieu d'une par serveur web dans l'établissement.
Si un service de découverte est dédié à une application (voire intégré dans une application), il n'amène pas de contrainte de haute disponibilité supplémentaire. S'il s'agit d'un service de découverte mutualisé, servant un ensemble d'applications, il est opportun de le rendre tolérant aux pannes. La mise en place de plusieurs instances d'un service de découverte est facilitée par le fait que ce service ne gère pas de notion d'état côté serveur. La seule information stockée au moyen d'un cookie HTTP côté client est la pré-sélection du fournisseur d'identités.
L'objectif de répartition de charge n'est pas à envisager pour ce service qui a une logique simple (pas de consommation CPU ni de mémoire).
Concernant la partie implémentation de la haute disponibilité, nous présentons brièvement différentes solutions envisageables. Pour chaque solution, nous détaillons dans le tableau ci-dessous leur principe de fonctionnement, l'utilisation pressentie dans le cas de Shibboleth et les inconvénients. Nous décrirons ensuite de façon plus détaillée les solutions retenues pour assurer la haute disponibilité des comptes CRU.
|
Technologie |
Principe de fonctionnement |
Utilisation avec Shibboleth |
Facilité de déploiement |
Inconvénients |
|
Round robin DNS |
Plusieurs serveurs alternatifs publiés dans le DNS |
Répartition de charge |
Simple |
Un serveur en panne reste actif dans la grappe. Mais des solutions complémentaires permettent de vérifier l'état d'un serveur. Exemple : lbnamed. |
|
Répartiteur de charge matériel |
Un matériel oriente les requêtes vers un des serveurs de la grappe |
Répartition de charge |
Simple |
Onéreux |
|
mod_proxy[16] (ou HAProxy[17]) |
Un serveur Apache, en frontal, distribue les requêtes vers un ensemble de serveurs. |
Répartition de charge |
Nécessite une configuration Apache pour ajouter des nœuds |
Tous les serveurs sont considérés comme actifs. Ne couvre que les protocoles HTTP et AJP. |
|
HeartBeat |
Une adresse IP virtuelle est partagée entre plusieurs serveurs. Heartbeat assure la surveillance du serveur actif et le basculement vers le serveur de backup en cas de panne. |
Tolérance aux pannes |
Configuration de heartbeat et de la surveillance des services. |
Un lien direct entre les serveurs est préconisé pour transmettre les « battements de cœur » |
|
Terracotta [13] ou Jboss cache [14] |
Partage de ressources (mémoire) entre des applications Java distribuées sur plusieurs serveurs |
Partage de sessions entre des IdP Shibboleth |
L'application doit être modifiée pour exploiter les fonctionnalités Terracotta. Configuration du cluster Terracotta. |
Limité à des applications Java. |
Le CRU propose sous la dénomination « comptes CRU » un fournisseur d'identités ouvert à une population large. Tout fournisseur de services adhérant à la Fédération Éducation-Recherche peut utiliser ce fournisseur d'identités. Il permet à tout utilisateur ne disposant pas (ou pas encore) d'un fournisseur d'identités institutionnel d'accéder aux services utilisant les mécanismes de fédération d'identités. Ce service a de fortes contraintes de disponibilité puisqu'il gère plusieurs dizaines de milliers d'utilisateurs.
Ce service est composé de 3 briques logicielles (servlets JAVA) :
un IdP Shibboleth (aujourd'hui en version 2.1.x) ;
un serveur CAS ;
l'outil de provisionning des comptes CRU. Cette application est l'interface web de création, modification et suppression de comptes CRU.
Illustration 2:
Dépendance entre les briques logicielles des Comptes CRU
Ces trois services s'appuient sur une base de
données MySQL qui leur sert de référentiel
utilisateurs. Ci-dessous le schéma des dépendances :
On remarque que l'IdP Shibboleth délègue l'authentification à un serveur CAS. Les deux services ont une contrainte de disponibilité égale. En effet, le serveur CAS des comptes CRU n'est pas utilisé seul (aucune application CASifiée). L'IdP ne peut réaliser le SSO étendu sans une authentification préalable par le serveur CAS.
Il est possible de simplifier l'architecture des comptes CRU en se passant du serveur CAS. En effet, la version 2 de l'IdP Shibboleth permet l'utilisation d'un service d'authentification interne implémentant plusieurs méthodes d'authentification (LDAP, Kerberos).
Le gestionnaire des comptes CRU, qui permet la création, la modification ou encore la suppression du compte a une contrainte de disponibilité moindre. Une panne du serveur la déployant ou une erreur de l'application est bien plus tolérable même si elle peut représenter un blocage pour les nouveaux utilisateurs.
Le serveur MySQL concentre de fortes contraintes de disponibilité, puisqu'il est indispensable aux trois services. Nous ne traiterons cependant pas la mise en haute disponibilité de ce serveur dans cet article.
L'objectif de tolérance aux pannes est jugé prioritaire dans le cas des comptes CRU. Compte-tenu du nombre d'utilisateurs du services et du nombre croissant d'applications clientes de ce fournisseur d'identités, nous désirons mettre en place un serveur de secours, capable de prendre le relai en cas de panne du serveur principal. Nous utiliserons le logiciel Heartbeat afin de partager une adresse IP virtuelle entre les deux serveurs (actif et passif), Heartbeat gérant la surveillance du serveur actif par le serveur passif.
Une architecture permettant la répartition de charge est également envisageable. Nous envisageons deux dispositifs alternatifs pour assurer la répartition de charge du fournisseur d'identités Shibboleth :
un répartiteur de charge intégrant la fonctionnalité d'affinité de sessions (mode « sticky »). Cette fonctionnalité permet d'orienter systématiquement un client vers la même instance du service ;
un répartiteur de charge sans fonctionnalité d'affinité des sessions associé à un dispositif de partage de sessions entre instances du service. En effet, il faut pouvoir maintenir la session active d'un utilisateur qui contacterait successivement plusieurs instances du service.
Le partage de sessions utilisateurs entre instances de l'IdP1 peut être assuré par la technologie Terracotta. Les développeurs de l'IdP Shibboleth privilégient l'utilisation de cette technologie puisqu'ils ont intégré un client Terracotta dans leur application. De ce fait, et compte-tenu de l'originalité du produit, nous avons étudié sa mise en œuvre, sans pour autant cibler une mise en production pour les besoins du CRU. En effet l'analyse de la charge de l'IdP des comptes CRU n'a pas révélé la nécessité de répartir le service.
Terracotta est une solution Java qui permet le partage de mémoire entre plusieurs instances d'une même application au sein d'une JVM (ou plus). Terracotta fonctionne en mode client-serveur ; l'IdP Shibboleth agit (nativement) en tant que client Terracotta. Il est nécessaire d'installer la partie serveur Terracotta qui assurera le partage de mémoire entre les clients. Le serveur Terracotta est gratuit, une version payante intègre des services complémentaires, principalement du support et du conseil.
On peut agencer les serveurs Terracotta suivant plusieurs architectures :
un seul serveur Terracotta : cette architecture permet le partage de mémoire, mais ne permet ni la répartition de la charge, ni la tolérance aux pannes du serveur ;
deux serveurs Terracotta actif et passif (notion de « mirror group) : c'est cette architecture que nous avons retenu dans notre étude. Elle permet de répartir le service Terracotta sur deux serveurs physiques pour assurer la tolérance aux pannes ;
plusieurs groupes de serveurs Terracotta actif/passif (notion de « server array ») : permet la répartition de charge entre serveurs Terracotta. Il semble que cette architecture soit adaptée pour la gestion de grandes quantités de données.
Les architectures décrites ci-dessus ne couvrent que la problématique de partage de mémoire, elles ne doivent pas être confondues avec l'architecture des serveurs Shibboleth. En effet, Terracotta ne gère pas le routage des requêtes HTTP.
Dans le cas des comptes CRU, nous configurons Terracotta en mode maître/esclave (encore appelé mode actif-passif) avec deux serveurs Terracotta, installés sur deux serveurs physiques distincts. Ces serveurs Terracotta se surveillent ; en cas de panne du serveur actif, le serveur passif prend la main. La topologie du cluster Terracotta est définie dans le fichier de configuration tc-config.xml. Ce fichier est partagé entre les serveurs et les clients Terracotta.
Illustration 3:
Architecture actif-passif de deux serveurs Terracotta
Dans notre cas, seul l'IdP Shibboleth bénéficie du partage de sessions via Terracotta, il agit en tant que client Terracotta. Il était possible de généraliser la solution au serveur CAS et au gestionnaire des comptes CRU, à condition de modifier le code de ces applications. Cela n'est malheureusement pas trivial car de bonnes connaissances des processus d'allocation des objets Java, leurs durées de vie, etc. sont primordiales.
Terracotta nous semble une bonne solution dans une architecture de répartition de charge, pour peu que le répartiteur de charge en amont ne propose pas de fonctionnalité d'affinité de sessions.
La fédération d'identités apporte des contraintes nouvelles aux établissements puisqu'elle impacte les services opérés par d'autres établissements. Les opérateurs des briques Shibboleth doivent prendre conscience de cette inter-dépendance qui force :
à accorder une place à part entière à la fédération d'identités dans l'établissement,
à définir des règles (plus) claires de gestion des identités,
à anticiper la question de la haute disponibilité de ces services.
Chaque service Shibboleth a des contraintes différentes ; de ce fait, on doit leur appliquer des objectifs de haute disponibilité différentes. Le fournisseur d'identités concentre les flux d'authentification pour de nombreuses applications et doit donc être tolérant aux pannes. Le fournisseur de services, s'il est mutualisé au sein de l'établissement, doit être lui aussi tolérant aux pannes. Le choix de la répartition de charge est à évaluer en fonction du nombre d'applications utilisant ce service. Le service de découverte, quant à lui, peut facilement s'adapter aux contraintes d'un répartiteur de charge.
La fédération d'identités, et Shibboleth en particulier n'imposent pas fortement une technologie de haute disponibilité spécifique. Chaque établissement pourra donc choisir dans sa panoplie favorite les outils s'adaptant aux contraintes de ces services.
La Fédération Éducation-Recherche, <https://federation.renater.fr>.
Gérer la propagation d'identités et d'attributs pour le web, tutoJRES, JRES2005, <http://2005.jres.org/tutoriels.html>.
SAML, Security Assertion Markup Language, Oasis, <http://wiki.oasis-open.org/security>.
SWITCH WAYF software, <http://www.switch.ch/aai/support/tools/wayf.html>.
TutoJRES Haute disponibilité des services, avril 2009, <http://www.jres.org/tuto/tuto10/index>.
CAS Central Authentication Service, JASIG, <http://www.jasig.org/cas>.
Génération de l'attribut eduPersonTargetedId, fiche technique, <https://federation.renater.fr/docs/fiches/persistentid>.
Utiliser un reverse-proxy « shibbolisé », fiche technique, <https://federation.renater.fr/docs/fiches/reverseproxy>.
Creating WAYFless URLs, London School of Economics, <https://gabriel.lse.ac.uk/twiki/bin/view/Projects/WayfLess>.
Native SP sessions, Internet2, <https://spaces.internet2.edu/display/SHIB2/NativeSPSessions>.
Tuning your Java virtual machine, Internet2, <https://spaces.internet2.edu/display/SHIB2/IdPProdJVMTuning>.
TerraCotta, <http://www.terracotta.org/>.
JBoss cache, <http://www.jboss.org/jbosscache/>.
Hearbeat : <http://www.linux-ha.org/Heartbeat>
Apache + Terracotta (version 2) en répartition de charge <http://www.scribd.com/doc/17127465/Terracotta-Load-Balancing-and-Clustering>
HAProxy : Répartiteur de charge TCP/HTTP, <http://haproxy.1wt.eu/>
1Ce besoin est lié au fait que l'IdP Shibboleth gère la table des sessions utilisateurs en mémoire.