Page en cours de relecture

6. Installation d'un service de découverte (WAYF)

Jusque-là nous avons utilisé le service de découverte de Test associé à la fédération de Test. Pour un service en production, vous pouvez utiliser le WAYF mis à disposition par RENATER, mais vous pouvez aussi mettre en place un WAYF à vos couleurs. Vous pouvez n'installer qu'une seule instance pour les besoins de votre établissement.

L'avantage d'installer un service de découverte au plus près de vos applications est de pouvoir le mettre en conformité avec la charte graphique de l'application. De plus, il est possible de filtrer à ce niveau les fournisseurs d'identités acceptés pour votre application. Cela évite de lister des fournisseurq d'identités qui ne sont pas acceptés et laisser leurs utilisateurs s'authentifier pour se voir refuser l'accès par la suite.
Afin d'adapter le contenu de cette page avec le nom de votre serveur, saisissez-le ici :

Nom de votre machine :

6.1. Installation WAYF et configuration Apache

Nous allons installer un service de découverte en utilisant l'implémentation de SWITCH : https://www.switch.ch/aai/support/tools/wayf.html

$ cd /usr/local
$ wget -O SWITCHwayf-1.22-0001.tar.gz \
    https://gitlab.switch.ch/gip-renater/SWITCHwayf/-/archive/1.22-0001/SWITCHwayf-1.22-0001.tar.gz
$ tar -zxf SWITCHwayf-1.22-0001.tar.gz
$ ln -s SWITCHwayf-1.22-0001 SWITCHwayf
$ chown -R apache:apache SWITCHwayf


RENATER participe sporadiquement au développement du WAYF de Switch, c'est pour cela que l'URL de récupération fait référence à la fois à SWITCH et à RENATER.

Le WAYF est développé en PHP ; vous devez donc installer PHP sur le serveur. La dernière version du WAYF nécessite une version 5.2 ou supérieure de PHP.

Le WAYF utilise les librairies DOM XML de PHP pour traiter les fichiers XML de méta-données. Il est donc nécessaire d'installer le paquet php-xml :

$ yum install php-xml

Nous allons configurer le serveur web pour ouvrir l'accès au WAYF.
Créez le fichier de configuration /etc/httpd/conf.d/wayf.conf.

| /etc/httpd/conf.d/wayf.conf
## Configuration du WAYF
Alias /wayf /usr/local/SWITCHwayf/www
<Directory /usr/local/SWITCHwayf/www>
    Options Indexes MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
 
    <Files WAYF>
      SetHandler php5-script
      AcceptPathInfo On
    </Files>
 
</Directory>

Redémarrons le serveur web :

$ systemctl reload httpd

6.2. Configuration & customisation du WAYF

L'arborescence est la suivante par défaut :

  • etc/config.dist.php : modèle pour le fichier de configuration principal,
  • lib/default-*.php : tous les fichiers php préfixés par default- sont personnalisables en dérivant un fichier ayant pour préfixe custom-*.php. Exemple : default-header.php personnalisé en custom-header.php.
  • etc/IDProvider.conf.dist.php : modèle pour le fichier qui permet de gérer manuellement des IdPs (identifiants et URL SSO). Le WAYF peut se baser directement sur ce fichier au lieu d'extraire la liste depuis un fichier de méta-données XML.
  • etc/IDProvider.metadata.conf.php : contiendra le résultat de l'exécution du script readMetadata.php
  • www/images/ : répertoire contenant des images pour la personnalisation du WAYF
  • lib/readMetadata.php : ce script extrait la liste des IdP (Identifiant et URL SSO) d'un fichier de méta-données en XML spécifié dans config.php
  • www/WAYF : le script php métier qui gère les redirections HTTP, positionnement de cookies du WAYF ainsi que la gestion du “embedded WAYF”

6.3. IDProvider.conf.php VS méta-données.xml

Le WAYF propose deux modes de fonctionnement :

  • extraction de la liste des IdP depuis un fichier de méta-données au format SAML 2. ;
  • définition de la liste des IdP dans un fichier IDProvider.conf.php.

La première solution évite de devoir gérer la liste des IdP (adapté pour lister tous les IdP d'une fédération).

La seconde a pour avantage de permettre aux SPs utilisant le WAYF de ne garder que les IdP qu'elle reconnait et de les présenter de façon catégorisée, voir l'exemple de SWITCH : https://aai-demo.switch.ch/secure/.

Le fichier IDProvider.conf.php permet également de gérer des exceptions, comme nous allons le voir avec les Comptes CRU.

6.4. Configuration

Nous allons configurer le WAYF pour utiliser les méta-données de la fédération de test.

$ cd /usr/local/SWITCHwayf/etc
$ cp IDProvider.conf.dist.php IDProvider.conf.php
$ cp config.dist.php config.php

Adaptez le fichier de configuration config.php :

| config.php
  ...
  // Domain within the WAYF cookie shall be readable. Must start with a .
**  $commonDomain = '.monposte.fr'; **
  ...
  // Set to true in order to enable dynamic generation of the IdP list displayed
**  $useSAML2Metadata = true; **
  ...
  // If true, the users IP is used for a reverse DNS lookup whose
  // resulting domain name then is matched with the URN values of the IdPs
**  $useReverseDNSLookup = true;**
 
  // Whether the JavaScript required for embedding the WAYF
  // on a remote site shall be generated or not
**  $useEmbeddedWAYF = true;**
  ...
 
  // Les logs du wayf sont stockés dans le répertoire de log d'apache
**  $WAYFLogFile = '/var/log/shibboleth/wayf.log';**
  ...
 
  // Use $metadataFile as source federation's metadata.
  // Nous pointons vers le fichier de méta-données maintenu à jour
  // par la brique SP Shibboleth
**  $metadataFile = '/var/cache/shibboleth/preview-all-renater-test-metadata.xml'; **

6.5. Modification du fichier shibboleth2.xml :

Nous allons modifier la configuration du SP pour utiliser notre nouveau service WAYF.

/etc/shibboleth/shibboleth2.xml
            <SSO discoveryProtocol="SAMLDS" discoveryURL=**"https://monposte.fr/wayf/WAYF"**>
              SAML2 SAML1
            </SSO>

Redémarrons le serveur web et le démon shibd pour prendre en compte le changement de configuration:

$ systemctl reload httpd
$ systemctl restart shibd 

Vous pouvez tester le bon fonctionnement du WAYF en accédant à https://monposte.fr/secure/.

Vous remarquerez l'organisation particulière des IdP dans le menu déroulant ; cette organisation est due au fichier de configuration IDProvider.conf.php.

Erreur : Le fournisseur de service ne pouvait pas être trouvé dans les méta-données
En effet dans le cadre du TP le WAYF consomme la copie locale des méta-données du SP. Il se peut que votre SP n'a pas rechargé les méta-données de la Fédération de Test depuis l'inscription de votre SP via le guichet de la fédération.

Pour forcer le rechargement des méta-données :

  1. supprimez la copie locale /var/cache/shibboleth/preview-all-renater-test-metadata.xml
  2. redémarrez le SP (systemctl restart shibd)

Complétion automatique : vous remarquerez la fonctionnalité de complétion du fournisseur d'identités dans la barre du menu.

6.6. Utilisation des Comptes CRU

L'IdP des Comptes CRU fait partie par défaut de la Fédération de test mais n'est pas présent dans les méta-données de la fédération Éducation-Recherche. En effet, ce fournisseur d'identités, contrairement à ceux opérés par les établissements d'enseignement supérieur, n'a pas de périmètre délimité : n'importe qui peut ouvrir un compte CRU. Conséquence de ce mode de fonctionnement : le nombre d'attributs utilisateurs fournis par l'IdP des Comptes CRU est limité (nom, prénom, adresse email, eduPersonPrincipalName, persistentID).

Au moment de passer votre SP en production, vous pouvez choisir d'ajouter la confiance dans les Comptes CRU, afin d'ouvrir l'accès aux personnes extérieures ou ne disposant pas encore d'un IdP Shibboleth dans leur établissement. Pour cela vous devez configurer votre SP Shibboleth mais également votre service de découverte.

Voir la documentation de mise en oeuvre