Page en cours de relecture

4. Configuration du SP Shibboleth dans la fédération

Le SP Shibboleth est composé de 2 parties logicielles :

  • Un module apache mod_shib
  • Un programme serveur shibd


Afin d'adapter le contenu de cette page avec le nom de votre serveur, saisissez-le ici :

Nom de votre machine :

4.1. Configuration d'Apache (mod_shib)

Documentation Shibboleth : https://wiki.shibboleth.net/confluence/display/SP3/Apache

La brique SP est livrée avec plusieurs exemples de configuration Apache selon le numéro de version de celui-ci. Par défaut, la configuration de mod_shib est installée sous le répertoire /etc/httpd/conf.d sous le nom de shib.conf (identique au fichier apache24.config du répertoire /etc/shibboleth). Ce fichier indique que l'URL https://monposte.fr/secure est protégée par le SP Shibboleth. Il est chargé par défaut au démarrage de Apache.


Editez le fichier de configuration /etc/shibboleth/shib.conf pour associer à l'URL /secure le script /etc/shibboleth/shibenv.php qui affichera les attributs utilisateurs reçus par le SP Shibboleth (pour le moment ce script n'est pas installé sur le poste, nous allons le faire plus tard). C'est grâce à cette affichage que nous pourrons vérifier que la brique SP fonctionne bien.

| /etc/httpd/conf.d/shib.conf
  **ScriptAlias /secure /etc/shibboleth/shibenv.php**
  <Location /secure>
    AuthType shibboleth
    ShibRequestSetting requireSession 1
    **ShibRequestSetting applicationId default**
    require shib-session
  </Location>
  **## Activation globale de l'authentification Shibboleth**
  **## C'est nécessaire pour activer les handlers**
  **<Location /> **
    **AuthType shibboleth**
    **Require shibboleth**
  **</Location> **

La directive AuthType shibboleth permet d'activer le module Shibboleth (mod_shib) lors des requêtes vers l'URL https://monposte.fr/secure. La directive ShibRequestSetting requireSession 1 indique à ce module qu'une session Shibboleth doit être déclenchée à la première requête sur cette URL (on désactive ce comportement quand on utilise le mode lazy sessions, présenté plus tard). La directive ShibRequestSetting applicationId default assure le « routage » des requêtes HTTP vers le bon contexte applicatif du SP Shibboleth (shibd). Enfin la directive require shib-session permet de s'assurer que seuls les utilisateurs authentifiés pourront accéder à https://monposte.fr/secure.

L'ancienne directive require valide-user est remplacée depuis la version 2.5.2 du SP Shibboleth par la directive require shib-session, voir cette documentation.
La liste exacte des directives autorisées est disponible ici : https://wiki.shibboleth.net/confluence/display/SP3/htaccess

La brique Shibboleth est configurée via ces directives dans Apache, mais aussi (et principalement) dans un fichier de configuration dédié, shibboleth2.xml, que nous détaillons plus loin.

4.2. Configuration de la brique Shibboleth SP (shibd)

Vous allez télécharger un ensemble de fichiers de configuration personnalisés pour les besoins du TP. Ces contenus sont disponibles sur un dépôt Git accessible de manière anonyme, à l'adresse git clone git+ssh://git@git.renater.fr:2222/partage-fede/formation.git.
Les fichier situés sous sp/etc/shibboleth doivent être installés dans le répertoire /etc/shibboleth/ en lieu et place des fichiers installés par défaut par les RPM.

$ cd /tmp
$ git clone git+ssh://git@git.renater.fr:2222/partage-fede/formation.git
$ cd formation/sp/etc/shibboleth
$ cp * /etc/shibboleth/
$ mv -f conf_sp2/* /etc/shibboleth/


Il faut à présent télécharger le certificat qui permet de vérifier la signature des méta-données de la fédération Éducation-Recherche et celle de test :

$ wget https://metadata.federation.renater.fr/certs/renater-metadata-signing-cert-2016.pem \
       -O /etc/shibboleth/renater-metadata-signing-cert-2016.pem


Les fichiers HTML d'affichage d'erreurs pour l'utilisateur ont été traduits. Les fichiers de configuration de Shibboleth sont :

  • attribute-map.xml : translation des noms d'attributs contenus dans les assertions SAML envoyés par les IdP vers des en-têtes HTTP exploitables par l'application finale (cf. plus loin le chapitre « Modification de l'application pour exploiter les attributs utilisateur ») ;
  • attribute-policy.xml : politique d'acceptation des attributs envoyés par les IdP.

L'extrait de fichier de configuration ci-dessous présente les éléments de configuration les plus importants ; ils seront commentés plus bas. Les zones grisées doivent être ajoutées/modifiées.

à partir de la version 2.3, l'exemple de fichier shibboleth2.xml fourni est minimaliste. Pour avoir un exemple de fichier de configuration plus riche, consultez /etc/shibboleth/example-shibboleth2.xml.

/etc/shibboleth/shibboleth2.xml
<SPConfig ...>
  ...
  <ApplicationDefaults entityID="https://**monposte.fr**"
    REMOTE_USER="eppn persistent-id targeted-id"
    cipherSuites="HIGH:!MD5:!RC4:!aNULL">
 
    **<!-- Le paramètre handlerURL n'est pas présent par défaut -->**
    <Sessions lifetime="28800" timeout="3600" checkAddress="false" relayState="ss:mem" 
      **handlerSSL="true"** 
      **consistentAddress="true"**
      **cookieProps="https"** 
      **handlerURL="/Shibboleth.sso"** >
 
      <SSO discoveryProtocol="SAMLDS" --entityID="https://idp.example.org/idp/shibboleth"-- 
        discoveryURL="**https://discovery.renater.fr/test**">
          SAML2 SAML1
      </SSO>
      ...
      <!-- Extension service that generates "approximate" metadata based on SP configuration. -->
      <Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>
 
      <!-- Status reporting service. -->
      <Handler type="Status" Location="/Status" acl="127.0.0.1 ::1 193.49.159.128/26 194.57.5.33"/>
    </Sessions>
    ...
    <Errors supportContact="root@localhost"
      **metadata="metadataError_fr.html"**
      **access="accessError_fr.html"**
      **ssl="sslError_fr.html"**
      **localLogout="localLogout_fr.html"**
      **globalLogout="globalLogout_fr.html"**
      logoLocation="/shibboleth-sp/logo.jpg"
      styleSheet="/shibboleth-sp/main.css"/>
 
    <!-- Meta-données de la fédération de Test RENATER -->
    <MetadataProvider type="XML" 
      url=**"https://metadata.federation.renater.fr/test/preview/preview-all-renater-test-metadata.xml"**
      backingFilePath=**"preview-all-renater-test-metadata.xml"** reloadInterval="7200">
      <MetadataFilter type="Signature" certificate=**"renater-metadata-signing-cert-2016.pem"**/>
    </MetadataProvider>
    ...
    <!-- Simple file-based resolver for using a single keypair. -->
    <CredentialResolver type="File" key="sp-key.pem" certificate="sp-cert.pem" />
  </ApplicationDefaults>
  ...
</SPConfig>

Voici quelques explications sur les principaux éléments de la configuration shibboleth2.xml :

Le nœud ApplicationDefaults définit la configuration du comportement de Shibboleth pour une application. Voici quelques éléments importants :

  • entityID est l'identifiant unique qui permet de distinguer l'application au sein de la fédération. Vous saisirez la valeur de entityID lorsque vous déclarerez votre SP dans la fédération de test. Nous recommandons un identifiant pérenne et sans référence au logiciel Shibboleth. Dans cette utilisation l'URL est juste un nom, elle n'est jamais « résolue ».
  • handlerURL (valeur par défaut : /Shibboleth.sso) est une base d'URL (absolue ou relative) qui doit être distincte pour chaque application (Application au sens Shibboleth, c'est à dire une ou plusieurs applications qui ont le même besoin en attributs utilisateurs). Nous verrons plus tard que les URL d'initiation de session ou de logout sont construites avec le handlerURL comme base.
  • SSO : anciennement défini par le paramètre SessionInitiator. Ce paramètre décrit comment Shibboleth réagit à une requête de session pour cette application, c'est-à-dire de quelle manière il va demander une authentification de l'utilisateur (interrogation directe d'un IdP donné, passage par un DS/WAYF, etc.). Dans notre exemple, le SP va utiliser de préférence le protocole SAML2. Si l'IdP avec lequel le SP communique ne connait que le protocole SAML1, le SP se rabattra sur cette version du protocole.
  • Handler type=“Status” Location=”/Status” est une URL (relative à handlerURL) qui renvoie un rapport du statut opérationnel du SP au format xml. On accède ainsi à quelques options de configuration, ainsi qu'aux métadonnées du SP. Certaines des informations retournées peuvent être considérées comme confidentielles : un accès limité à cette URL doit donc être garanti. Les hosts autorisés sont filtrés avec la directive acl suivie d'une liste d'adresses IP séparées par un espace (on pourra y inclure un serveur de supervision comme Nagios par exemple).
  • Handler type=“MetadataGenerator” Location=”/Metadata” est une URL (relative à handlerURL) qui renvoie les méta-données du SP au format XML. Cette URL peut (doit) être accessible sans restriction, afin de :
    • Permettre à un IDP de récupérer directement ces méta-données, dans le cas d'une relation bi-latérale
    • Remplir automatiquement les informations techniques du SP sur le guichet de la fédération
  • CredentialResolver : spécifie le certificat et la clé privée utilisés pour signer les assertions SAML.
  • MetadaProvider/url : permet de spécifier le fichier de méta-données qui est utilisé par l'application. Nous utilisons ici les méta-données de la fédération de test. Elles sont rechargées automatiquement toutes les deux heures par défaut (paramètre reloadInterval).

Il est possible de protéger d'autres applications sur le même serveur avec la même brique Shibboleth. Pour ajouter une nouvelle application, on ajoute un nœud ApplicationOverride avec ses propres éléments entityID, handlerURL, SessionInitiator, etc. ; voir https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationOverride. En fin de TP vous pourrez éventuellement tester cette possibilité.

Une copie locale de chaque fichier de méta-données distants est maintenue, cf le paramètre MetadataProvider/backingFilePath dans l'exemple ci-dessus. Depuis la version 2.4 du SP Shibboleth ces fichiers sont stockés dans le répertoire /var/cache/shibboleth/ ; depuis cette même version du SP Shibboleth le démon shibd ne s'exécute plus sous l'identité root, mais shibd.

4.2.1. Les méta-données

La documentation de référence : https://wiki.shibboleth.net/confluence/display/SP3/MetadataProvider

Les méta-données de la fédération de test sont regroupées dans le fichier preview-all-renater-test-metadata.xml qui liste tous les membres de cette fédération. Pour qu'un fournisseur de services soit reconnu dans une fédération par les fournisseurs d'identités, il doit être listé dans ce fichier. Inversement, pour qu'un fournisseur d'identités soit reconnu dans la fédération par des fournisseurs de services, il doit être listé dans les méta-données. Le fichier de méta-données inclut également les certificats de chaque entité.

Les méta-données constituent donc le socle de la confiance d'une fédération. Pour assurer leur intégrité le fichier des méta-données est signé électroniquement. Dans une fédération en production, l'enregistrement d'un nouveau fournisseur ou la mise à jour des informations d'un fournisseur existant est soumis à un processus permettant de vérifier la validité et la légitimité de la demande.

Pour chaque fournisseur, les méta-données indiquent son identifiant unique (attribut entityID), des adresses de contact organisationnel et technique, le certificat utilisé par ce fournisseur, l'adresse du SSO pour un fournisseur d'identités et l'adresse de réception des attributs pour un fournisseur de services.

Il n'est pas nécessaire de mettre à jour les méta-données de votre SP puisque votre fichier de configuration shibboleth2.xml pointe directement vers un fichier hébergé sur le serveur de RENATER et mis à jour à chaque ajout/modification/suppression d'un IdP ou SP. Le SP se charge par défaut de le télécharger toute les 2 heures. C'est un plus par rapport aux versions 1.3.x de Shibboleth qui nécessitaient un processus de synchronisation et de vérification de signature spécifique du fichier de méta-données.

Relations bilatérales : pour des besoins locaux, un IdP et un SP peuvent se faire confiance mutuellement, en échangeant leur fichier de méta-données respectifs. Une fédération à deux

Publication des méta-données : le SP Shibboleth 3.x publie automatiquement ses méta-données à l'adresse https://monposte.fr/Shibboleth.sso/Metadata. Vous pouvez utiliser cette URL pour des relations bilatérales avec un IdP ou pour vous enregistrer dans une fédération.

Dans le chapitre « Enregistrement dans la fédération de test » vous enregistrerez en ligne votre fournisseur dans la fédération de test. Il apparaitra alors dans les méta-données de cette fédération.

4.2.2. ApplicationDefaults et ApplicationOverride

Documentation de référence : https://wiki.shibboleth.net/confluence/display/SP3/ApplicationDefaults

La notion d'application ici ne correspond pas à une application au sens ou on peut l'entendre. Il s'agit plutôt de la notion de contexte applicatif ; c'est à dire un ensemble de paramétrage (entityID, méta-données utilisées, attributs utilisateurs attendus, etc.) communs à un ensemble d'applications.

Concrètement vous devrez créer autant d'éléments ApplicationOverride que de groupes d'applications qui partagent les caractéristiques suivantes :

  • applications accédées via un même nom de serveur ;
  • applications permettant l'authentification depuis une même liste d'IdP ;
  • applications utilisant un même ensemble d'attributs utilisateurs.

Un ensemble d'application partageant un ApplicationOverride partagera le même identifiant (entityId) et sera visible comme un même SP auprès du guichet de la fédération.

Il est recommandé de n'utiliser le niveau ApplicationDefaults que pour définir des paramètres communs à chaque contexte applicatif, ainsi vous gardez la configuration par défaut de vos applications entre les balises <ApplicationDefaults>.

4.2.3. Aiguiller les requêtes

Documentation de référence : https://wiki.shibboleth.net/confluence/display/SP3/ApplicationOverride

Une fois définis des contextes applicatifs dans /etc/shibboleth/shibboleth2.xml (définis par ApplicationDefaults ou ApplicationOverride), il est nécessaire d'aiguiller les requêtes HTTP vers l'un d'entre eux. Cet aiguillage peut être défini de deux manières :

  • dans la configuration Apache
  • dans le fichier /etc/shibboleth/shibboleth2.xml (RequestMapper)

Configuration de l'aiguillage via Apache vs Shibboleth RequestMapper :
Les deux modes de configuration sont équivalents ; le RequestMapper Shibboleth a été créé pour permettre le routage des requêtes en environnement IIS.
Les développeurs de Shibboleth recommandent cependant d'utiliser la configuration depuis le contexte Apache au lieu du RequestMapper. En effet, la syntaxe du RequestMapper est parfois ambigüe. Un autre argument en faveur du mode de configuration Apache: il permet à des gestionnaires d'applications d'activer l'authentification Shibboleth, sans devoir intervenir dans le fichier de configuration principal du SP Shibboleth.

4.2.3.1. Aiguiller via la configuration Apache

L'aiguillage depuis la configuration d'Apache consiste à faire référence à un contexte applicatif (“default” ou ApplicationID) via la directive de configuration ShibRequestSetting applicationId.

  <Location /secure> 
    AuthType shibboleth 
    ShibRequestSetting requireSession 1
    ShibRequestSetting applicationId **default**
    require shib-session 
  </Location> 

4.2.3.2. Aiguiller via la configuration Shibboleth

La documentation Shibboleth explique comment effectuer le paramétrage de l'aiguillage via la configuration Shibboleth :

4.3. Informations complémentaires pour la brique SP

4.3.1. Configuration des logs

Le fichier gérant le niveau de log est /etc/shibboleth/shibd.logger. Il est référencé par /etc/shibboleth/shibboleth2.xml.
Le niveau de log est par défaut à INFO car le SP est très verbeux en mode DEBUG.
Pour faciliter le débogage dans un premier temps vous pouvez éditer le fichier shibd.logger pour le mettre en DEBUG.

| /etc/shibboleth/shibd.logger
# set overall behavior
log4j.rootCategory=**DEBUG**, shibd_log
...
# tracing of SAML messages and security policies
**log4j.category.OpenSAML.MessageDecoder=DEBUG**
**log4j.category.OpenSAML.MessageEncoder=DEBUG**
# To log decrypted SAML assertions
**log4j.category.Shibboleth.SSO.SAML2=DEBUG**

4.4. Lancement de Apache et de shibd

Problème avec RedHat et CentOS 6.x et 7.x : le SP est incompatible avec cette version de l'OS à cause de la version de la bibliothèque libcurl utilisée. En effet RedHat a compilé libcurl sur la base de Nescape Security Services et non plus OpenSSL. Ce changement casse le fonctionnement du SP. Shibboleth distribue un paquet libcurl-openssl utilisé par Shibboleth via le positionnement de la variable d'environnement LD_LIBRARY_PATH dans /etc/systemd/system/multi-user.target.wants/shibd.service. Mais si vous exécutez directement un script (shibd -tc ou resolvertest), vous devrez positionner la variable d'environnement LD_LIBRARY_PATH. Lire la documentation du consortium Shibboleth

Erreur « Unknown cipher in list: ALL:!aNULL:!LOW:!EXPORT:!SSLv2 » : cette erreur est liée à l'utilisation de la bibliothèque libcurl évoquée ci-dessus.

Sur une machine 64 bits (supprimer le '64' sur une machine 32 bits) :

$ vi /etc/systemd/system/multi-user.target.wants/shibd.service
[Unit]
Description=Shibboleth Service Provider Daemon
Documentation=https://wiki.shibboleth.net/confluence/display/SP3/Home
After=network.target
Before=httpd.service
 
[Service]
Type=notify
NotifyAccess=main
User=shibd
**Environment=LD_LIBRARY_PATH=/opt/shibboleth/lib64**
ExecStart=/usr/sbin/shibd -f -F
StandardInput=null
StandardOutput=null
StandardError=journal
TimeoutStopSec=1m
TimeoutStartSec=5m
Restart=on-failure
RestartSec=30s
 
[Install]
WantedBy=multi-user.target


Démarrez Apache :

$ systemctl restart httpd


Vérifiez que la syntaxe de votre configuration shibboleth2.xml est correcte :

$ /usr/sbin/shibd -tc /etc/shibboleth/shibboleth2.xml
 
  overall configuration is loadable, check console for non-fatal problems

Démarrage du démon shibd :

$ systemctl start shibd
Démarrage de shibd :                                       [  OK  ]


Vérifiez que les processus sont bien lancés :

$ ps auwx | grep httpd
 
root      3277  0.0  5.9 477468 29908 ?        Ss   15:23   0:00 /usr/sbin/httpd -DFOREGROUND
apache    3284  0.0  2.8 628732 14404 ?        Sl   15:23   0:00 /usr/sbin/httpd -DFOREGROUND
apache    3285  0.0  2.8 628732 14404 ?        Sl   15:23   0:00 /usr/sbin/httpd -DFOREGROUND
apache    3286  0.0  2.8 628732 14404 ?        Sl   15:23   0:00 /usr/sbin/httpd -DFOREGROUND
apache    3287  0.0  2.8 628732 14404 ?        Sl   15:23   0:00 /usr/sbin/httpd -DFOREGROUND
apache    3288  0.0  2.8 628732 14404 ?        Sl   15:23   0:00 /usr/sbin/httpd -DFOREGROUND
 
$ ps auwx | grep shib
 
shibd    18643  0.0  3.7 119428 19432 pts/0  Sl   13:17   0:03 /usr/sbin/shibd -f -F

Vous pouvez également vérifier que le démon shibd s'est correctement lancé en consultant ses logs pour vous assurer que n'apparaissent pas d'erreurs.

$ tail -f /var/log/shibboleth/shibd.log