Auteurs : Rafael Diaz Maurin, Florent Guilleux, Mehdi Hached, Sébastien Médard, Olivier Salaün, David Verdin
Dernière mise à jour : Septembre 2014
Un glossaire est disponible en fin de documentation
Préambule :
Commençons par déterminer le nom du poste sur lequel vous travaillez :
# hostname -f
Mettez le nom du poste ainsi obtenu dans le champ suivant :
Nom de votre machine :
Le terme IdP (pour Identity Provider) fait référence à la notion de Fournisseur d'Identités. Pour plus de précisions sur cette notion, reportez-vous au chapitre « Rôle le la brique fournisseur d'identités Shibboleth » ou au chapitre intitulé « Sources de documentation ».
Les commandes à effectuer sont écrites avec la présente police précédées du caractère # de l'utilisateur root (unix)
Public concerné : personnel technique d'un organisme d'enseignement supérieur ou de recherche mettant en place les briques Shibboleth pour leur établissement.
Durée : une journée.
Dans une architecture de fédération d'identités, la brique Fournisseur d'Identités (mentionnée sous le terme IdP dans le reste du document) est chargée d'authentifier les utilisateurs pour le compte des fournisseurs de services. Le fournisseur d'identités reçoit des requêtes d'authentification de la part du fournisseur de services, via le navigateur web de l'utilisateur. L'utilisateur sera orienté par le fournisseur d'identités, vers son serveur CAS. Une fois l'utilisateur authentifié, son profil est enrichi d'attributs extraits d'un annuaire LDAP (ou d'un autre référentiel de l'établissement). Le fournisseur d'identités renvoie une assertion SAML au fournisseur de services, toujours via le navigateur web de l'utilisateur. Les attributs utilisateur transmis au fournisseur de services permettront à ce dernier de contrôler finement l'accès à une ressource web.
La configuration de la brique fournisseur d'identités consiste à
Pour mettre le service en production, vous devrez également configurer plus finement le filtrage des attributs utilisateurs transmis à chaque fournisseur de services.
Les certificats x509 sont massivement utilisés dans la technologie de fédération d'identités. Il faut toutefois en distinguer 3 utilisations différentes :
Vous pouvez également obtenir de l'aide ou échanger dans la liste federation-utilisateurs@listes.renater.fr : https://listes.renater.fr/sympa/info/federation-utilisateur
Dans le TP nous procèderons par étapes pour aboutir à un fournisseur d'identités Shibboleth opérationnel. La première étape consistera à installer les pré-requis. Ensuite vous installerez la brique logicielle Shibboleth et vous effectuerez une configuration minimale. Une phase de tests vous permettra de valider votre installation auprès de la ressource de test. Enfin, vous pourrez explorer les possibilités offertes pour alimenter les attributs utilisateurs.
Web Developer : elle vous permet notamment de visualiser et supprimer rapidement les cookies. L'extension Tamper Data permet quand a elle de visualiser les en-têtes HTTP et les redirections du navigateur au cours. C'est très utile pour comprendre le fonctionnement de Shibboleth.Vous pouvez installer ces extensions depuis les pages https://addons.mozilla.org/fr/firefox/addon/60 et https://addons.mozilla.org/fr/firefox/addon/966. Relancez Firefox pour terminer leur installation.
Passer en compte root sur votre machine :
$ su -
# rpm -vi http://dl.fedoraproject.org/pub/epel/5/i386/emacs-nxml-mode-0.20041004-6.el5.noarch.rpm
Avant l'installation proprement dite de la brique Identity Provider Shibboleth, plusieurs composants doivent être mis en place. Nous allons vous guider dans leur installation.
Installer unzip s'il ne l'est pas :
$ yum install unzip
Nous procédons à l'installation de JAVA pour les servlets IdP et SSO-CAS.
Vérifiez tout d'abord la nature de votre distributions Linux :
# uname -a
Lancer un navigateur Internet, Firefox par exemple.
Nous choisirons le package distribué par SUN (recommandé par les développeurs) sous forme de binaire RPM. En effet, les développeurs de Shibboleth mettent en avant la non compatibilité des compilateurs GNU Java des packages natifs de CentOs ou de RHEL, voir cette documentation https://wiki.shibboleth.net/confluence/display/SHIB2/IdPInstall.
Téléchargez le RPM de JAVA Runtime Environment (JRE) de SUN depuis http://java.sun.com/javase/downloads/index.jsp.
uname -a) ;Installez la machine virtuelle JAVA (ici exemple 64bits) :
# rpm -i jre-8u40-linux-x64.rpm
JAVA est maintenant installé dans le répertoire /usr/java/jre1.8.0_xx/.
Votre variable d'environnement JAVA_HOME doit pointer vers ce répertoire, à chaque fois que vous mettrez à jour votre JRE par rpm, le répertoire /usr/java/latest pointera vers la dernière version installée automatiquement. De plus nous allons définir la variable JAVA_OPTS pour assurer à l'exécution de la JVM donc de Tomcat et de la servlet IdP assez de mémoire vive. Il est conseiller d'allouer au moins 1Go de mémoire à la servlet IdP. Vous pouvez être plus large si vous déployez l'IdP sur des machines mieux pourvues en mémoire vive.
Exécutez les commandes suivantes (fonctionne avec un shell BASH) :
# export JAVA_HOME=/usr/java/latest/
# export JAVA_OPTS="-Xmx1000m -XX:MaxPermSize=512m"
/etc/profile ou /etc/profile.d/ ou dans le script de démarrage du serveur Tomcat (fourni plus bas).
JAVA_OPTS concerne la JVM globalement et peut de ce fait impacter le fonctionnement d'autres applications Java. Il est préférable de définir ces options dans la variable d'environnement CATALINA_OPTS suivant le même format ; cette variable d'environnement n'impactera que le fonctionnement du serveur d'applications Tomcat.
Apache Tomcat est un serveur d'applications JAVA ; c'est lui qui exécutera la brique Shibboleth IdP. Tomcat est disponible sous forme de RPM, mais cette configuration n'est pas recommandée car certains choix faits par les mainteneurs du paquet sont atypiques et peuvent poser problème pour l'installation de Shibboleth. N'utilisez pas le serveur Apache Tomcat fourni par votre distribution, car il peut être pré-configuré avec des paramètres empêchant le fonctionnement de Shibboleth, difficiles à détecter et à corriger.
Pour ce TP nous allons tout de même prendre la dernière version 7 de ce serveur car les limitations ne nous gênent pas ici. Il vous faudra maintenir à jour ce serveur suite à d'éventuelles alertes de sécurité.
Suivez les instructions suivantes pour télécharger, vérifier l'intégrité des fichiers et installer Apache Tomcat :
# cd /tmp/
# wget http://apache.crihan.fr/dist/tomcat/tomcat-7/v7.0.59/bin/apache-tomcat-7.0.59.zip
# wget https://www.apache.org/dist/tomcat/tomcat-7/v7.0.59/bin/apache-tomcat-7.0.59.zip.asc
# wget -O KEYS http://www.apache.org/dist/tomcat/tomcat-7/KEYS
# gpg --import KEYS
# gpg --verify apache-tomcat-7.0.59.zip.asc
gpg: Signature faite le ven. 18 juil. 2014 16:40:36 CEST avec la clé RSA ID D63011C7
gpg: Bonne signature de « Violeta Georgieva Georgieva (CODE SIGNING KEY) violetagg@apache.org »
gpg: ATTENTION: Cette clé n'est pas certifiée avec une signature de confiance !
gpg: Rien ne dit que la signature appartient à son propriétaire.
Empreinte de clé principale: 713D A88B E509 1153 5FE7 16F5 208B 0AB1 D630 11C7
# unzip apache-tomcat-7.0.59.zip
Archive: apache-tomcat-7.0.59.zip
creating: apache-tomcat-7.0.59/
[…]
# mv apache-tomcat-7.0.59 /opt/
# cd /opt
Nous allons créer un lien symbolique vers la version courante de Tomcat, en prévision de mises à jour futures :
# ln -s apache-tomcat-7.0.59 tomcat
Lancez la commande suivante (fonctionne avec un shell BASH) pour positionner la variable d'environnement CATALINA_HOME qui doit indiquer le chemin d'accès au répertoire d'installation du serveur Tomcat :
# export CATALINA_HOME=/opt/tomcat
Aucun script de démarrage (de type /etc/init.d/) du serveur Tomcat n'est fourni lors de son installation. Néanmoins nous vous proposons un script très générique à télécharger depuis notre site voir ci-dessous (prenez le temps d'examiner le contenu) :
# /usr/sbin/useradd tomcat
# wget https://test.federation.renater.fr/exemples/conf_idp2/tomcat -O /etc/init.d/tomcat
# chown tomcat /etc/init.d/tomcat
# chmod 755 /etc/init.d/tomcat
# chmod +x tomcat/bin/*.sh
Nous allons créer un fichier XML qui permettra à Tomcat de déployer automatiquement la brique IdP sans avoir à recopier l'archive « .war » dans le répertoire webapps/ de Tomcat. Cette méthode de déploiement permet aussi d'éviter des problèmes de mise en cache parfois mal gérées par Tomcat. Pour cela, créez l'arborescence suivante :
# mkdir -p /opt/tomcat/conf/Catalina/localhost/
**<Context docBase="/opt/shibboleth-idp/war/idp.war" privileged="true" antiResourceLocking="false"** ** antiJARLocking="false"** ** unpackWAR="false" />**
Remarque :le fichier shibboleth-idp/war/idp.war sera accessible après l'installation de l'IdP qu'on aborde plus loin.
Nous allons à présent créer un répertoire qui va servir a stocker les bibliothèques qu'utilise la servlet IdP. Nous y copierons ces bibliothèques un peu plus loin dans le TP :
Avant de démarrer le serveur Tomcat, nous allons créer un utilisateur tomcat dédié ; c'est sous cette identité que s'exécutera le serveur Tomcat :
# chown -R tomcat /opt/apache-tomcat-7.0.59
Vous pouvez maintenant démarrer le serveur Tomcat dans un premier temps et vérifier son exécution ensuite :
# service tomcat start
Using CATALINA_BASE: /opt/tomcat
Using CATALINA_HOME: /opt/tomcat
Using CATALINA_TMPDIR: /opt/tomcat/temp
Using JRE_HOME: /usr/java/latest/
# ps auwx|grep tomcat
tomcat 20159 12.2 4.7 1645980 49156 ? Sl 10:58 0:02 /usr/java/latest//bin/java -Djava.util.logging.config.file=/opt/tomcat/conf/logging.properties -Xmx1000m -XX:MaxPermSize=512m -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/opt/tomcat/endorsed -classpath /opt/tomcat/bin/bootstrap.jar -Dcatalina.base=/opt/tomcat -Dcatalina.home=/opt/tomcat -Djava.io.tmpdir=/opt/tomcat/temp org.apache.catalina.startup.Bootstrap start
Vérifiez que les logs de Tomcat logs/catalina.out sont correctement renseignés lorsque vous démarrez et arrêtez Tomcat.
# tail -f /opt/tomcat/logs/catalina.out
13 juin 2012 09:25:27 org.apache.catalina.startup.HostConfig deployDirectory
INFO: Déploiement du répertoire host-manager de l'application web
13 juin 2012 09:25:28 org.apache.coyote.http11.Http11Protocol start
INFO: Démarrage de Coyote HTTP/1.1 sur http-8080
13 juin 2012 09:25:28 org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
13 juin 2012 09:25:28 org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/72 config=null
13 juin 2012 09:25:28 org.apache.catalina.startup.Catalina start
INFO: Server startup in 1440 ms
Vous pouvez maintenant accéder à votre serveur Tomcat avec un navigateur sur la page http://mon-poste.fr:8080/
Un certificat X.509 doit être installé sur le serveur hébergeant le service IdP. Ce certificat répond au besoin de sécurisation des échanges de l'utilisateur avec le serveur web et permet une authentification du serveur.
Sur un serveur en production vous pouvez utiliser un certificat TCS (reconnu nativement dans les navigateurs). Durant le TP nous utiliserons un certificat de test préparé pour les besoins de cette formation.
Téléchargez le certificat, la clef privée associée et la chaîne de certification :
# wget -O /etc/pki/tls/private/mon-poste.fr.key http://test.federation.renater.fr/formation/mon-poste.fr.key
# chmod 600 /etc/pki/tls/private/mon-poste.fr.key
# wget -O /etc/pki/tls/certs/mon-poste.fr.crt http://test.federation.renater.fr/formation/mon-poste.fr.crt
# chmod 644 /etc/pki/tls/certs/mon-poste.fr.crt
# wget -O /etc/pki/tls/certs/server-cachain.txt http://test.federation.renater.fr/formation/server-cachain.txt
# chmod 644 /etc/pki/tls/certs/server-cachain.txt
Vérifiez que le module mod_ssl pour Apache est installé :
# rpm -qi mod_ssl
Si le module n'est pas installé, faites :
# yum install mod_ssl
…
Is this ok [y/N]: y
…
Complete!
Configurez Apache pour utiliser ce certificat. Remplacez les directives SSLCertificateXxx existantes par celles indiquées ci-dessous :
**...** **SSLCertificateFile /etc/pki/tls/certs/mon-poste.fr.crt** **...** **SSLCertificateKeyFile /etc/pki/tls/private/mon-poste.fr.key** **...** **SSLCertificateChainFile /etc/pki/tls/certs/server-cachain.txt**
Shibboleth utilisant des assertions à courte durée de vie, des divergences d'horloge entre les serveurs IdP et SP ne sont pas tolérables. Les serveurs doivent donc avoir une configuration permettant une synchronisation horaire.
Dans le cas ou le serveur est une machine virtuelle (comme dans le cadre de ce TP) c'est l'hyperviseur qui assure cette synchronisation (utilisation des VMWare tools).
Dans le cas d'un serveur physique vous devez vérifier le bon fonctionnement du serveur NTP :
# service ntpd status
ntpd est arrêté
# service ntpd start
# /sbin/chkconfig --level 235 ntpd on
# date
Documentation de référence : https://wiki.shibboleth.net/confluence/display/SHIB2/IdPInstall
Téléchargez la dernière version 2.x de l'IdP Shibboleth depuis https://shibboleth.net/downloads/identity-provider/ :
# mkdir /opt/src
# cd /opt/src
# wget https://shibboleth.net/downloads/identity-provider/2.4.4/shibboleth-identityprovider-2.4.4-bin.zip
# wget -O KEYS https://shibboleth.net/downloads/PGP_KEYS
# wget https://shibboleth.net/downloads/identity-provider/2.4.4/shibboleth-identityprovider-2.4.4-bin.zip.asc
# gpg --import KEYS
# gpg --verify shibboleth-identityprovider-2.4.4-bin.zip.asc
gpg: Signature faite le mer. 25 févr. 2015 22:33:14 CET avec la clé DSA ID 61CB0B3F
gpg: Bonne signature de « Brent Putman putmanb@georgetown.edu »
…
# unzip shibboleth-identityprovider-2.4.4-bin.zip
Nous allons recopier des bibliothèques dont a besoin la servlet Java IdP pour fonctionner dans un sous répertoire de Tomcat créé précédemment :
Nous passons à présent à l'installation de l'IdP proprement dite. L'installation de l'IdP est interactive, vous devez répondre à plusieurs questions :
# ./install.sh
Where should the Shibboleth Identity Provider software be installed? [/opt/shibboleth-idp]
taper entrer
What is the fully qualified hostname of the Shibboleth Identity Provider server? [idp.example.org]
mon-poste.fr
A keystore is about to be generated for you. Please enter a password that will be used to protect it.
taper 'password'
…
BUILD SUCCESSFUL
Total time: 44 seconds
/opt/shibboleth-idp/credentials/idp.jks. Dans le contexte de ce TP ce keystore n'est pas utilisé puisque le SP Shibboleth sera configuré pour exploiter la version PEM du certificat et de la clef privée.
/opt/src/shibboleth-identityprovider-2.4.X/src/installer/resources/install.properties
L'installation a créé l'arborescence de l'IdP Shibboleth sous le répertoire /opt/shibboleth-idp/ . Cette arborescence doit être accessible pour l'utilisateur qui exécute le serveur Tomcat, dans notre cas l'utilisateur tomcat :
# chown -R tomcat /opt/shibboleth-idp/
Parcourons l'arborescence de l'IdP :
bin/ : contient les outils en ligne de commandes permettant un test rapide des attributs de l'IdP et connaitre son numéro de versionconf/ : contient les fichiers de configuration de l'IdPcredentials/ : les clés, certificats qui ont été générés lors de l'installation de votre IdP. Ces éléments sont exclusivement utilisés pour sécuriser les échanges SAML ; ils ne sont pas vus par les utilisateurs et ne nécessitent pas de signature par une autorité de confiance.lib/ : les librairies (jar) sur lesquelles s'appuie l'IdP. Ces librairies sont par ailleurs contenues dans le fichier idp.war ; elles ne sont utilisées que par les outils en ligne de commandes.logs/ : là où se trouvent tous les fichiers de logs (créés au démarrage de l'IdP)idp-process.log : fichier de log principal de l'IdPidp-access.log : journalisation des accès à l'IdPidp-audit.log : journalisation des données transmises par l'IdPmetadata/ : contient les méta-données de l'IdP et une copie locale des méta-données des fédérations qui seront configurées par la suitewar/ : contient l'archive de l'IdP, pas besoin de la déplacer pour le déploiement grâce au fichier tomcat/conf/Catalina/localhost/idp.xml créé auparavant. Tomcat déploiera l'archive idp.war à la volée si celui-ci est démarré.
Pour démarrer l'IdP Shibboleth, démarrer (ou redémarrez) votre serveur Tomcat :
# service tomcat restart
Examinez les logs de Tomcat pour voir si son démarrage s'est bien déroulé et que le fichier idp.war a été déployé dans l'environnement Tomcat (répertoire /opt/tomcat/work/Catalina/localhost ). Sinon vérifiez que le fichier de configuration /opt/tomcat/conf/server.xml comporte une directive autoDeploy comme dans l'exemple ci-dessous :
<Host name="localhost" appBase="webapps" unpackWARs="true" **autoDeploy="true"** xmlValidation="false" xmlNamespaceAware="false">
Optionnel : Si vous voulez avoir une vue d'ensemble des applications déployées par Tomcat et être sûr que l'IdP a bien été déployé. Vous pouvez enrichir le fichier /opt/tomcat/conf/tomcat-users.xml avec la partie suivante qui permet d'accéder à l'interface de gestion graphique (par navigateur Web) de Tomcat :
<?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename=**"manager-gui"**/> <user username=**"tomcat" password="tomcat" roles="manager-gui"**/> </tomcat-users>
Redémarrez votre serveur Tomcat pour prendre en compte ce changement de configuration. Il est impératif que dans deux autres fenêtres de terminal vous ayez toujours un tail -f sur les logs du serveur Tomcat et de l'IdP.
# service tomcat restart
# tail -f /opt/shibboleth-idp/logs/idp-process.log
# tail -f /opt/tomcat/logs/catalina.out
Vous pouvez accéder à cette interface à l'URL http://mon-poste.fr:8080/manager/html, entrer le user/password tomcat et vérifier que l'IdP est bien dans la liste des applications list.
Ok ne signifie pas que votre IdP est utilisable.
Comme vu précédemment, Shibboleth propose 3 fichiers de logs. Pour décider des seuils de logs il faut éditer le fichier /opt/shibboleth-idp/conf/logging.xml. Lors du démarrage et de l'exécution de la servlet, vous ne devriez observer dans le fichier /opt/shibboleth-idp/logs/idp-process.log que des messages en niveau INFO. Il existe en tout 5 niveaux : TRACE, DEBUG, INFO, WARN et ERROR. Pour ce TP, changez la valeur des parties suivantes en DEBUG, la deuxième permet de voir les assertions SAML échangées :
<logger name="edu.internet2.middleware.shibboleth" level=**"DEBUG"** /> ... <!-- Logs inbound and outbound protocols messages at DEBUG level --> <logger name="PROTOCOL_MESSAGE" level="DEBUG" /> ...
Ce mode DEBUG, ne ralentit plus l'exécution de la servlet mais est très verbeux et peut saturer la partition sur laquelle est installé Tomcat. En production utilisez le niveau de logs INFO et revenez au niveau DEBUG en cas de problèmes pour repérer la source de l'erreur.
Pour forcer la prise en compte immédiate de ce changement, redémarrer Tomcat.
Nous allons réaliser une configuration minimum permettant de tester le fonctionnement de votre fournisseur d'identités Shibboleth.
Tous les fichiers de configuration du fournisseurs d'identités sont installés par défaut dans /opt/shibboleth-idp/conf/ .
Nous vous suggérons de garder une copie des principaux fichiers de configuration de l'IdP Shibboleth. En production, il est fortement recommandé de « versionner » ces fichiers de configuration, avec SVN par exemple.
# cd /opt/shibboleth-idp/conf
# cp -p relying-party.xml relying-party.xml.dist
# cp -p attribute-resolver.xml attribute-resolver.xml.dist
# cp -p attribute-filter.xml attribute-filter.xml.dist
Documentation Internet2 : https://wiki.shibboleth.net/confluence/display/SHIB2/IdPRelyingParty
Il s'agit du fichier de configuration principal de Shibboleth IdP (équivalent du fichier idp.xml dans les précédentes versions du logiciel). Ci-dessous un exemple de fichier relying-party.xml .
Ce fichier est pré-configuré avec les éléments qui ont été saisis lors de l'installation. Dans un premier temps, les parties modifiées ou à modifier sont en surbrillance, elles sont expliquées ensuite :
<!-- ========================================== --> <!-- Relying Party Configurations --> <!-- ========================================== --> <rp:AnonymousRelyingParty provider="https://**mon-poste.fr**/idp/shibboleth" defaultSigningCredentialRef="IdPCredential" /> <rp:DefaultRelyingParty provider="https://**mon-poste.fr**/idp/shibboleth" defaultSigningCredentialRef="IdPCredential"> <!-- Each attribute in these profiles configuration is set to its default value, that is, the values that would be in effect if those attributes were not present. We list them here so that people are aware of them (since they seem reluctant to read the documentation). --> <rp:ProfileConfiguration xsi:type="saml:ShibbolethSSOProfile" includeAttributeStatement=**"true"** assertionLifetime="PT5M" signResponses="conditional" signAssertions="never" /> ...
Explications :
provider : il s'agit de l'identifiant de votre IdP. Cet identifiant sera référencé dans les méta données de la fédération ainsi que par les fournisseurs de services. DefaultRelyingParty : définit la configuration à utiliser (notamment le providerID) par défaut vis à vis d'un fournisseur de service AnonymousRelyingParty : définit la configuration à utiliser (notamment le providerID) lorsque l'IdP reçoit une requête d'un SP anonyme. Dans la configuration par défaut, l'IdP ne supporte aucun ProfileConfiguration pour les SP anonymes ; les demandes d'authentification ne sont donc pas acceptées dans ce cas.ProfileConfiguration/includeAttributeStatement : cet attribut positionné à true force l'IdP à transmettre les attributs utilisateurs en même temps que l'assertion d'authentification (attribute push via le navigateur). Ce mode de fonctionnement est obligatoire dans le cadre de la fédération Éducation-Recherche.
Documentation Internet2 : https://wiki.shibboleth.net/confluence/display/SHIB2/IdPMetadataProvider
Les fichiers de méta-données d'une fédération listent tous les membres de cette fédération. Sauf relation bilatérale, pour qu'un fournisseur de services soit reconnu par les fournisseurs d'identités, il doit être listé dans les méta-données. Inversement, pour qu'un fournisseur d'identités soit reconnu par des fournisseurs de services, il doit être listé dans les méta-données de la fédération. Le fichier de méta-données inclut également les autorités de certification reconnue ou bien, dans le cas de la fédération Éducation-Recherche, directement des certificat auto-signés.
Les méta-données constituent donc le socle de confiance d'une fédération. Pour assurer leur intégrité le fichier des méta-données est en général signé électroniquement (c'est cas dans la fédération Éducation-Recherche). 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 :
entityID) ;Assertion Consumer Service).Plus loin, dans le chapitre « Enregistrement dans la fédération de test » vous enregistrerez votre fournisseur d'identités dans la fédération de test proposé par RENATER. Votre fournisseur d'identités sera alors référencé dans les méta-données de cette fédération.
La confiance dans les méta-données est gérée dans le fichier /opt/shibboleth-idp/conf/relying-party.xml. L'IdP Shibboleth permet de charger dynamiquement depuis une URL les méta-données de la fédération ou celles d'un SP hors fédération. Les méta-données, une fois chargées, sont vérifiées (signature) et ont une date de péremption.
Éditez ce fichier pour y ajouter la confiance dans les méta-données de la fédération Éducation-Recherche.
Modifiez la définition des méta-données comme suit :
... <!-- MetadataProvider the combining other MetadataProviders --> <metadata:MetadataProvider id="ShibbolethMetadata" xsi:type="metadata:ChainingMetadataProvider"> <!-- Load the IdP's own metadata. This is necessary for artifact support. --> <metadata:MetadataProvider id="IdPMD" xsi:type="metadata:FilesystemMetadataProvider" metadataFile="/opt/shibboleth-idp/metadata/idp-metadata.xml" maxRefreshDelay="P1D" /> ** <!-- Federation Renater -->** ** <metadata:MetadataProvider id="MDTEST" xsi:type="metadata:FileBackedHTTPMetadataProvider"** ** metadataURL="https://federation.renater.fr/test/renater-test-metadata.xml"** ** backingFile="/opt/shibboleth-idp/metadata/renater-test-metadata.xml">** ** <metadata:MetadataFilter xsi:type="metadata:ChainingFilter">** ** <metadata:MetadataFilter xsi:type="metadata:RequiredValidUntil" ** ** maxValidityInterval="P7D" />** ** <metadata:MetadataFilter xsi:type="metadata:SignatureValidation"** ** trustEngineRef="shibboleth.MetadataTrustEngine"** ** requireSignedMetadata="true" />** ** <metadata:MetadataFilter xsi:type="metadata:EntityRoleWhiteList">** ** <metadata:RetainedRole>samlmd:SPSSODescriptor</metadata:RetainedRole>** ** </metadata:MetadataFilter>** ** </metadata:MetadataFilter>** ** </metadata:MetadataProvider>** </metadata:MetadataProvider>
On peut définir plusieurs sources de méta-données, en ajoutant des nœuds MetadataProvider au fichier de configuration ; dans ce cas l'ordre de définition a une importance. Chaque source de méta-données devra être identifiée par un attribut MetadataProvider/id qui doit être unique.
Nous allons maintenant télécharger le certificat permettant de vérifier les méta-données de la fédération Éducation-Recherche ; la configuration sera faite dans le même fichier relying-party.xml.
Téléchargez le certificat utilisé pour signer les méta-données de fédération Éducation-Recherche :
# wget -O /opt/shibboleth-idp/credentials/metadata-federation-renater.crt https://federation.renater.fr/test/metadata-federation-renater.crt
Éditez le fichier de configuration relying-party.xml pour faire référence à ce certificat ; n'oubliez pas de décommenter la partie en question :
<!-- ========================================== --> <!-- Security Configurations --> <!-- ========================================== --> ... <security:Credential id="IdPCredential" xsi:type="security:X509Filesystem"> <security:PrivateKey>/opt/shibboleth-idp/credentials/idp.key</security:PrivateKey> <security:Certificate>/opt/shibboleth-idp/credentials/idp.crt</security:Certificate> </security:Credential> <!-- Trust engine used to evaluate the signature on loaded metadata. --> <security:TrustEngine id="shibboleth.MetadataTrustEngine" xsi:type="security:StaticExplicitKeySignature"> **<security:Credential id="TestCredentials" xsi:type="security:X509Filesystem">** <security:Certificate>/opt/shibboleth-idp/credentials/**metadata-federation-renater.crt**</security:Certificate> **</security:Credential>** </security:TrustEngine> ...
/opt/shibboleth-idp/metadata/idp-metadata.xml qui le décrit (voir la définition ci-dessus). Ces méta-données sont accessibles via l'URL http://mon-poste.fr:8080/idp/profile/Metadata/SAML. Malheureusement, le fichier /opt/shibboleth-idp/metadata/idp-metadata.xml n'est pas mis à jour dynamiquement lorsque la configuration principale est modifiée et de ce fait n'est pas utilisable par un tiers, ou doit alors être systématiquement mis à jour si vous diffusez cette URL.
Il est tout à fait possible d'installer uniquement un serveur Tomcat, sans serveur Apache ; dans ce cas le serveur Tomcat fournira les fonctionnalités SSL pour sécuriser le service. Nous allons opter pour l'utilisation d'un proxy Apache en frontal du serveur Tomcat. Cette architecture offre l'avantage de pouvoir sécuriser le serveur Tomcat en restreignant les services accessibles à ceux explicitement configurés. Par ailleurs, cette architecture vous permet de disposer de l'ensemble des fonctionnalités d'un serveur Apache (modules d'authentification, réécriture, contrôle d'accès, etc.).
La transmission des requêtes entre Apache et Tomcat est assurée par le protocole AJP1.3. La version 2.2 d'Apache fournit cette fonctionnalité via mod_proxy et mod_proxy_ajp. Vérifiez que votre serveur Apache charge bien ce module proxy_ajp_module :
# httpd -M | grep ajp
proxy_ajp_module (shared)
Syntax OK
Vous devez créer le fichier de configuration de votre serveur Apache pour définir la correspondance entre une URL et la servlet idp que vous avez installée :
**## Ce fichier rassemble la configuration d'Apache pour l'IdP Shibboleth** **ProxyPass /idp/ ajp:%%//%%127.0.0.1:8009/idp/ retry=0** **ProxyPass /examples/ ajp:%%//%%127.0.0.1:8009/examples/**
Remarque :
L'application d'exemple « /examples/ » sert juste à tester notre interfaçage Tomcat-Apache.
Redémarrez le serveur Apache :
# service httpd restart
Vérifiez que le connecteur AJP 1.3 est activé au niveau du serveur Tomcat :
... <!-- Define an AJP 1.3 Connector on port 8009 --> **<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />**
8009 et 8080 depuis l'extérieur sur lesquels Tomcat est configuré par défaut pour répondre.
Vous pouvez maintenant tester l'accès au serveur Tomcat via Apache, en accédant aux exemples JSP fournis avec Tomcat : http://mon-poste.fr/examples/ (attention au '/' à la fin de l'URL).
En cas de problème :
# ps auwx|grep tomcat
# ps auwx|grep httpd
# tail -f /var/log/httpd/error_log
# tail -f /opt/tomcat/logs/catalina.out
Documentation Internet2 : https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAddAttribute
Ce fichier définit la façon dont chaque attribut utilisateur est extrait des référentiels locaux pour ensuite être diffusé par l'IdP Shibboleth. Vous devez définir des sources de données (DataConnector) puis des attributs (AttributeDefinition) qui y font référence. Chaque attribut peut être visible avec plusieurs noms ; ceci est utile pour qu'un identifiant d'attribut soit visible selon les formes URN et OID par exemple.
Nous allons adapter la configuration distribuée par défaut pour interroger un annuaire LDAP de test. Par la suite, vous pouvez personnaliser ce fichier pour interroger l'annuaire LDAP de votre établissement.
Dans l'exemple ci-dessous nous définissons deux attributs uid et mail ainsi que la source de données myLDAP.
Décommenter les deux définitions des attributs suivants :
...
<!-- Schema: Core schema attributes-->
** <resolver:AttributeDefinition xsi:type="ad:Simple" id="uid" sourceAttributeID="uid">**
** <resolver:Dependency ref="myLDAP" />**
** <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:uid" />**
** <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid" />**
** </resolver:AttributeDefinition>**
** **
** <!-- Email -->**
** <resolver:AttributeDefinition xsi:type="ad:Simple" id="email" sourceAttributeID="mail">**
** <resolver:Dependency ref="myLDAP" />**
** <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:mail" />**
** <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" />**
** </resolver:AttributeDefinition>**
...
<!-- TEST LDAP connector -->
<resolver:DataConnector id=**"myLDAP"** xsi:type="dc:LDAPDirectory"
**ldapURL="ldap://ldap.cru.fr" baseDN="ou=people,dc=univ-test,dc=fr" principal=""**
**principalCredential=""**>
<dc:FilterTemplate>
<![CDATA[
(**uid=$requestContext.principalName**)
]]>
</dc:FilterTemplate>
</resolver:DataConnector>
<!-- Computed targeted ID connector -->
...
Filtre LDAP: Dans l'exemple ci-dessus le filtre LDAP (nœud FilterTemplate ci-dessus) fait référence à l'identifiant de l'utilisateur via la variable $requestContext.principalName dont le contenu sera l'identifiant de l'utilisateur positionné par le serveur SSO-CAS.
SAML1String et SAML2String) dans l'exemple ci-dessus. Ce mode de fonctionnement permet de rester compatible avec les SP Shibboleth 1.3 qui s'attendent à recevoir des attributs au format URN, alors que Shibboleth 2.x utilise le format OID, comme recommandé par la norme SAML2.
attribute-resolver.xml plus complet est distribué par RENATER. Il est disponible sur la page suivante : https://services.renater.fr/federation/technique/configurations
Documentation Internet2 : https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAddAttribute
Un fournisseur d'identités Shibboleth est finement configurable pour filtrer les attributs utilisateurs transmis à chaque fournisseur de services. Cette configuration se fait via le fichier de configuration attribute-filter.xml. Le configuration par défaut ne fournit aucun attribut aux fournisseurs de services ; aussi nous allons l'adapter pour transmettre les attributs utilisateurs définis précédemment.
<!-- Release the transient ID to anyone --> <afp:AttributeFilterPolicy id="releaseTransientIdToAnyone"> <afp:PolicyRequirementRule xsi:type="basic:ANY"/> <afp:AttributeRule attributeID="transientId"> <afp:PermitValueRule xsi:type="basic:ANY"/> </afp:AttributeRule> </afp:AttributeFilterPolicy> ** <afp:AttributeFilterPolicy id="releaseUidAndEmailToAnyone">** ** <afp:PolicyRequirementRule xsi:type="basic:ANY"/>** ** <afp:AttributeRule attributeID="uid"> ** ** <afp:PermitValueRule xsi:type="basic:ANY" /> ** ** </afp:AttributeRule>** ** <afp:AttributeRule attributeID="email"> ** ** <afp:PermitValueRule xsi:type="basic:ANY" /> ** ** </afp:AttributeRule>** ** </afp:AttributeFilterPolicy>** ...
Documentation Internet2 : https://wiki.shibboleth.net/confluence/display/SHIB2/AACLI
Shibboleth inclut l'utilitaire aacli.sh en ligne de commande qui permet de tester quels attributs sont transmis, étant donné un fournisseur de services et un identifiant d'utilisateur.
Vous pouvez tester votre configuration dès maintenant :
# cd /opt/shibboleth-idp
# su tomcat -c "./bin/aacli.sh --requester=https://test.federation.renater.fr/test/ressource --configDir=conf/ --principal=etudiant1"
<?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="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" 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">**jean.dupont@univ-test.fr**</saml2:AttributeValue> </saml2:Attribute> ... </saml2:AttributeStatement>
Le résultat de la commande aacli.sh est une assertion SAML qui inclut les attributs mail et uid. La configuration permettant l'extraction et la diffusion de ces deux attributs utilisateur est donc correcte.
Documentation Internet2 : https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthUserPass
Maintenant que notre IdP est localement configuré, nous allons définir le mode d'authentification de notre fournisseur d'identités. En effet, à partir de la version 2.1, l'IdP est pourvu nativement de plusieurs systèmes d'authentifications. Il existe quatre types d'authentification possibles :
Remote User depuis un autre système de SSO (délégation) ;
Nous allons utiliser dans un premier temps le SSO natif proposé par l'IdP qui a sa propre interface de connexion. Il faut donc « brancher » notre IdP à un annuaire LDAP de test pour la phase d'authentification. Celle-ci s'active dans le fichier de configuration principal, relying-party.xml en ajoutant la partie suivante :
<rp:DefaultRelyingParty provider="https://mon-poste.fr/idp/shibboleth" defaultSigningCredentialRef="IdPCredential" **defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"**> ...
Une fois spécifié la méthode d'authentification, on connecte l'IdP sur l'annuaire de type LDAP dans le fichier de configuration /opt/shibboleth-idp/conf/login.config. Pensez à décommenter la configuration ci-dessous.
ShibUserPassAuth {
// Example LDAP authentication
// See: https://spaces.internet2.edu/display/SHIB2/IdPAuthUserPass
edu.vt.middleware.ldap.jaas.LdapLoginModule required
ldapUrl="**ldap://ldap.cru.fr**"
baseDn="**ou=people,dc=univ-test,dc=fr**"
ssl="**false**"
userFilter="uid={0}";
Éditez à présent le fichier /opt/shibboleth-idp/conf/handler.xml pour y décommenter la partie gérant le formulaire de connexion Shibboleth :
... <!-- Username/password login handler --> <ph:LoginHandler xsi:type="ph:UsernamePassword" jaasConfigurationLocation="file:///opt/shibboleth-idp/conf/login.config"> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</ph:AuthenticationMethod> </ph:LoginHandler> ...
Redémarrez le serveur Tomcat pour que les modifications prennent effet :
# service tomcat restart
Pour tester votre fournisseur d'identités nouvellement installé, vous avez besoin d'un fournisseur de services SAML qui sera capable de déléguer l'authentification à votre fournisseur d'identités. A cette fin, nous allons utiliser le fournisseur de services de test de la Fédération Education-Recherche.
Vous devez préalablement vous enregistrer auprès de cette fédération de test afin que le fournisseur de services de test ai connaissance de votre IdP. Le guichet de la fédération vous permet d'effectuer cet enregistrement pour un IdP : https://federation.renater.fr/registry
Ce formulaire requiert une authentification préalable. Vous pouvez vous authentifier avec un compte CRU ; si vous n'en avez pas, vous serez invité à vous en créer un lors de la procédure d'authentification.
Renseignez le formulaire d'enregistrement de manière suivante :
Onglet Description
Intitulé du fournisseur d'identités : Idp test mon-poste.fr
Intitulé du fournisseur d'identités (en anglais) : Idp test mon-poste.fr
domaine : univ-test.fr
Description : Idp test
Description (en anglais) : Idp test
Onglet Rattachement à un organisme
Sélection de l'organisme : ne pas renseigner
Onglet Contacts
Nom Contact technique 1 : vous
Adresse email : vous@votre.univ.fr
Onglet Informations techniques
entityID : https://mon-poste.fr/idp/shibboleth
URL du service SSO : https://mon-poste.fr/idp/profile/Shibboleth/SSO
URL du profil SAML2/POST/SSO : https://mon-poste.fr/idp/profile/SAML2/POST/SSO
URL du profil SAML2/Redirect/SSO : https://mon-poste.fr/idp/profile/SAML2/Redirect/SSO
Certificat X.509 : [contenu du fichier /opt/shibboleth-idp/credentials/idp.crt à copier sans les BEGIN CERTIFICATE et END CERTIFICATE ]
Explications :
provider;univ-test.fr comme domaine car c'est celui extrait depuis un LDAP de test.Vous devez maintenant rattacher votre IdP à la fédération de Test via le guichet.
Votre IdP est maintenant dans la Fédération de Test. Un délai est nécessaire pour la prise en compte de la dernière version des méta-données de la fédération de Test par le SP de Test et le service de découverte en amont.
Remarque : Vous pourrez modifier ultérieurement les informations saisies via le guichet de la fédération https://federation.renater.fr/registry
Vous pouvez accéder au fournisseur de services de test https://test.federation.renater.fr/test/ressource (connexion possible 5mn après l'enregistrement de votre IdP, le temps de mise à jour des méta-données côté DS et SP de test) :
'Idp test mon-poste.fr ' dans le menu déroulant ;
Documentation Internet2 : https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthRemoteUser
Nous allons cette fois ci interfacer l'IdP Shibboleth avec un serveur d'authentification CAS de test. Par la suite vous pourrez le connecter avec le serveur CAS de votre organisme.
Nous téléchargeons le client JA-SIG CAS et le recopions dans la bibliothèque de l'IdP :
# wget http://repo2.maven.org/maven2/org/jasig/cas/client/cas-client-core/3.3.3/cas-client-core-3.3.3.jar -O /opt/src/shibboleth-identityprovider-2.4.4/lib/cas-client-core-3.3.3.jar
Vous allez devoir ajouter l'appel au filtre CAS dans le web.xml des sources de l'IdP puis générer à nouveau le fichier idp.war.
Éditez le fichier /opt/src/shibboleth-identityprovider-2.4.4/src/main/webapp/WEB-INF/web.xml afin d'y ajouter les appels au filtre CAS :
... <!-- Spring 2.0 listener used to load up the configuration --> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <!-- CAS Filter Configuration --> <context-param> <param-name>serverName</param-name> <param-value>https://mon-poste.fr</param-value> </context-param> <!-- CAS Authentication Filter --> <filter> <filter-name>CAS Authentication Filter</filter-name> <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class> <init-param> <param-name>casServerLoginUrl</param-name> <param-value>https://test.federation.renater.fr/cas/login</param-value> </init-param> </filter> <!-- CAS Validation Filter --> <filter> <filter-name>CAS Validation Filter</filter-name> <filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class> <init-param> <param-name>casServerUrlPrefix</param-name> <param-value>https://test.federation.renater.fr/cas</param-value> </init-param> </filter> <!-- CAS HttpServletRequest Wrapper Filter --> <filter> <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name> <filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class> </filter> <!-- CAS Assertion Thread Local Filter --> <filter> <filter-name>CAS Assertion Thread Local Filter</filter-name> <filter-class>org.jasig.cas.client.util.AssertionThreadLocalFilter</filter-class> </filter> <!-- CAS Filter for Shibb RemoteUser --> <filter-mapping> <filter-name>CAS Authentication Filter</filter-name> <url-pattern>/Authn/RemoteUser</url-pattern> </filter-mapping> <filter-mapping> <filter-name>CAS Validation Filter</filter-name> <url-pattern>/Authn/RemoteUser</url-pattern> </filter-mapping> <filter-mapping> <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name> <url-pattern>/Authn/RemoteUser</url-pattern> </filter-mapping> <filter-mapping> <filter-name>CAS Assertion Thread Local Filter</filter-name> <url-pattern>/Authn/RemoteUser</url-pattern> </filter-mapping> <!-- Add IdP SLF4J MDC cleanup filter to all requests --> ...
Faites le test suivant pour vérifier la cohérence de votre fichier XML :
# xmlwf /opt/src/shibboleth-identityprovider-2.4.4/src/main/webapp/WEB-INF/web.xml
Vous devez ensuite redéployer l'application Shibboleth ; répondez no à la question Would you like to overwrite this Shibboleth configuration?:
# cd /opt/src/shibboleth-identityprovider-2.4.4/
# ./install.sh
Buildfile: src/installer/resources/build.xml
install:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Be sure you have read the installation/upgrade instructions on the Shibboleth website before proceeding.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Where should the Shibboleth Identity Provider software be installed? [/opt/shibboleth-idp] [Acceptez ce choix]
The directory '/opt/shibboleth-idp' already exists. Would you like to overwrite this Shibboleth configuration? (yes, [no])
no
Copying 50 files to /opt/shibboleth-idp/lib
Copying 5 files to /opt/shibboleth-idp/lib/endorsed
Copying 1 file to /opt/src/shibboleth-identityprovider-2.4.4/src/installer
Building war: /opt/src/shibboleth-identityprovider-2.4.4/src/installer/idp.war
Copying 1 file to /opt/shibboleth-idp/war
Deleting: /opt/src/shibboleth-identityprovider-2.4.4/src/installer/web.xml
Deleting: /opt/src/shibboleth-identityprovider-2.4.4/src/installer/idp.war
BUILD SUCCESSFUL
Total time: 8 seconds
Vous pouvez constater que le fichier idp.war a été mis à jour dans le répertoire /opt/shibboleth-idp/war/ .
Il est nécessaire de redémarrer le serveur Tomcat pour prendre en compte ces changements :
# service tomcat restart
Lorsque vous redémarrez votre serveur Tomcat, il est recommandé d'avoir une fenêtre de terminal avec les log de l'IdP en temps réel pour déceler tout de suite le moindre problème :
# tail -f /opt/shibboleth-idp/logs/idp-process.log
Après le redémarrage de Tomcat, vous pourrez vérifier que l'application Shibboleth a correctement démarrée en consultant le service de Status à l'adresse http://mon-poste.fr:8080/manager/html
À présent nous retirons les modifications faites au précédent chapitre pour permettre la délégation de l'authentification. Modifier le fichier relying-party.xml en retirant la ligne (grisée ci-dessous) spécifiant la méthode d'authentification PasswordProtectedTransport. En effet, par défaut, l'IdP gère l'authentification en supposant qu'un mécanisme d'authentification tiers (SSO-CAS dans ce TP) est mise en œuvre (filtre java) en frontal de l'URL /Authn/RemoteUser ; ce mécanisme d'authentification positionne la variable d'environnement REMOTE_USER.
... <rp:DefaultRelyingParty provider="https://mon-poste.fr/idp/shibboleth" defaultSigningCredentialRef="IdPCredential" --defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"-->
Attention à la fin de la balise rp:DefaultRelyingParty, le chevron fermant ('>') de l'élément DefaultRelyingParty ne doit pas être supprimé.
Redémarrez votre serveur Tomcat pour faire prendre en compte les modifications dans la configuration :
# service tomcat restart
Vous pouvez à présent re-tester votre IdP en accédant à nouveau à la ressource de test https://test.federation.renater.fr/test/ressource.
Authentification CAS : Vous serez redirigé vers le serveur CAS de test puisque nous avons configuré notre IdP pour utiliser ce serveur CAS. Utilisez l'identifiant/mot de passe = etudiant1/etudiant1. Ce compte de test transmet un ensemble d'attributs facilitant les tests, sous réserve de configurer la diffusion de plus d'attributs au niveau de l'IdP, voir plus haut.