Prérequis
Tomcat doit avoir été configuré et être branché sur un serveur Apache frontal.
Il convient également d'avoir à disposition un IdP et un SP fonctionnels, et que le mapping des attributs LDAP ait été correctement réalisé.
Une version de Shibboleth 2.x est obligatoire, pour assurer le support SAML2.
La documentation Renater fournit des tutoriels détaillés sur l'installation et la configuration d'un IdP et d'un SP Shibboleth.
Configuration Apache - mod_shib
La mise en place du SP Shibboleth sur le serveur Apache va se faire via l'activation du module mod_shib, fourni avec le SP.
Il conviendra donc d'ajouter le chargement du module à la configuration du serveur httpd :
LoadModule mod_shib $SP_HOME/lib/shibboleth/mod_shib_xx.so
Il existe plusieurs versions fournies du mod_shib, dépendantes de la version du serveur Apache utilisé. Il conviendra donc de charger le module correspondant : mod_shib_13 (Apache httpd 1.3), mod_shib_20 (Apache httpd 2.0), mod_shib_22 (Apache httpd 2.2), mod_shib_24 (Apache httpd 2.4).
Une fois le module chargé, on va pouvoir le configurer. On va dans un premier temps protéger le handler Shibboleth qui permettra, entre autre, d'obtenir des informations sur le SP :
UseCanonicalName On
ServerName localhost
<Location /Shibboleth.sso>
SetHandler shib
</Location>
On peut également ajouter un script qui permettra de tester l'identification par Shibboleth, et qui affichera les informations transmises dans le header :
ScriptAlias /secure $APACHE_HOME/cgi-bin/printenv.pl <Location /secure> AuthType shibboleth ShibRequestSetting requireSession 1 ShibRequestSetting applicationId default require valid-user </Location>
L'utilisation de ce script est expliquée dans la partie Tests de fonctionnement ci-dessous.
Enfin, il reste à protéger l'URL de login du portail pour forcer une authentification via Shibboleth quand un utilisateur accèdera à cette URL :
<Location /uPortal/Login >
AuthType shibboleth
ShibRequestSetting requireSession 1
ShibRequestSetting applicationId default
require valid-user
</Location>
Configuration uPortal
Tests de fonctionnement
Ces tests vont permettre de vérifier le bon fonctionnement et le bon paramétrage de l'IdP et du SP Shibboleth avec, successivement, la récupération d'attributs LDAP par l'IdP et la transmission de ces attributs de l'IdP au SP .
Ces étapes peuvent être suivies aussi bien avant l'installation qu'à tout moment pour déterminer l'origine d'un problème qui serait lié à l'authentification Shibboleth.
IdP
Avec l'IdP est fourni un utilitaire (aacli) qui va permettre de tester la récupération des attributs définis dans les fichiers de configuration de l'IdP attribute-resolver et attribute-filter. Il se trouve dans le répertoire /bin de l'IdP, et est décliné en deux versions : aacli.bat (Windows) et aacli.sh (Unix).
Deux paramètres sont nécessaires pour lancer l'utilitaire :
--configDir qui doit pointer vers le dossier contenant les fichiers de configuration de l'IdP (/conf en général)
--principal qui est l'identifiant utilisé pour le test.
D'autres paramètres de test peuvent être définis et sont explicités avec l'utilisation du paramètre --help.
Si un utilisateur est défini par un uid etudiant1 dans l'annuaire LDAP, et quel'IdP est configuré pour remonter les attributs uid et displayName, la commande :
(Unix) $aacli.sh --configDir=<Path>conf --principal=etudiant1 (Windows) aacli.bat --configDir=<Path>conf --principal=etudiant1
devrait produire une sortie semblable à cela :
<?xml version="1.0" encoding="UTF-8"?><saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<saml2:Attribute FriendlyName="uid" Name="urn:oid:0.9.2342.19200300.100.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">etudiant1</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="displayName" Name="urn:oid:2.16.840.1.113730.3.1.241" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Prenom Nom</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
Cela permet de vérifier que l'IdP peut bien se connecter au serveur LDAP et remonter des attributs.
SP
Pour vérifier que le SP est bien en état de fonctionnement, depuis la machine hébergeant le serveur Apache, on peut se rendre à l'url suivante : http://localhost/Shibboleth.sso/Status . Cette page devrait afficher des informations de métadonnées sur le SP, ce qui confirme son fonctionnement.
Pour vérifier que l'IdP transmet bien les éléments qu'il récupère au SP, on va utiliser la servlet de test mise en place lors de la configuration d'Apache : /secure.
Étant protégée par Shibboleth, elle va requérir une authentification, et on pourra vérifier les attributs transmis lors de cette identification.
Pour cela, il suffit d'accéder à http://localhost/secure/ pour afficher le script d'informations.
Attention : pour l'execution de ce script, Perl est nécessaire, et son chemin doit être précisé dans le script cgi-bin/printenv.pl
Une fois identifié, il est également possible d'accéder à la page de Session du SP qui affiche plus spécifiquement les attributs qui lui ont été transmis par l'IdP pour la session en cours, via l'URL http://localhost/Shibboleth.sso/Session .
Si ces attributs correspondent bien à ceux attendus, alors la communication entre IdP et SP est correcte.