accueilRessourcesLogiciels
 

Installation d’un Service Provider Shibboleth


Introduction

Un Service Provider Shibboleth (abrégé en SP dans la suite) sert à gérer la partie authentification d’une application web. C’est en quelque sorte une sur-couche par dessus l’application en elle même. L’application n’a pas forcément besoin d’être "compatible" Shibboleth. Un SP est associé à un Virtual Host Apache, il peut donc y avoir plusieurs SP sur une même machine.

Pour faire fonctionner notre SP, il y a deux éléments à installer sur notre serveur : un module Shibboleth pour Apache et un démon Shibboleth. Cette documentation s’appuie sur l’excellent support de TP de la fédération Renater accessible à cette URL : https://federation.renater.fr/docs/...

Pré-requis

Ajout du dépôt Shibboleth maintenu par OpenSUSE :

wget -O /etc/yum.repos.d/security_shibboleth.repo http://download.opensuse.org/repositories/security://shibboleth/RHEL_6/security:shibboleth.repo
echo "protect=1" >> /etc/yum.repos.d/security_shibboleth.repo
wget -O /etc/pki/rpm-gpg/RPM-GPG-KEY-shibboleth-security http://download.opensuse.org/repositories/security:/shibboleth/RHEL_6/repodata/repomd.xml.key
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-shibboleth-security

Installation des paquets

Pour une machine 64 bits, on installe les paquets suivants :

yum install xmltooling.x86_64  log4shib xerces-c.x86_64 xml-security-c.x86_64 xmltooling.x86_64 opensaml.x86_64 shibboleth.x86_64

Pour une machine 32 bits :

yum install xmltooling.i386  log4shib xerces-c.i386 xml-security-c.i386 xmltooling.i386 opensaml.i386 shibboleth.i386

On oublie pas d’activer le démon shibboleth au démarrage :

chkconfig shibd on

Création du certificat auto-signé

On génère la clé et son certificat pour la machine :

openssl genrsa 1024 > /tmp/<nom_serveur>.key
openssl req -new -x509 -nodes -sha1 -days 7300 -subj "/C=FR/O=<DOMAINE>/CN=<nom_serveur>" -key /tmp/<nom_serveur>.key > /tmp/<nom_serveur>.crt
openssl x509 -noout -fingerprint -text < /tmp/<nom_serveur>.crt >> /tmp/<nom_serveur>.crt

On les déplace dans le dossier Shibboleth :

mv /tmp/<nom_serveur>.key /etc/shibboleth
mv /tmp/<nom_serveur>.crt /etc/shibboleth

Configuration du démon Shibd

On récupère des fichiers de conf préparés pour la fédération Renater :

cd /etc/
cp -pr shibboleth shibboleth.dist
cd /tmp/
wget https://services-federation.renater.fr/exemples/conf_sp2_renater.tar.gz
tar zxvf conf_sp2_renater.tar.gz
mv -f conf_sp2/* /etc/shibboleth/

On récupère le certificat qui signe les méta-données de la fédération :

wget https://services-federation.renater.fr/metadata/metadata-federation-renater.crt -O /etc/shibboleth/metadata-federation-renater.crt

On édite le fichier de configuration principal de shibd :

vim /etc/shibboleth/shibboleth2.xml

On modifie l’URL de l’application par défaut :

<ApplicationDefaults entityID="https://<cname>.<domaine>/sp"
                      REMOTE_USER="mail eppn persistent-id targeted-id">

On modifie l’URL vers le service WAYF :

<SSO location="/" discoveryProtocol="SAMLDS" discoveryURL="https://services-federation.renater.fr/validation/wayf">

Remplacer la directive Error par :

<Errors supportContact="<admin>@<domaine>" 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"/>

On déclare les méta-données de la fédération :

       <!-- Meta-données de la fédération de test Éducation-Recherche -->
       <MetadataProvider type="XML" uri="https://services-federation.renater.fr/metadata/renater-metadata.xml" backingFilePath="/etc/shibboleth/renater-metadata.xml" reloadInterval="7200">
               <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
               <MetadataFilter type="Signature" certificate="metadata-federation-renater.crt"/>
       </MetadataProvider>

Enfin, on configure le chemin vers le certif auto-signé et sa clé :

<CredentialResolver type="File" key="<nom_serveur>.key" certificate="<nom_serveur>.crt" />

Configuration du VirtualHost Apache

Exemple 1 - Autoriser tous les utilisateurs connectés

Ce cas est le plus courant, on laisse passer les utilisateurs connectés au niveau d’Apache, l’application derrière s’occupera de la gestion des accès.

Éditer le fichier de configuration du VHost à Shibboléthiser :

vim /etc/httpd/conf/vhosts/<cname>.<domaine>.conf

Ajoutez ces directives dans la directive  :

# Auth Shibb
AuthType shibboleth
ShibRequestSetting requireSession 1
ShibRequestSetting applicationId default
Require valid-user

Exemple 2 - Autoriser une liste d’utilisateurs connectés

La directive Require valid-user autorise toute personne connecté à la fédération éducation-recherche. Il est intéressant de restreindre l’accès, pour cela on va filtrer les REMOTE_USER en se basant sur un fichier de groupe.

On crée le fichier de groupe :

vim /etc/httpd/conf/groups.conf

La syntaxe du fichier est la suivante (un groupe par ligne) :

<nom_groupe1>: <remote_user1> <remote_user2> <remote_user3> ...

Éditer le fichier de configuration du VHost à Shibboléthiser :

vim /etc/httpd/conf/vhosts/<cname>.<domaine>.conf

Et modifier la partie authentification comme ici :

# Auth Shibb
AuthType shibboleth
ShibRequestSetting requireSession 1
ShibRequestSetting applicationId default
AuthGroupFile /etc/httpd/conf/groups.conf
Require group <nom_groupe1>

Tester sa brique SP

Relancer les services :

service shibd restart
service httpd restart

On peut tester simplement ce que renvoi l’IdP avec un petit script php :

cd /var/www/<cname>/
vim index.php

Contenu du script :

<?php
echo "<pre>";
print_r($_SERVER);
echo "</pre>";
?>

Avec un navigateur, allez sur l’URL de votre application. D’abord, vous allez être redirigé vers le WAYF, sélectionnez votre établissement. Vus êtes ensuite redirigé vers le SSO, authentifiez vous. Enfin, vous revenez sur votre application, vérifiez les infos affichées par le script php, en particulier la valeur de REMOTE_USER.

Déclarer un SP supplémentaire

Une même machine peut héberger plusieurs SP, comme pour les VirtualHost. Donc pas besoin de réinstaller Shibd et son module, par contre il faudra quand même déclarer ce nouvel SP dans la fédération d’identité que vous utilisez.

Premièrement, il faut déclarer une application supplémentaire dans le fichier shibboleth2.xml :

vim /etc/shibboleth/shibboleth2.xml

La nouvelle application va hériter automatiquement de ce qui a déjà été défini pour l’application par défaut. Juste avant la balise , ajouter la ligne suivante :

<ApplicationOverride id="<cname2>" entityID="https://<cname2>.<domaine>/sp"/>

Ensuite, il faut éditer la configuration du VHost :

vim /etc/httpd/conf/vhosts/<cname2>.<domaine>.conf

Et ajouter la partie authentification :

# Auth Shibb
AuthType shibboleth
ShibRequestSetting requireSession 1
ShibRequestSetting applicationId <cname2>
Require valid-user

Relancer les services :

service shibd restart
service httpd restart

Trucs et astuces

Déshibboléthiser une sous arborescence

Mon application est shibboléthiser à la racine, mais j’aimerai rendre accessible le sous-dossier public/ par exemple. La configuration suivante permet de le faire :

<Directory /public/>
       Options FollowSymLinks
       AllowOverride none
       Order allow,deny
       Allow from all

       # No auth
       Satisfy Any
</Directory>

Références

Cet article se base sur les excellents supports de formation Renater disponibles ici : https://services.renater.fr/federat...

L’article d’origine sur mon blog : http://blog.gamb.fr/index.php?post/...

Contact : [Gilian.Gambini chez dsi.cnrs.fr]

Licence Creative Commons


ARESU
Direction des Systèmes d'Information du CNRS

358 rue P.-G. de Gennes
31676 LABEGE Cedex

Bâtiment 1,
1 Place Aristide Briand
92195 MEUDON Cedex



 

 

Direction des Systèmes d'Information

Pôle ARESU

Accueil Imprimer Plan du site Credits