Configuration du SP Shibboleth

Le SP Shibboleth est composé de 2 parties logicielles :
  • Un module apache mod_shib
  • Un serveur autonome shibd


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

Nom de votre machine :

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.


Obserrvez le fichier de configuration /etc/httpd/conf.d/shib.conf, mis en place automatiquement par l'installation du RPM :

/etc/httpd/conf.d/shib.conf
[...]
<Location /Shibboleth.sso>
  AuthType None
  Require all granted
</Location>
[...]
<Location /secure>
  AuthType shibboleth
  ShibRequestSetting requireSession 1
  require shib-session
</Location>

Les blocs Location délimitent des contextes au sein de la configuration Apache, permettant de préciser la portée des directives imbriquées. Une directive Location correspond à un contexte basé sur l'URL (plus précisément: sur le chemin d'une URL) utilisée pour accéder à une ressource : toute URL dont le chemin commence par /secure (https://monposte.fr/secure, par exemple) correspond au premier contexte. Toute URL dont le chemin commence par /Shibboleth.sso (https://monposte.fr/Shibboleth, par exemple), correspond au second contexte. Le répertoire /var/www/html/secure existant sur le système de fichier, un bloc Directory aurait également pu être utilisé à la place du premier.

Les directives AuthType et Require sont des directives d'autorisation et de contrôle d'accès d'Apache. La première spécifie le module en charge de l'authentification, mod_shib en l'occurence, la deuxième spécifie le critère d'accès requis, à savoir que seuls les utilisateurs authentifiés seront autorisés.

Pour /Shibboleth.sso, il n'est pas indispensable d'utiliser la directive SetHandler shib dans une configuration basique : Apache se charge seul de router correctement la requête. Le seul impératif ici, est que les URL commençant par /Shibboleth.sso soient accessibles sans authentification. Une directive SetHandler shib indiquerait que le traitement des URLs correspondant à ce contexte est déléguée à un gestionnaire de contenu particulier, mod_shib. en l'occurence.

Seule la directive ShibRequestSetting requireSession 1 est spécifique à Shibboleth, et configure le SP en mode bloquant (par opposition au mode lazy session, présenté plus tard), à savoir qu'une session Shibboleth doit être créé dès le premier accès à ce contexte.

L'ancienne directive Require valid-user est remplacée depuis la version 2.5.2 du SP Shibboleth par la directive Require shib-session.
La liste exacte des modalités de contrôle d'accès disponibles est documentée ici : https://wiki.shibboleth.net/confluence/display/SP3/htaccess

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 https://git.renater.fr/anonscm/git/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
$> git clone https://git.renater.fr/anonscm/git/partage-fede/formation.git
$> cd formation/sp/etc/shibboleth
$> sudo cp * /etc/shibboleth/
$> sudo mkdir /var/www/html/secure
$> cd
$> sudo cp formation/sp/var/www/html/secure/* /var/www/html/secure/


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 que vous devez mettre à jour ; 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 subject-id pairwise-id persistent-id"
      cipherSuites="DEFAULT:!EXP:!LOW:!aNULL:!eNULL:!DES:!IDEA:!SEED:!RC4:!3DES:!kRSA:!SSLv2:!SSLv3:!TLSv1:!TLSv1.1">
 
    **<!-- 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"** >
 
      **<!-- Nous mettons ici en place une relation bilatérale : le SP ira toujours déléguer l'authentification à votre IDP -->**
      **<!--**
      <SSO discoveryProtocol="SAMLDS" discoveryURL="https://discovery.renater.fr/test"> 
          SAML2
      </SSO>
      **-->**
      **<SSO entityID="https://monposte.fr/idp/shibboleth">**
          **SAML2**
      **</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"/>
    </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"**
      helpLocation="/about.html"
      styleSheet="/shibboleth-sp/main.css"/>
 
    <!-- Meta-données de votre IDP -->
    <MetadataProvider type="XML"
      url=**"https://monposte.fr/idp/shibboleth"**
      backingFilePath=**"metadata-monposte.fr.xml"** reloadInterval="7200">
    </MetadataProvider>
    ...
    <!-- Simple file-based resolvers for separate signing/encryption keys. -->
    <CredentialResolver type="File" use="signing"
        key="sp-signing-key.pem" certificate="sp-signing-cert.pem"/>
    <CredentialResolver type="File" use="encryption"
        key="sp-encrypt-key.pem" certificate="sp-encrypt-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 diriger tous les utilisateurs vers votre IdP. Ce n'est donc pas une utilisation fédérée. Cela sera vu plus tard. Le protocole utilisé sera de préférence 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 l'IDP et mettons en place une relation bilatérale. 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. ; voir chapitre relatif au proxy SP. 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.

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

Les méta-données utilisées par le SP ici se limitent à celles de l'IdP. Nous verrons plus tard comment mettre en place la fédération.

Sur RedHat 6.x et 7.x (et toutes les distributions dérivées, dont CentOS), l'éditeur a choisi, pour des raisons de license, de privilégier la bibliothèque cryptographique Nescape Security Services, plutôt qu'OpenSSL. Ce choix rend le paquetage libcurl de la distribution incompatible avec le SP, c'est pourquoi le consortium Shibboleth fournit un paquetage alternatif libcurl-openssl, compilé avec OpenSSL. Par contre, comme ce paquetage installe la bibliothèque dans l'emplacement non-standard /opt/shibboleth/lib64, il faut passer la variable d'environnement LD_LIBRARY_PATH lors du lancement de shibd. Plus d'informations ici https://wiki.shibboleth.net/confluence/display/SP3/LinuxRH6.

Dans le cas d'un lancement via le service systemd, ceci est déjà prévu, et il n'y a rien à faire:

$> sudo systemctl start shibd

Par contre, dans le cas d'un lancement manuel, par exemple pour vérifier la syntaxe du fichier de configuration, il faut penser à le faire:

$> sudo /usr/sbin/shibd -tc /etc/shibboleth/shibboleth2.xml
2019-09-11 14:55:48 CRIT XMLTooling.Config : libcurl lacks OpenSSL-specific options, this will greatly limit functionality
overall configuration is loadable, check console for non-fatal problems

$> sudo LD_LIBRARY_PATH=/opt/shibboleth/lib64 /usr/sbin/shibd -tc /etc/shibboleth/shibboleth2.xml
overall configuration is loadable, check console for non-fatal problems
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.

Démarrez Apache :

$> sudo systemctl restart httpd

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

$> systemctl status httpd
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
   Active: active (running) since mer. 2019-09-11 13:21:23 CEST; 1h 44min ago
     Docs: man:httpd(8)
           man:apachectl(8)
 Main PID: 30498 (httpd)
   Status: "Total requests: 6; Current requests/sec: 0; Current traffic:   0 B/sec"
    Tasks: 31
   Memory: 48.9M
   CGroup: /system.slice/httpd.service
           ├─30498 /usr/sbin/httpd -DFOREGROUND
           ├─30913 /usr/sbin/httpd -DFOREGROUND
           ├─30914 /usr/sbin/httpd -DFOREGROUND
           ├─30924 /usr/sbin/httpd -DFOREGROUND
           ├─30925 /usr/sbin/httpd -DFOREGROUND
           ├─30926 /usr/sbin/httpd -DFOREGROUND
           ├─30928 /usr/sbin/httpd -DFOREGROUND
           ├─30929 /usr/sbin/httpd -DFOREGROUND
           ├─30930 /usr/sbin/httpd -DFOREGROUND
           ├─30931 /usr/sbin/httpd -DFOREGROUND
           └─30932 /usr/sbin/httpd -DFOREGROUND

$> systemctl status shibd
● shibd.service - Shibboleth Service Provider Daemon
   Loaded: loaded (/usr/lib/systemd/system/shibd.service; disabled; vendor preset: disabled)
   Active: active (running) since mer. 2019-09-11 14:34:25 CEST; 2s ago
     Docs: https://wiki.shibboleth.net/confluence/display/SP3/Home
 Main PID: 31120 (shibd)
    Tasks: 5
   Memory: 12.2M
   CGroup: /system.slice/shibd.service
           └─31120 /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.

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

Afin que votre IDP fasse confiance au SP, il est nécessaire que celui-ci récupère également ses méta-données. Il s'agit donc de faire la même chose que précédemment (Configurer une relation bilatérale entre votre IdP et un service non fédéré).
Il faut ajouter la récupération des méta-données du SP dans l'IDP :

/opt/shibboleth-idp/conf/metadata-providers.xml
  <MetadataProvider id="SP-TP"
    xsi:type="FileBackedHTTPMetadataProvider"
    backingFile="%{idp.home}/metadata/sp-tp.xml"
    disregardTLSCertificate="true"
    metadataURL="https://monposte.fr/Shibboleth.sso/Metadata">
  </MetadataProvider>

Puis recharger les méta-données de l'IdP :

$> /opt/shibboleth-idp/bin/reload-service.sh -id shibboleth.MetadataResolverService
Configuration reloaded for 'shibboleth.MetadataResolverService'

Vous pouvez à présent tester la relation bilatérale en accédant à l'URL https://monposte.fr/secure.

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**
  • federation/documentation/guides-installation/sp3/chap04.txt
  • Dernière modification : 2021/03/03 15:26
  • de guillaume.rousse@renater.fr