Nous allons illustrer l'adaptation d'une application pour la rendre compatible avec Shibboleth. Pour ce faire, nous utilisons une application simple, développée par RENATER pour l'occasion : un petit moteur de Blog. Nous proposons deux implémentations strictement équivalentes écrites en Perl et en PHP. Pour la suite, vous devrez choisir l'implémentation qui a votre préférence.

Notre application myBlog est un bon cobaye car elle a les caractéristiques suivantes :

• l'application gère un mécanisme d'authentification des utilisateurs ;
• l'authentification n'est pas systématique puisque certaines parties de l'application sont accessibles anonymement ;
• l'application a une notion de rôles applicatifs avec des privilèges associés.

Après la phase d'installation de l'application, nous allons l'adapter pour lui permettre d'utiliser l'authentification Shibboleth. Cette adaptation va se faire en plusieurs étapes, illustrant les différents modes/niveaux d'intégration d'une application avec Shibboleth.

Pour effectuer le TP en Perl, suivre ce lien.

Pour effectuer le TP en PHP, suivre ce lien.

Présentation de SWITCH : http://www.terena.org/activities/eurocamp/november07/slides/hemmerle-aa_enabling_applications.pdf

Article JRES 2009 : suivre ce lien

Nous vous donnons ici quelques conseils très pratiques pour implémenter une authentification Shibboleth dans votre application :

• ampleur de la tâche : si votre application est déjà interfacée avec une authentification Apache, par certificats ou une authentification CAS, l'adaptation à Shibboleth n'en sera que plus aisée car l'application est déjà adaptée pour exploiter des mécanismes d'authentification externe.
• mettre en place une session applicative : lorsque votre application hérite des attributs issus de Shibboleth, vous pouvez initier une session applicative indépendante de la session Shibboleth. Ainsi vous ne dépendez pas de la durée de session du Service Provider. Vous devez donc :
  • donner la priorité à une session applicative (par rapport à une session Shibboleth) dans votre code ;
  • vous devrez stocker les attributs utilisateur associés à la session utilisateur
• WAYF intégré : la brique WAYF (menu déroulant listant les fournisseurs d'identités) peut être intégrée dans votre application en exploitant les mécanismes de lazy session de Shibboleth.
• architecture proxy : si vous n'avez pas la possibilité de modifier une application, il reste envisageable de mimer un autre type d'authentification avec un serveur proxy.
• désactiver l'utilisation des mots de passe : avec les mécanismes de fédération d'identités votre application ne recueille plus le mot de passe de l'utilisateur. Vous devez donc désactiver la bannière de login, les fonctions de rappel (ou de réinitialisation) des mots de passe.
• besoin d'un mot de passe : si votre application a besoin de manipuler un mot de passe, vous pouvez générer un mot de passe aléatoire (qui ne sera pas utilisé).
• nommage des attributs utilisateur : lors de vos échanges avec des fournisseurs d'identités, mentionnez l'identifiant SupAnn d'un attribut (exemple : supannAffectation) et pas le champ d'en-tête HTTP qui peut être spécifique à votre fournisseur de services.
• gestion des erreurs : Shibboleth est une architecture distribuée ; l'utilisateur peut être confronté à des erreurs à différents niveaux. Il est donc particulièrement essentiel de fournir à l'utilisateur des messages d'erreur compréhensibles avec des éléments pour l'aider à s'en sortir. Si par exemple votre application n'a pas reçu l'adresse email nécessaire, le message d'erreur pourra mentionner votre établissement de rattachement ne nous a pas transmis votre adresse email, veuillez reporter le problème à l'administrateur de l'application.
• paramétrage : éviter de définir les noms d'attributs Shibboleth en dur dans l'application, mais plutôt les rendre configurable dans un fichier à part.
• attributs multi-valués : votre fournisseur de service peut recevoir des attributs multi-valués. Dans ce cas, l'application accède aux valeurs de l'attributs regroupées dans une même variable d'environnement, les valeurs étant séparées par le caractère ;.
• navigation : avant de rediriger l'utilisateur vers le WAYF ou vers son fournisseur d'identités, il est nécessaire de mémoriser la page exacte à laquelle il voulait accéder. Ainsi, à l'issue de l'authentification, on pourra rediriger l'utilisateur vers la page demandée et non vers la page d'accueil du service.