Shibboleth IdP version 3: Points d'attentions et évolutions

Références

Pourquoi un IdP v3

Il a été envisagé dès les dernières mises à jour de l'IdP v2 que les contributions extérieures allaient être nécessaire pour la pérennité du projet Shibboleth IdP. En effet, Les ressources humaines sont limitées et il est donc impossible de maintenir deux versions en parallèle.

Quid de Shibboleth IdP version 2

Seules des mises à jour de sécurité seront encore appliquées selon le calendrier suivant :

  • 29 Février 2016 – failles moyennes
  • 31 Mai 2016 – failles importantes
  • Fin de vie définitive 31 Juillet 2016
    • Failles critiques corrigées jusqu’à cette date

Pour rappel, la version sûre minimale de la vesrion 2 est à cette date la “2.4.4”.
Plus de détails : http://shibboleth.net/pipermail/announce/2015-May/000112.html

Changement et nouveautés

La version 3 de l'IdP Shibboleth a été en développement depuis plus de 2 ans et pensée avec deux objectifs principaux :

  • faciliter le développement d'extensions en les rendant moins complexes et plus standards ;
  • Découpler l'IdP du protocole SAML pour faciliter son adaptation à d'autres protocoles d'authentification et d'autorisation.

Cette nouvelle version est fonctionnellement compatible avec Shibboleth v2, mais sa nouvelle API oblige les extensions précédemment développées à être à adaptées. En effet, l'architecture de cette version s'appuie sur Spring Web Flow. Cette nouvelle version n'apporte pas aujourd'hui de nouvelles fonctionnalités par rapport à la version 3. Les développeurs se sont concentré sur la maintenabilité du code, faciliter les déploiement et mises à jour et comme annoncé, préparer le terrain à des contribution plus “propres” qui elles pourront enrichir fonctionnellement cette nouvelle version.

Environnement technique

L'IdP v3 est toujours développé en Java. Il n'y a donc pas de contraintes fortes sur la nature du système d'exploitation. Ici les établissements auront le choix en privilégiant leur système préféré. Toutefois il est nécessaire de savoir que :

  • Tomcat 6 ou plus vieux ne sont plus supportés ;
  • Jetty 7 ou plus vieux ne sont pas supporté ;
  • Java 6 ou plus vieux ne sont plus supportés.

Des détails supplémentaires sur les versions de l'environnement Java et du conteneur de Servlet seront précisés dans nos prochaines documentations d'installation.

Réorganisation des fichiers de configuration

Le nombre de fichiers a augmenté mais pour mieux cibler les fonctionnalités et les rendre plus lisibles.

Génération des PersistentID/NameID

Il s'est avéré lors des tests d’interopérabilité avec d'autres implémentations de SAML2 que cet identifiant devait être manipulable facilement et finement. En effet, certaines implémentations, notamment commerciales, supportent SAML de façon minimale. Cet identifiant peut être

  • SAML 1 NameIdentifier et SAML 2 NameID
  • Identifiant persistant ou volatile (session)

Pour ces implémentations, il faut pouvoir transmettre un « attribut » en tant que jeton de session en lieu et place d’un identifiant, e.g. une adresse email. La génération est très similaire à ce qui existe pour IdP v2, mais la configuration est dédiée et séparée dans les fichiers saml-nameid.xml et saml-nameid.properties.

Module de recueil de consentement

Dans la version 2, une extension nommée uApprove pouvait être ajoutée pour le rôle de module d'information et de recueil de consentement. La version 3 intègre ces fonctionnalités et les enrichit par défaut. Par exemple, il est possible d'interrompre un flux d'authentification si les attributs ou leurs valeurs ne correspondent pas au contexte souhaité par une ressource.
Note : si l'extension serveur CAS est utilisée, l'écosystème CAS bénéficie de ces fonctionnalités également.

Services en ligne de commande

Le client AACLI évolue et est mieux intégré dans un service en ligne de commande plus réactif.
Des services en ligne de commande pour recharger la configuration ou les méta-données existent également et évitent de relancer le conteneur ou recharger la servlet (reload-metadata.sh et reload-service.xml).

Gestion des mises à jour

Les mises à jour entre les différentes version 3 sont pensées pour faciliter la maintenabilité de la brique technique et d'éviter les erreurs/problèmes pour de “simples” mises à jour de sécurité ou de bug fix.

  • Séparation claire entre les configuration utilisateurs et celles du “système”;
  • Reconstruction du WAR selon les besoins pour appliquer des changements locaux.

Personnalisation des pages

Il ne s'agit plus de modifier des fichiers JSP mais des patrons Velocity. Cela permet de faire des changements sans être obligé de redémarrer le conteneur de servlet. Permet de “ranger” les fichiers dans des arborescences différentes du webapp du conteneur et donc d'éviter les écrasements lors des mises à jour.

  • Pages de login, logout ou erreurs

SSO-CAS

Une implémentation (en Bêta) du protocole CAS v2 est livrée avec l'IdP v3 par défaut. Développée par un développeur de JASIG CAS (Virginia Tech.) qui s'est joint au projet Shibboleth IdP.

  • C'est une alternative à un serveur CAS (e.g. JASIG CAS) ;
  • Les applications cassifiées avec leurs clients CAS ne sont pas impactées ;
  • Force authentication, Gateway et Proxy tickets, LPPE… supportés ;
  • Testé avec les clients les plus populaires (Http, Java, Php, .Net…) ;
  • Export d'attributs en SAML1.1 ;
  • Single Logout planifié pour la version 3.2.0.

Cette extension permet de centraliser la gestion du Web-SSO sur une unique brique technique.

Planifier la migration

Il est fortement conseillé aujourd'hui de ne pas entreprendre de migration. En effet, les changements sont suffisamment importants pour rendre cette tache complexe.
N'envisagez pas une migration en lieu et place de votre installation IdP v2. Un serveur séparé testé et validé avec la nouvelle version 3 pourra être passé en production.

RENATER mettra dès la fin Septembre sa documentation d'installation de Shibboleth IdP à jour. Des formations seront quant à elle programmées pour des sessions régulières durant 2016.