Prérequis
Tomcat doit avoir été configuré !
Il convient également d'avoir à disposition un IdP et un SP fonctionnels.
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
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 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/ depuis la machine hébergeant le serveur Apache 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.