Auteurs : Rafael Diaz Maurin , Florent Guilleux, Mehdi Hached, Sébastien Médard, Olivier Salaün, David Verdin
Dernière mise à jour : Mars 2015
Préambule :
Les commandes à exécuter et les exemples de fichiers de configuration sont affichés dans cette police.
Public concerné : développeurs d'applications ou gestionnaires d'applications souhaitant « shibboliser » une application.
Cette partie détaille l'installation et la configuration de la brique Shibboleth fournisseur de services (Service Provider, SP). Nous procèderons par étapes pour aboutir à un fournisseur de services 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 d'un fournisseur d'identités de test dans la fédération de test.
La brique fournisseur de services consiste en un module pour les serveurs web Apache ou IIS, à installer en frontal de l'application. Elle est disponible pour plusieurs systèmes d'exploitation (Windows, Linux/Unix, MacOS X). Une application « shibbolisée » doit donc être hébergée sur l'un de ces systèmes d'exploitation et serveurs web (si ce n'est pas le cas, il est toujours possible de l'installer sur un reverse proxy en frontal du serveur hébergeant l'application). La brique fournisseur de services inclut également un démon nommé shibd, son rôle principal est de maintenir les différentes sessions.
Nous utiliserons le module Apache sur une distribution CentOS 7.2 avec Apache 2.4. Ce module est codé en C++. La version que nous allons installer est la version 2.5.6 du SP Shibboleth. Elle est disponible pour plusieurs plateformes (CentOS, RHEL, SLES, openSUSE). Elle existe aussi en version tar.gz mais les RPM sont beaucoup plus faciles à installer et mettre à jour, surtout si on intègre à yum le dépôt qui va bien. Le RPM de base du SP est accompagné de 5 autres RPM requis. Pour d'autres distributions Linux, une recompilation depuis les sources (ou source-RPM) est possible mais n'est pas garantie par les développeurs de Shibboleth.
Si vous ne faites pas partie d'un établissement faisant partie de la fédération Éducation-Recherche (https://services.renater.fr/federation/participants/idp), il vous sera nécessaire d'avoir un compte CRU accéder au guichet fédération. Vous pouvez vous créer un compte CRU à partir du site https://cru.renater.fr.
Commençons par connaitre le nom du poste sur lequel vous travaillez :
# hostname
Mettez le nom du poste ainsi obtenu dans le champ suivant :
Nom de votre machine :
Web Developper : elle vous permet notamment de visualiser et supprimer rapidement les cookies. L'extension Tamper Data permet quant à elle de visualiser les en-têtes HTTP et les redirections du navigateur. C'est très utile pour comprendre le fonctionnement de Shibboleth. Vous pouvez installer ces extensions depuis les page https://addons.mozilla.org/fr/firefox/addon/60 et https://addons.mozilla.org/fr/firefox/addon/966. Relancez Firefox pour terminer leur installation.Avant l'installation proprement dite de la brique Shibboleth, plusieurs composants doivent être mis en place.
Un certificat X.509 doit être installé sur le serveur web pour sécuriser les échanges entre le navigateur et le serveur web (couche SSL/TLS) et permettre une authentification du serveur par le navigateur web.
Pour cette formation nous utilisons un certificat de test préparé pour chaque poste. Ces certificats de test sont générés par une AC de test.
Téléchargez le certificat, sa clef privée associée et la chaîne de certification :
# wget -O /etc/pki/tls/private/monposte.fr.key http://test.federation.renater.fr/formation/monposte.fr.key
# chmod 600 /etc/pki/tls/private/monposte.fr.key
# wget -O /etc/pki/tls/certs/monposte.fr.crt http://test.federation.renater.fr/formation/monposte.fr.crt
# chmod 644 /etc/pki/tls/certs/monposte.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
Si le module mod_ssl pour Apache n'est pas installé, vous devez l'installer :
# rpm -qi mod_ssl
le paquetage mod_ssl n'est pas installé
# yum install mod_ssl
…
Is this ok [y/N]:y
…
Complete!
Configurez Apache pour utiliser ce certificat :
SSLCertificateFile /etc/pki/tls/certs/monposte.fr.crt ... SSLCertificateKeyFile /etc/pki/tls/private/monposte.fr.key ... SSLCertificateChainFile /etc/pki/tls/certs/server-cachain.txt
Il faut éditer le fichier de configuration de votre serveur Apache pour spécifier les éléments suivants :
UseCanonicalName doit être positionnée à On. Cette directive est requise pour permettre le routage des requêtes via la fonctionnalité RequestMap détaillée plus loin ;ServerName doit être correctement configurée au nom de votre machine.
UseCanonicalName : voir l'explication sur le site de Shibboleth
ServerName monposte.fr:80 ... UseCanonicalName On
NTP doit être utilisé sur le serveur hébergeant la brique du fournisseur de services. Shibboleth utilisant des assertions à courte durée de vie, des divergences d'horloge entre les serveurs hébergeant les IdP et les SP peuvent empêcher un utilisateur d'accéder à un service fédéré. 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
Pour connaître l'architecture de votre machine (exemple) :
$ uname -i
x86_64
i386 correspond à une architecture 32bitsx86_64 correspond à une architecture 64bits
OpenSuse Build Service maintient à jour des paquets RPM de Shibboleth (et ses dépendances) pour les distributions suivantes : RedHat Enterprise Linux, CentOS, Suse Linux Enterprise et OpenSuse.
Ainsi, nous allons configurer un dépot pour une CentOS 7.x :
# wget -O /etc/yum.repos.d/security_shibboleth.repo http://download.opensuse.org/repositories/security://shibboleth/CentOS_7/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/CentOS_7//repodata/repomd.xml.key
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-shibboleth-security
Sur une architecture 32bits on exécutera cette commande :
# yum install shibboleth
Sur une architecture 64bits :
# yum install shibboleth.x86_64
Positionner les droits shibd pour le répertoire du SP :
chown -R shibd /etc/shibboleth
Le site de téléchargement de Shibboleth SP : http://shibboleth.net/downloads/service-provider/latest/
Lancer Firefox si vous voulez télécharger les RPM via une interface graphique :
$ firefox &
Passer en compte root sur votre machine :
$ sudu su -
Documentation Shibboleth : https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPLinuxRPMInstall
x-debuginfo, x-devel et x-doc qui sont proposés sur le site Shibboleth qui se trouvent dans le même répertoire.
Le processus shibd a besoin d'un certificat pour signer et/ou chiffrer les requêtes SAML transmises aux fournisseurs d'identités (IdP).
le SP Shibboleth s'installe en générant un biclé auto-signé et est livré avec un script nommé keygen.sh qui permet d'en regénérer de nouveaux si besoin. En effet, pour des raisons pragmatiques (durée de vie des certificats reconnus, mise à jour des méta-données), il est plus simple d'utiliser un certificat auto signé.
Documentation Internet 2 : https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig
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 est installée sous le répertoire /etc/httpd/conf.d/ sous le nom de shib.conf (identique au fichier apache22.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.
Editez ce fichier de configuration shib.conf pour associer à l'URL /secure le script shibenv.php qui affichera les attributs utilisateurs reçus par le SP Shibboleth (pour le moment ce script n'est pas installé sur le poste, nous allons le faire plus tard). C'est grâce à cette affichage que nous pourrons vérifier que la brique SP fonctionne bien.
# yum install php
# service httpd restart
**ScriptAlias /secure /etc/shibboleth/shibenv.php**
<Location /secure>
**AuthType shibboleth**
**ShibRequestSetting requireSession 1**
**ShibRequestSetting applicationId default**
**require shib-session**
</Location>
**## Activation globale de l'authentification Shibboleth**
**## C'est nécessaire pour activer les handlers**
**<Location />**
**AuthType shibboleth**
**Require shibboleth**
**</Location>**
La directive AuthType shibboleth permettra d'activer le module Shibboleth lors des requêtes vers l'URL https://monposte.fr/secure. La directive ShibRequestSetting requireSession 1 indique à ce module qu'une session Shibboleth doit être déclenchée à la première requête sur cette URL (on désactive ce comportement quand on utilise le mode lazy sessions, présenté en fin de TP). La directive ShibRequestSetting applicationId default assure le « routage » des requêtes HTTP vers le bon contexte applicatif du SP Shibboleth. Enfin la directive require shib-session permet de s'assurer que seuls les utilisateurs authentifiés pourront accéder à https://monposte.fr/secure.
require valide-user est remplacée depuis la version 2.5.2 du SP Shibboleth par la directive require shib-session, voir cette documentation. L'ancienne directive reste valide.
shibboleth2.xml, que nous détaillons plus loin.
Vous allez télécharger un ensemble de fichiers de configuration personnalisés pour les besoins du TP à l'adresse https://test.federation.renater.fr/exemples/conf_sp2_renater.tar.gz. Les fichiers 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 /tmp
# wget https://test.federation.renater.fr/exemples/conf_sp2_renater.tar.gz
# tar -zxvf conf_sp2_renater.tar.gz
conf_sp2/ conf_sp2/localLogout_fr.html conf_sp2/metadataError_fr.html conf_sp2/accessError_fr.html conf_sp2/sessionError_fr.html conf_sp2/globalLogout_fr.html conf_sp2/attribute-map.xml conf_sp2/attribute-policy.xml conf_sp2/sslError_fr.html conf_sp2/shibenv.php
# mv -f conf_sp2/* /etc/shibboleth/
Il faut à présent télécharger le certificat qui permet de vérifier la signature des méta-données de la fédération Éducation-Recherche et celle de test :
# wget https://metadata.federation.renater.fr/certs/renater-metadata-signing-cert-2016.pem -O /etc/shibboleth/renater-metadata-signing-cert-2016.pem
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 ; ils seront commentés plus bas. Les zones grisées doivent être ajoutées/modifiées.
shibboleth2.xml fourni est minimaliste. Pour avoir un exemple de fichier de configuration plus riche, consultez /etc/shibboleth/example-shibboleth2.xml.
<SPConfig ...> ... <ApplicationDefaults entityID="https://**monposte.fr**" REMOTE_USER="eppn persistent-id targeted-id"> <Sessions lifetime="28800" timeout="3600" checkAddress="false" relayState="ss:mem" **handlerSSL="true" cookieProps="https"**> <SSO discoveryProtocol="SAMLDS" --entityID="https://idp.example.org/idp/shibboleth"-- discoveryURL="**https://discovery.renater.fr/test**"> SAML2 SAML1 </SSO> ... <Errors supportContact="root@localhost" **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"/> <!-- Meta-données de la fédération de Test RENATER --> <MetadataProvider type="XML" uri=**"https://metadata.federation.renater.fr/test/preview/preview-all-renater-test-metadata.xml"** backingFilePath=**"preview-all-renater-test-metadata.xml"** reloadInterval="7200"> <MetadataFilter type="Signature" certificate=**"renater-metadata-signing-cert-2016.pem"**/> </MetadataProvider> ... <!-- Simple file-based resolver for using a single keypair. --> <CredentialResolver type="File" key="sp-key.pem" certificate="sp-cert.pem" /> ... </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 utiliser de préférence le protocole 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).ApplicationOverride avec ses propres éléments entityID, handlerURL, SessionInitiator, etc. ; voir https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationOverride. En fin de TP vous pourrez éventuellement tester cette possibilité.
CredentialResolver : spécifie le certificat et la clé privée utilisés pour signer les assertions SAML.MetadaProvider/uri : permet de spécifier le fichier de méta-données qui est utilisé par le SP. Nous utilisons ici les méta-données de la fédération de test. Elles sont rechargées automatiquement toutes les deux heures par défaut (paramètre reloadInterval).MetadataProvider/bakingFilePath dans l'exemple ci-dessus. Depuis la version 2.4 du SP Shibboleth ces fichier 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/SHIB2/NativeSPMetadataProvider
Les méta-données sont regroupées dans le fichier preview-all-renater-test-metadata.xml qui liste tous les membres de la fédération de test. Pour qu'un fournisseur de services soit reconnu dans une fédération par les fournisseurs d'identités, il doit être listé dans ce fichier. Inversement, pour qu'un fournisseur d'identités soit reconnu dans la fédération par des fournisseurs de services, il doit être listé dans les méta-données. Le fichier de méta-données inclut également les certificats de chaque entité.
Les méta-données constituent donc le socle de la confiance d'une fédération. Pour assurer leur intégrité le fichier des méta-données est signé électroniquement. 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 son identifiant unique (attribut entityID), des adresses de contact organisationnel et technique, le certificat utilisé par ce fournisseur, l'adresse du SSO pour un fournisseur d'identités et l'adresse de réception des attributs pour un fournisseur de services.
shibboleth2.xml pointe directement vers un fichier hébergé sur le serveur de RENATER et mis à jour à chaque ajout/modification/suppression d'un IdP ou SP. Le SP se charge par défaut de le télécharger toute les 2 heures. C'est un plus par rapport aux versions 1.3.x de Shibboleth qui nécessitaient un processus de synchronisation et de vérification de signature spécifique du fichier de méta-données.
Dans le chapitre « Enregistrement dans la fédération de test » vous enregistrerez en ligne votre fournisseur dans la fédération de test. Il apparaitra alors dans les méta-données de cette fédération.
Documentation de référence : https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplication
La notion d'application ici ne correspond pas à une application au sens ou on peut l'entendre. Il s'agit plutôt de la notion de contexte applicatif ; c'est à dire un ensemble de paramétrage (entityID, méta-données utilisées, attributs utilisateurs attendus, etc.) communs à un ensemble d'applications.
Concrètement vous devrez créer autant d'éléments ApplicationOverride que de groupes d'applications qui partagent les caractéristiques suivantes :
Un ensemble d'application partageant un ApplicationOverride partagera le même identifiant (entityId) et sera visible comme un même SP auprès du guichet de la fédération.
ApplicationDefaults que pour définir des paramètres communs à chaque contexte applicatif, ainsi vous gardez la configuration par défaut de vos applications entre les balises <ApplicationDefaults>.
Documentation de référence : https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationOverride
Une fois définis des contextes applicatifs dans shibboleth2.xml (définis par ApplicationDefaults ou ApplicationOverride), il est nécessaire d'aiguiller les requêtes HTTP vers l'un d'entre eux. Cet aiguillage peut être défini de deux manières : dans le fichier shibboleth2.xml (RequestMapper) ou dans la configuration Apache.
L'aiguillage depuis la configuration d'Apache consiste à faire référence à un contexte applicatif (ApplicationID) via la directive de configuration ShibRequestSetting application Id.
<Location /secure>
AuthType shibboleth
ShibRequestSetting requireSession 1
ShibRequestSetting applicationId default
require shib-session
</Location>
RequestMapper vs ShibRequestSetting : les deux modes de configuration sont équivalents ; le RequestMapper a été créé pour permettre le routage des requêtes en environnement IIS. Les développeurs de Shibboleth recommandent d'utiliser la configuration depuis le contexte Apache au lieu du RequestMapper. En effet, la syntaxe du RequestMapper est parfois ambiguë. Un autre argument en faveur du second mode de configuration : il permet à des gestionnaires d'applications d'activer l'authentification Shibboleth, sans devoir intervenir dans le fichier de configuration principal du SP Shibboleth.
Le niveau de log est par défaut à INFO car le SP est très verbeux en mode DEBUG. Le fichier gérant le niveau de log est /etc/shibboleth/shibd.logger pointé depuis le fichier shibboleth2.xml. Pour faciliter le débogage dans un premier temps vous pouvez éditer le fichier shibd.logger pour le mettre en DEBUG.
# 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**
Sur une machine 64 bits (supprimer le '64' sur une machine 32 bits) :
# export LD_LIBRARY_PATH=/opt/shibboleth/lib64:$LD_LIBRARY_PATH
Démarrez Apache :
# service httpd restart
Vérifiez que la syntaxe de votre configuration shibboleth2.xml est correcte :
# /usr/sbin/shibd -tc /etc/shibboleth/shibboleth2.xml
overall configuration is loadable, check console for non-fatal problems
Démarrage du démon shibd :
# service shibd start
Vérifiez que les processus sont bien lancés :
# ps auwx | grep httpd
root 17373 0.0 1.7 19100 9084 ? Ss Nov30 0:02 /usr/sbin/httpd apache 23165 0.0 1.7 31176 9004 ? Sl Dec02 0:00 /usr/sbin/httpd
# ps auwx | grep shib
root 18643 0.0 3.7 119428 19432 pts/0 Sl 13:17 0:03 /usr/sbin/shibd -p /var/run/shibboleth/shibd.pid -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.
# tail -f /var/log/shibboleth/shibd.log
Vous allez maintenant valider le bon fonctionnement de votre fournisseur de services dans le cadre de la fédération Éducation-Recherche de test. Il s'agit d'une infrastructure destinée uniquement à des usages de type test.
Vous devez d'abord enregistrer votre fournisseur en décrivant techniquement votre fournisseur de services auprès de la fédération de test. Les éléments techniques fournis seront publiés dans les méta-données et permettront à votre fournisseur de services d'interagir avec les fournisseurs d'identités.
Le guichet de la fédération vous permet d'effectuer cet enregistrement : https://federation.renater.fr/registry. Ce formulaire requiert une authentification préalable. Vous pouvez vous authentifier soit avec un compte CRU soit via votre fournisseur d'identités si vous êtes rattaché à un établissement inscrit comme fournisseur d'identités dans la fédération Éducation-Recherche.
Renseignez les différents onglets du formulaire, la signification des champs y est décrite :
Onglet Description
Intitulé du service: TP fédération : Service de test monposte.fr
Intitulé du service (en anglais): TP fédération : Service de test monposte.fr
URL du service : https://monposte.fr/secure
Description du SP : TP fédération : Service de test
Description du SP (en anglais) : TP fédération : Service de test
Onglet Rattachement à un organisme
Rattachement à un organisme : ne pas renseigner
Onglet Contacts
Contact technique 1 nom : votre nom
email : votre email institutionel
Onglet Attributs demandés
Pays où les données sont traitées : cocher la case “les données sont traitées en France ou dans un autre pays de l'UE”
Conformité au Data Protection Code of Conduct eduGAIN : ne pas cocher la case “ce service est conforme aux règles du Code of Conduct”
Public(s) concerné(s) par le service : ressource locale
Catégorie du service : outils collaboratifs
Attributs :
displayName (cocher la bouton radio "obligatoire oui" et remplisser le champs "Quel usage comptez-vous faire de cet attribut" avec "personnalisation" \\ email (cocher la bouton radio "obligatoire oui" et remplisser le champs "Quel usage comptez-vous faire de cet attribut" avec "identifiant" \\ eduPersonPrincipalName (cocher la bouton radio "obligatoire oui" et remplisser le champs "Quel usage comptez-vous faire de cet attribut" avec "identifiant" \\
Onglet Informations techniques
URL de vos méta données : https://monposte.fr/Shibboleth.sso/Metadata
Ne pas remplir les autres champs, ils deviendront grisés une fois l'URL de vos méta données renseignées.
Vous devez maintenant rattacher votre SP à la fédération de Test via le guichet.
Votre SP est maintenant dans la Fédération de Test. Un délai peut être 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 les IdPs.
Les valeurs des autres champs seront automatiquement extraites du fichier de méta-données de votre SP. Il n'est donc pas nécessaire de les renseigner.
Une fois que vous avez validé le formulaire, votre fournisseur de services est automatiquement enregistré dans la fédération de test. Vous pouvez maintenant essayer d'accéder à votre fournisseur de services sur https://monposte.fr/secure avec un navigateur :
shibboleth2.xml ;Fédération Éducation-Recherche - IdP de Test ;etudiant1, mot de passe: etudiant1) ; all SHIB headers- (HTTP_SHIB_ATTRIBUTES is not shown in this list)
(REMOTE_USER) etudiant1@renater.fr
...
cnDupont Jean
displayName Jean Dupont
entitlement urn:mace:dir:entitlement:common-lib-terms
eppn etudiant1@renater.fr
facsimileTelephoneNumber 0102030405
givenName Jean
l Paris
mail jean.dupont@univ-test.fr
nickname Jean
o univ-test
org-dn dc=univ-test,dc=fr
orgunit-dn o=maths,dc=univ-test,dc=fr
ou maths
preferredLanguage FR
primary-affiliation student
primary-orgunit-dn o=maths,dc=univ-test,dc=fr
sn Dupont
supannActivite {CNU}5404
supannAutreTelephone 1234567890
...
Vous remarquerez que :
REMOTE_USER prend la valeur de l'identifiant institutionnel (aussi appelé eduPersonPrincipalName ou eppn), cf élément ApplicationDefaults/REMOTE_USER de shibboleth2.xml.Shib- ; il s'agit de variables internes positionnées automatiquement par la brique Shibboleth./etc/shibboleth/attribute-map.xml.
Nativement, la version 2 du SP Shibboleth propose une fonctionnalité d'affichage de tous les attributs utilisateurs de la session courante. Il suffit d'accéder à l'URL https://monposte.fr/Shibboleth.sso/Session. Pour afficher les valeurs des attributs lors de l'accès à ce script mettez, dans le fichier shibboleth2.xml l'option suivante à « true » :
<Handler type="Session" Location="/Session" showAttributeValues="true"/>
Prévoir un redémarrage du service shibd pour la prise en compte des modifications dans le fichier shibboleth2.xml
service shibd restart
HTTP_SHIB_ car elles étaient transmises sous formes d'entêtes HTTP.
/var/log/shibboleth/shibd.log) ainsi que les logs du fournisseur d'identités de test https://services-federation.renater.fr/viewlogs?fournisseur=idp-test-error
Erreur « Unknown service provider » : une erreur qui arrive fréquemment (sur la page d'URL de l'IdP). En général elle est due à une différence entre la valeur de entityID déclarée dans les méta-données via le formulaire web et la valeur de l'attribut entityID déclarée dans la configuration shibboleth2.xml. Veillez à ce qu'il n'y ait aucune différence de caractère entre ces deux valeurs (http vs https, sans slash à la fin vs avec slash à la fin, etc.). Si c'est le cas corrigez votre déclaration dans la configuration shibboleth2.xml, relancez le démon shibd, supprimez vos cookies, puis retestez.
Erreur « Unable to locate metadata for identity provider (https://idp.example.org/shibboleth) » : vous avez probablement oublié de commenter l'élément de configuration SSO/entityID dans le fichier shibboleth2.xml par défaut.
Jusque là nous avons utilisé le service de découverte de Test associé à la fédération de Test. Pour un service en production, vous devrez impérativement installer un DS/WAYF reconnaissant les fournisseurs d'identités de la fédération Éducation-Recherche. Vous pouvez n'installer qu'une seule instance pour les besoins de votre établissement.
L'avantage d'installer un service de découverte au plus près de vos applications est de pouvoir le mettre en conformité avec la charte graphique de l'application. De plus, il est possible de filtrer à ce niveau les fournisseurs d'identités acceptés pour votre application. Cela évite de lister des fournisseur d'identités qui ne sont pas acceptés et laisser leurs utilisateurs s'authentifier pour se voir refuser l'accès par la suite.
Nous allons installer un service de découverte en utilisant l'implémentation de SWITCH : https://www.switch.ch/aai/support/tools/wayf.html
# cd /usr/local/src
# mkdir /usr/local/SWITCHwayf_1.20.1
# wget --no-check-certificate https://forge.switch.ch/attachments/download/1879/SWITCHwayf_1.20.1_r3265_20151222.zip
# unzip -d /usr/local/SWITCHwayf_1.20.1 SWITCHwayf_1.20.1_r3265_20151222.zip
# ln -s /usr/local/SWITCHwayf_1.20.1 /usr/local/SWITCHwayf
# chown -R apache:apache /usr/local/SWITCHwayf
Le WAYF est développé en PHP ; vous devez donc installer PHP sur le serveur. La dernière version du WAYF nécessite une version 5.2 ou supérieure de PHP.
Le WAYF utilise les librairies DOM XML de PHP pour traiter les fichiers XML de méta-données. Il est donc nécessaire d'installer le paquet php-xml :
# yum install php-xml
Nous allons configurer le serveur web pour ouvrir l'accès au WAYF.
Créez le fichier de configuration /etc/httpd/conf.d/wayf.conf.
** ## Configuration du WAYF** ** <Files WAYF>** ** ForceType application/x-httpd-php** ** </Files>** ** Alias /wayf /usr/local/SWITCHwayf**
Redémarrons le serveur web :
# service httpd reload
L'arborescence est la suivante par défaut :
default- sont personnalisables en dérivant un fichier ayant pour préfixe custom-. Exemple : default-header.php personnalisé en custom-header.php.config.php
Le WAYF propose deux modes de fonctionnement :
IDProvider.conf.php.La première solution évite de devoir gérer la liste des IdP (adapté pour lister tous les IdP d'une fédération).
La seconde a pour avantage de permettre aux SPs utilisant le WAYF de ne garder que les IdP qu'elle reconnait et de les présenter de façon catégorisée, voir l'exemple de SWITCH : https://aai-demo.switch.ch/secure/.
Le fichier IDProvider.conf.php permet également de gérer des exceptions, comme nous allons le voir avec les Comptes CRU.
Nous allons configurer le WAYF pour utiliser les méta-données de la fédération de test.
# cd /usr/local/SWITCHwayf
# cp IDProvider.conf.dist.php IDProvider.conf.php
# cp config.dist.php config.php
Adaptez le fichier de configuration config.php :
// Domain within the WAYF cookie shall be readable. Must start with a . ** $commonDomain = '.monposte.fr'; ** ... // Set to true in order to enable dynamic generation of the IdP list displayed ** $useSAML2Metadata = true; ** ... // If true, the users IP is used for a reverse DNS lookup whose // resulting domain name then is matched with the URN values of the IdPs ** $useReverseDNSLookup = true;** // Whether the JavaScript required for embedding the WAYF // on a remote site shall be generated or not ** $useEmbeddedWAYF = true;** ... // Les logs du wayf sont stockés dans le répertoire de log d'apache ** $WAYFLogFile = '/var/log/shibboleth/wayf.log';** ... // Use $metadataFile as source federation's metadata. // Nous pointons vers le fichier de méta-données maintenu à jour // par la brique SP Shibboleth ** $metadataFile = '/var/cache/shibboleth/preview-all-renater-test-metadata.xml'; **
Nous allons modifier la configuration du SP pour utiliser notre nouveau service WAYF.
<SSO discoveryProtocol="SAMLDS" discoveryURL=**"https://monposte.fr/wayf/WAYF"**> SAML2 SAML1 </SSO>
Redémarrons le serveur web et le démon shibd pour prendre en compte le changement de configuration:
# service httpd reload
# service shibd restart
Vous pouvez tester le bon fonctionnement du WAYF en accédant à https://monposte.fr/secure/.
Vous remarquerez l'organisation particulière des IdP dans le menu déroulant ; cette organisation est due au fichier de configuration IDProvider.conf.php.
Pour forcer le rechargement des méta-données :
L'IdP des Comptes CRU fait partie par défaut de la Fédération de test mais n'est pas présent dans les méta-données de la fédération Éducation-Recherche. En effet, ce fournisseur d'identités, contrairement à ceux opérés par les établissements d'enseignement supérieur, n'a pas de périmètre délimité : n'importe qui peut ouvrir un compte CRU. Conséquence de ce mode de fonctionnement : le nombre d'attributs utilisateurs fournis par l'IdP des Comptes CRU est limité (nom, prénom, adresse email, eduPersonPrincipalName, persistentID).
Au moment de passer votre SP en production, vous pouvez choisir d'ajouter la confiance dans les Comptes CRU, afin d'ouvrir l'accès aux personnes extérieures ou ne disposant pas encore d'un IdP Shibboleth dans leur établissement. Pour cela vous devez configurer votre SP Shibboleth mais également votre service de découverte.
Nous allons illustrer l'adaptation d'une application pour la rendre compatible avec Shibboleth. Pour ce faire, nous utilisons une application simple, développée par RENATER pour l'occasion : un petit moteur de Blog. Nous proposons deux implémentations strictement équivalentes écrites en Perl et en PHP. Pour la suite, vous devrez choisir l'implémentation qui a votre préférence.
Notre application myBlog est un bon cobaye car elle a les caractéristiques suivantes :
Après la phase d'installation de l'application, nous allons l'adapter pour lui permettre d'utiliser l'authentification Shibboleth. Cette adaptation va se faire en plusieurs étapes, illustrant les différents modes/niveaux d'intégration d'une application avec Shibboleth.
Vérifiez que le paquetage perl-Template-Toolkit.x86_64 est présent sur la machine sinon installez le :
# yum install perl-Template-Toolkit.x86_64
Téléchargez l'application :
# cd /var/www/cgi-bin
# wget https://test.federation.renater.fr/exemples/myBlog.tar.gz
# tar -xvzf myBlog.tar.gz
myBlog/ myBlog/blog.pl myBlog/Billet.pm myBlog/users myBlog/templates/ myBlog/templates/index.tt2.html
Vous devez ensuite aménager un point d'accès à l'application, dans le fichier de configuration de Apache au niveau d'un ScriptAlias déjà existant :
... ScriptAlias /myBlog /var/www/cgi-bin/myBlog/blog.pl
Téléchargez l'application depuis le site de RENATER :
# cd /var/www/cgi-bin
# wget https://test.federation.renater.fr/exemples/myBlog_PHP.tar.gz
# tar -xvzf myBlog_PHP.tar.gz
myBlog_PHP/ myBlog_PHP/templates/ myBlog_PHP/templates/index.tpl.php myBlog_PHP/index.php myBlog_PHP/billets/ myBlog_PHP/Blog.class.php myBlog_PHP/Billet.class.php myBlog_PHP/users
# chown -R apache.apache myBlog_PHP
Vous devez ensuite aménager un point d'accès à l'application, dans le fichier de configuration de Apache :
... ScriptAlias /myBlog /var/www/cgi-bin/myBlog_PHP/index.php
Redémarrez ensuite votre serveur Apache pour prendre en compte la modification :
# service httpd restart
Vous pouvez tester que l'application répond en accédant avec votre navigateur à https://monposte.fr/myBlog
L'application myBlog permet de gérer des billets. La liste des billets est accessible publiquement, alors que la création d'un billet requiert une authentification de l'utilisateur. Le droit de supprimer un billet est réservé à l'auteur de celui-ci ou à un administrateur. Les mots de passe des utilisateurs ainsi que leur profil (admin ou user) sont définis dans le fichier myBlog/users :
PERL version : # cat /var/www/cgi-bin/myBlog/users
PHP version : # cat /var/www/cgi-bin/myBlog_PHP/users
user1:pwd1:admin user2:pwd2:user
Le CGI rendant le service est myBlog/blog.pl. La session d'authentification avec l'utilisateur est maintenue via le cookie HTTP intitulé BLOG_USER.
La librairie myBlog/Billet.pm définit les fonctions métier.
Les pages web sont définies dans un unique modèle de page myBlog/templates/index.tt2.html.
Le CGI rendant le service est myBlog_PHP/index.php. La session d'authentification avec l'utilisateur est maintenue via le cookie HTTP intitulé BLOG_USER.
Les bibliothèques myBlog_PHP/Blog.class.php et myBlog_PHP/Billet.class.php définissent les fonctions métier.
Les pages web sont définies dans un unique modèle de page myBlog_PHP/templates/index.tpl.php.
Vous pouvez tester l'authentification native de l'application, l'écriture et le listage de billets avec les logins et mot de passe définis dans myBlog/users.
L'intégration minimale consiste à activer une authentification Shibboleth systématique en amont de l'application. L'utilisateur devra donc systématiquement s'authentifier pour accéder à l'application. La brique SP Shibboleth oriente l'utilisateur vers son fournisseur d'identités (utilisation d'un IdP de test à défaut). Une fois l'utilisateur authentifié, il est redirigé vers l'application myBlog ; l'application reçoit les attributs de l'utilisateur via des variables d'environnement HTTP. Il faudra donc modifier l'application pour exploiter l'identifiant de l'utilisateur ainsi reçu via Shibboleth et ne plus proposer la fonction d'authentification native.
Nous allons éditer la configuration Apache pour activer l'authentification Shibboleth lors de l'accès à l'URL /myBlog.
... <Location /myBlog> AuthType shibboleth ShibRequestSetting requireSession 1 require shibboleth </Location>
# service httpd reload
On modifie à présent le fichier users afin d'ajouter l'utilisateur dont l'identifiant (EPPN) est etudiant1@univ-test.fr pour lui assigner un rôle user :
user1:pwd1:admin user2:pwd2:user **etudiant1@univ-test.fr:null:user**
Le workflow d'un mécanisme d'invitation en vue de recueillir des EPPN est le suivant :
Si vous accédez à nouveau à l'application https://monposte.fr/myBlog vous passerez par une authentification Shibboleth. Dans le cas présent, vous ne le remarquerez pas forcément car le SP vous a déjà authentifié lors de l'accès à https://monposte.fr/secure. Pour dérouler entièrement la séquence d'authentification, effacez tous les cookies de votre navigateur puis accédez à nouveau à l'application.
Pour l'instant l'application n'est pas capable d'exploiter les attributs qui lui sont transmis par le SP Shibboleth : vous le constatez en voyant que vous n'êtes pas connecté en arrivant sur https://monposte.fr/myBlog après la séquence Shibboleth. En effet, l'application n'a pas encore été adaptée pour exploiter les attributs remontés par Shibboleth.
Quand un utilisateur est effectivement authentifié sur un IdP via Shibboleth, le module SP reçoit en retour une assertion SAML contenant en général un identifiant de l'utilisateur et d'autres attributs. Le module SP analyse cette assertion et en extrait les différents attributs pour renseigner des en-têtes HTTP. Cette mise en correspondance entre les attributs de l'assertion SAML et les en-têtes HTTP est définie dans le fichier attribute-map.xml. Par exemple, la valeur de l'attribut urn:mace:dir:attribute-def:displayName est positionnée dans l'en-tête displayName.
L'en-tête REMOTE_USER fait exception, il est lui défini via shibboleth2.xml :
REMOTE_USER=“persistent-id targeted-id”
Cette règle indique au SP de renseigner cet en-tête d'abord avec l'en-tête mail (issu de l'attribut urn:mace:dir:attribute-def:mail fourni par l'IdP) et s'il n'existe pas avec l'en-tête persistent-id et s'il n'existe pas non plus avec targeded-id.
Tous ces en-têtes HTTP sont automatiquement mis à disposition des applications par le serveur Apache sous forme de variables d'environnement. Pour qu'une application accède aux attributs remontés par Shibboleth, il suffit donc que son code lise ces variables d'environnement.
Exploitons ce mécanisme dans myBlog pour authentifier l'utilisateur via Shibboleth : il suffit à l'application de vérifier si la variable d'environnement REMOTE_USER a une valeur.
... my %cookies = fetch CGI::Cookie; ** if ($ENV{'eppn'}) {** ** $requete->{'utilisateur'} = $ENV{'eppn'};** ** my $users = &charge_users();** ** $requete->{'role_utilisateur'} = $users->{$requete->{'utilisateur'}}{'role'};** ** }** elsif (defined %cookies && $cookies{'BLOG_USER'}) { $requete->{'utilisateur'} = $cookies{'BLOG_USER'}->value; my $users = &charge_users(); $requete->{'role_utilisateur'} = $users->{$requete->{'utilisateur'}}{'role'}; }
Cette modification du code permet d'initialiser une session utilisateur si la variable d'environnement eppn est positionnée.
On peut également exploiter le nom de l'utilisateur (displayName) pour l'afficher dans l'application à la place de l'identifiant :
... if ($ENV{'eppn'}) { $requete->{'utilisateur'} = $ENV{'eppn'}; ** $requete->{'nom_utilisateur'} = $ENV{'displayName'};** my $users = &charge_users(); $requete->{'role_utilisateur'} = $users->{$requete->{'utilisateur'}}{'role'};
[% IF utilisateur %]Logged in as <strong>**[% IF nom_utilisateur %][% nom_utilisateur %][% ELSE %][% utilisateur %][% END %]**</strong><br/>[% END %] [% IF role_utilisateur %]Role : [% role_utilisateur %]<br/>[% END %]
... **if(getenv('eppn') != '') {** **$this->utilisateur = getenv('eppn');** **$users = self::chargeUsers();** **$this->role_utilisateur = $users[$this->utilisateur]['role'];** **}** else if(isset($_COOKIE['BLOG_USER']) && !empty($_COOKIE['BLOG_USER'])) { $this->utilisateur = $_COOKIE['BLOG_USER']; $users = self::chargeUsers(); $this->role_utilisateur = $users[$this->utilisateur]['role']; }
Cette modification du code permet d'initialiser une session utilisateur si la variable d'environnement eppn est positionnée.
On peut également exploiter le nom de l'utilisateur (displayName) pour l'afficher dans l'application à la place de l'identifiant :
var $utilisateur = ''; **var $nom_utilisateur = '';** var $role_utilisateur = ''; ... if(getenv('eppn') != '') { $this->utilisateur = getenv('eppn'); **$this->nom_utilisateur = getenv('displayName');** $users = self::chargeUsers(); $this->role_utilisateur = $users[$this->utilisateur]['role'];
**<?php if($this->utilisateur != '') echo 'Logged in as <strong>'.(($this->nom_utilisateur != '') ? $this->nom_utilisateur : $this->utilisateur).'</strong><br />'; ?>** <?php if($this->role_utilisateur != '') echo 'Role : '.$this->role_utilisateur.'<br />'; ?>
Connectez-vous sur https://monposte.fr/myBlog pour vérifier qu'après la séquence d'authentification via Shibboleth vous arrivez connecté avec l'identité de votre IdP de Test.
eppn, mail et displayName) est codé en dur. Si vous adaptez une application en production, rendez ces variables paramétrables afin de vous adapter à des évolutions de Shibboleth ou l'utilisation d'autres logiciels de d'authentification.
Vous remarquerez que la fonction de déconnexion de l'application ne rend plus son office puisque lorsque vous cliquez sur le lien logout, vous êtes effectivement déconnecté, mais si vous vous rendez de nouveau sur https://monposte.fr/myBlog vous vous retrouvez à nouveau connecté. En effet, la déconnexion n'a pas été propagée depuis l'application jusqu'au SP Shibboleth. Ce dernier maintient toujours une session pour l'utilisateur, et continue donc à transmettre à chaque requête du navigateur à l'application les variables d'environnement où l'identité de l'utilisateur est positionnée : pour l'application c'est comme si l'utilisateur était à nouveau connecté via Shibboleth.
La session utilisateur au niveau du SP Shibboleth peut être terminée en redirigeant l'utilisateur vers une URL de la forme https://monposte.fr/Shibboleth.sso/Logout. Cependant cette déconnexion ne s'applique que localement, elle n'est propagée ni au fournisseur d'identités (et au serveur CAS associé), ni aux autres applications auprès desquelles l'utilisateur est éventuellement connecté.
Nous allons donc mettre en œuvre la déconnexion Shibboleth locale. Pour cela nous allons modifier la fonction req_logout() de notre application pour orienter l'utilisateur vers cette URL de logout Shibboleth, une fois le logout applicatif effectué :
... ## Logout sub req_logout { my $self = shift; delete $self->{'utilisateur'}; delete $self->{'role_utilisateur'}; **## L'utilisateur est ensuite redirigé vers l'URL de logout Shibboleth** **## L'URL de retour correspond à l'URL du script** ** $self->{'url_redirection'} = 'https://monposte.fr/Shibboleth.sso/Logout?return=https://monposte.fr/myBlog';** **## LIGNE A RETIRER $self->{'next_action'} = 'index';** return 1; }
... function req_logout() { $this->utilisateur = ''; $this->role_utilisateur = ''; ** $this->url_redirection = 'https://monposte.fr/Shibboleth.sso/Logout?return=https://monposte.fr/myBlog';** **// LIGNE A RETIRER $this->next_action = 'index';** }
Rechargez la page https://monposte.fr/myBlog pour prendre en compte cette modification, puis cliquez sur le lien logout pour tester cette déconnexion locale. Vous remarquerez que, à la suite du logout, vous êtes à nouveau orienté vers la séquence d'authentification Shibboleth. En effet, nous avons activé une authentification systématique en amont du CGI ; nous allons maintenant essayer de faire mieux.
Le mécanisme des lazy sessions est propre à Shibboleth. Ce mécanisme permet de déclencher la phase d'authentification de l'utilisateur, non plus à l'initiative de la directive ShibRequestSetting requireSession 0 définie dans Apache en amont de l'application, mais depuis l'application : c'est l'application qui déclenche, quand elle le souhaite, la séquence Shibboleth. Pour ce faire, l'application redirige le navigateur de l'utilisateur vers une URL spécifique pour le SP Shibboleth : c'est seulement quand il est contacté via cette URL spécifique que l'authentification sur le SP Shibboleth est déclenchée.
Nous allons modifier notre blog pour déclencher l'authentification Shibboleth lorsque l'utilisateur cliquera sur un nouveau lien login Shibboleth. L'opération déclenchée par ce clic sera l'envoi d'un entête HTTP de redirection (Location: url) afin d'envoyer le navigateur de l'utilisateur vers l'URL spécifique d'activation du SP Shibboleth.
Dans la configuration du serveur Apache, nous allons modifier la directive commandant le déclenchement de l'authentification Shibboleth :
<Location /myBlog> AuthType shibboleth ** ShibRequestSetting requireSession 0** ** require shibboleth** </Location>
ShibRequestSetting requireSession 0 empêche Shibboleth de se déclencher automatiquement. La directive require shibboleth est nécessaire dans le contexte des lazy sessions pour permettre à Apache de faire appel au module mod_shib sans définir de règle de contrôle d'accès spécifique.
Relancez Apache pour prendre en compte ces modifications :
# service httpd restart
Documentation de référence : https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessionCreationParameters
Le mécanisme de lazy sessions est déclenché lorsque l'utilisateur est redirigé vers une URL prévue à cette effet. Cette URL, utilisée dans votre application, n'est pas directement présente dans le fichier de configuration de Shibboleth ; vous devez construire cette URL à partir de plusieurs éléments définis dans votre fichier shibboleth2.xml, de la façon suivante :
handler_url + ref_session_initiator + paramètres
Dans notre cas de figure, cette URL est la suivante :
https://monposte.fr/Shibboleth.sso/Login?target=https://monposte.fr/myBlog
Le paramètre target permet de spécifier l'adresse de retour, une fois l'utilisateur authentifié.
Si l'URL spécifiée par le paramètre target comprend des caractères gênants dans une URL, vous devrez prendre soin de les échapper préalablement.
Nous allons ajouter un nouveau lien de login à l'interface graphique de l'application ; l'utilisateur pourra ainsi s'authentifier avec la méthode pré-existante ou avec Shibboleth.
[% ELSE %]<a href="[% chemin_cgi %]?action=login">login</a> ** | <a href="[% chemin_cgi %]?action=shiblogin">login avec Shibboleth</a>[% END %] **
Nous allons créer une nouvelle fonction req_shiblogin() qui sera associée à l'action shiblogin de notre blog :
... }elsif ($self->{'action'} eq 'login') { $self->req_login(); **}elsif ($self->{'action'} eq 'shiblogin') {** ** $self->req_shiblogin();** }elsif ($self->{'action'} eq 'logout') { $self->req_logout(); }elsif ($self->{'action'} eq 'effacer') { $self->req_effacer(); } ... ** ## Shibboleth Login** ** sub req_shiblogin {** ** my $self = shift;** ** $self->{'url_redirection'} = 'https://monposte.fr/Shibboleth.sso/Login?target=https://monposte.fr/myBlog';** ** return 1;** **}** ## Logout sub req_logout {
Nous allons ajouter un nouveau lien de login à l'interface graphique de l'application ; l'utilisateur pourra ainsi s'authentifier avec la méthode pré-existante ou avec Shibboleth.
else echo '<a href="?action=login">login</a> **| <a href="?action=shiblogin">login avec Shibboleth</a>'**; ?>
Nous allons créer une nouvelle méthode req_shiblogin() qui sera associée à l'action shiblogin de notre blog :
... }else if($this->action == 'login') { $this->req_login(); **}else if($this->action == 'shiblogin') {** ** $this->req_shiblogin();** }else if($this->action == 'logout') { $this->req_logout(); }else if($this->action == 'effacer') { $this->req_effacer(); } ... **## Shibboleth Login** **function req_shiblogin() {** ** $this->url_redirection = 'https://monposte.fr/Shibboleth.sso/Login?target=https://monposte.fr/myBlog';** **}** ## Logout function req_logout() {
Vous pouvez maintenant tester la nouvelle fonction de login Shibboleth en accédant à https://monposte.fr/myBlog puis en cliquant sur « Login avec Shibboleth ».
Documentation de référence: http://www.switch.ch/aai/support/serviceproviders/sp-embedded-wayf.html
Le WAYF de SWITCH implémente une fonctionnalité originale qui permet à une application d'inclure le code javascript permettant de générer le menu déroulant du WAYF.
Nous allons adapter le modèle de page HTML du moteur de blog pour y ajouter le « embedded WAYF ».
Nous allons ajouter le code javascript incluant le WAYF dans notre modèle de page.
Si vous avez choisi l'implémentation Perl, éditez /var/www/cgi-bin/myBlog_PHP/templates/index.tpl.php
Si vous avez choisi l'implémentation PHP, éditez /var/www/cgi-bin/myBlog/templates/index.tt2.html :
code à rajouter après la balise : <body> <!-- EMBEDDED-WAYF-START --> <script type="text/javascript"><!-- //////////////////// ESSENTIAL SETTINGS //////////////////// // EntityID of the Service Provider that protects this Resource // [Mandatory] wayf_sp_entityID = "https://monposte.fr"; // Shibboleth Service Provider handler URL // Examples: "https://point.switch.ch/Shibboleth.sso", "https://rr.aai.switch.ch/aaitest/Shibboleth.sso" // [Mandatory, if wayf_use_discovery_service = false] var wayf_sp_handlerURL = "https://monposte.fr/Shibboleth.sso"; // Session Initiator URL of the Service Provider var wayf_sp_samlDSURL = wayf_sp_handlerURL + "/Login"; // URL of the WAYF to use // [Mandatory] wayf_URL = "https://monposte.fr/wayf/WAYF"; // URL on this resource that the user shall be returned to after authentication // [Mandatory] wayf_return_url = "https://monposte.fr/myBlog"; // Whether to show the checkbox to remember settings for this session var wayf_show_remember_checkbox = false; // Width of the embedded WAYF in pixels or "auto" var wayf_width = 205; // Overwrites the text of the submit button var wayf_overwrite_submit_button_text = 'Go'; // Overwrites the intro text above the drop-down list var wayf_overwrite_intro_text = 'Login shibboleth'; // Whether to hide the WAYF after the user was logged in // If you want to hide the embedded WAYF completely, uncomment // the property and set it to "". This then won't draw anything var wayf_logged_in_messsage = "Vous êtes authentifié"; // If enabled, the Embedded WAYF will activate the // improved drop down list feature, which will transform the list of // organisations into a search-field while keeping its original function as // a select list. To make this work, the JQuery library will dynamically be // loaded if it is not yet present. Additionally, another Javascript and CSS // file are loaded to perform the actual transformation. // Please note that this feature will also display the organisations' logos, // which might be loaded from a remote domain. While generally not especially // dangerous, there is always a risk when loading content (in this case // images) from third party hosts. // [Optional, default: false] var wayf_use_improved_drop_down_list = true; //--> </script> <script type="text/javascript" src="https://monposte.fr/wayf/WAYF/embedded-wayf.js"></script> <noscript> <!-- Fallback to Shibboleth DS session initiator for non-JavaScript users You should set the value of the target GET parameter to an URL-encoded absolute URL that points to a Shibboleth protected web page where the user is logged in into your application. --> <p> <strong>Login:</strong> Javascript is not available for your web browser. Therefore, please <a href="/Shibboleth.sso/Login?target=">proceed manually</a>. </p> </noscript> <!-- EMBEDDED-WAYF-END --> <div class="footer">Powered by myBlog</div>
Vous pouvez tester le nouveau WAYF en accédant à l'application myBlog après avoir supprimé tous vos cookies.
Pour un exemple de code complet (avec toutes les options) du WAYF RENATER, accédez l'URL https://discovery.renater.fr/renater/WAYF/embedded-wayf.js/snippet.html
Cette solution offre à la fois un bon niveau d'intégration (puisque le menu déroulant du WAYF est directement dans l'application) et est peu intrusive dans l'application.
Les intérêts de cette solution pour le mainteneur de l'application :
Les intérêts pour les utilisateurs :
Présentation de SWITCH : http://www.terena.org/activities/eurocamp/november07/slides/hemmerle-aa_enabling_applications.pdf
Article JRES 2009 : https://services.renater.fr/federation/docs/fiches/shibbolisation
Nous vous donnons ici quelques conseils très pratiques pour implémenter une authentification Shibboleth dans votre application :
Documentation :
On entend par configuration bilatérale une relation entre un IdP et un SP, sans passer par l'inscription dans une fédération. Dans ce cas, au lieu de configurer l'URL des méta-données de la fédération, on configure l'URL des méta-données propres du SP ou de l'IdP.
Comme vu précédemment l'IdP Shibboleth présente l'inconvénient de ne pas proposer une génération dynamique de ses méta-données propres. Il est donc nécessaire de configurer à la main le fichier metadata/idp-metadata.xml pour personnaliser les éléments suivants : entityID, certificat, URLs.
Vous gérez une application locale, utilisable par les utilisateurs de quelques établissements uniquement (contexte UNR ou PRES par exemple). Deux possibilités s'offrent à vous : inscrire ce SP dans la fédération Éducation-Recherche ou gérer les relations bilatérales entre SP et IdPs.
Si tous les IdP sont inscrits dans la fédération Éducation-Recherche, vous pouvez configurer votre SP Shibboleth pour exploiter les méta-données de la fédération.
Il est également possible de gérer des configurations bilatérales (configurer le SP avec les méta-données individuelles de chaque IdP). Cette solution est plus lourde à administrer et doit donc être réservée à des cas particuliers (utilisation de profils SAML spécifiques, relation avec des IdP extérieurs à la Fédération Éducation-Recherche).
Chaque IdP doit charger les méta-données propres du SP.
Exemple de configuration d'un des IdPs, utilisant les méta-données dynamiques de notre SP :
<metadata:MetadataProvider id="ShibbolethMetadata" xsi:type="ChainingMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"> ... <!-- Méta-données d'un SP local --> ** <metadata:MetadataProvider id="LocalSP" xsi:type="FileBackedHTTPMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata" ** ** metadataURL="https://monposte.fr/Shibboleth.sso/Metadata"** ** backingFile="/opt/shibboleth-idp/metadata/localsp.xml">** ** </metadata:MetadataProvider>** </metadata:MetadataProvider>
Redémarrez le serveur Tomcat :
# service tomcat restart
Vous pouvez vérifier que l'authentification en amont de votre SP fonctionne toujours et que l'IdP a téléchargé une copie des méta-données du SP dans le répertoire /opt/shibboleth-idp/metadata/.
Il s'agit d'un cas d'utilisation où un SP ne reconnaît qu'un seul IdP, par exemple lorsque Shibboleth est utilisé en interne dans un établissement, à la place de CAS. Le SP est configuré pour utiliser les méta-données propres de l'IdP ; l'utilisateur n'est plus orienté vers le WAYF puisque que le SP ne reconnaît qu'un seul IdP.
Vous devez au préalable personnaliser le fichier de méta-données de l'IdP. Nous indiquons ci-dessous les partie du fichier de méta-données à adapter à votre configuration :
<EntityDescriptor entityID="https://**monposte.fr**/idp/shibboleth" xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:shibmd="urn:mace:shibboleth:metadata:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <IDPSSODescriptor protocolSupportEnumeration="urn:mace:shibboleth:1.0 urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol"> <Extensions> <shibmd:Scope regexp="false">**univ-test.fr**</shibmd:Scope> </Extensions> <KeyDescriptor> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> **MIIDZ....** </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </KeyDescriptor> <ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://**monposte.fr**:8443/idp/profile/SAML1/SOAP/ArtifactResolution" index="1"/> <ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://**monposte.fr**:8443/idp/profile/SAML2/SOAP/ArtifactResolution" index="2"/> <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat> <SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" Location="https://**monposte.fr**/idp/profile/Shibboleth/SSO" /> <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://**monposte.fr**/idp/profile/SAML2/POST/SSO" /> <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://**monposte.fr**/idp/profile/SAML2/POST-SimpleSign/SSO" /> <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://**monposte.fr**/idp/profile/SAML2/Redirect/SSO" /> </IDPSSODescriptor> <AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol"> <Extensions> <shibmd:Scope regexp="false">**univ-test.fr**</shibmd:Scope> </Extensions> <KeyDescriptor> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> **MIID...** </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </KeyDescriptor> <AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://**monposte.fr**:8443/idp/profile/SAML1/SOAP/AttributeQuery" /> <AttributeService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://**monposte.fr**:8443/idp/profile/SAML2/SOAP/AttributeQuery" /> <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat> </AttributeAuthorityDescriptor> </EntityDescriptor>
Configurons le SP pour prendre en compte le fichier de méta-données de l'IdP.
<SSO entityID="https://**monposte.fr**/idp/shibboleth" discoveryProtocol="SAMLDS" discoveryURL="https://**monposte.fr**/wayf/WAYF"> SAML2 SAML1 </SSO> ... <MetadataProvider type="XML" uri="https://**monposte.fr**/idp/profile/Metadata/SAML" backingFilePath="monidp-metadata.xml" reloadInterval="7200"> </MetadataProvider>
Documentation RENATER : https://services.renater.fr/federation/docs/fiches/passageprod
Pour finaliser l'installation avant le passage en production quelques changements s'imposent :
shibboleth2.xml <ApplicationOverride>Les quatre étapes sont donc les suivantes.
... <!-- Meta-données de la fédération de Éducation-Recherche --> <MetadataProvider type="XML" uri="**https://metadata.federation.renater.fr/renater/main/main-all-renater-metadata.xml**" backingFilePath="**main-all-renater-metadata.xml**" reloadInterval="7200"> <SignatureMetadataFilter certificate="/etc/shibboleth/renater-metadata-signing-cert-2016.pem"/> (Autres attributs possibles...) </MetadataProvider> ...
Il faut ensuite ajouter dans les règles Apache (dans le fichier shib.conf par exemple) des directives du types :
<Location "/ressource/production">
AuthType shibboleth
require shib-session
ShibRequestSetting requireSession 0
ShibRequestSetting applicationId ressource-production
ShibUseHeaders on #Utilisation explicite des entêtes HTTP pour les attributs
</Location>
Il est conseillé de laisser le <ApplicationDefaults> décrire la SP de test et de spécifiquement créer des <ApplicationOverride> pour décrire tout nouveau SP en production. On peut ainsi définir une seule fois les paramètres communs à chaque application (au niveau ApplicationDefaults) et définir les paramètres spécifiques dans un élément ApplicationOverride.
Voir cet exemple :
<ApplicationDefaults ... <!-- SP de production --> <ApplicationOverride id="**ressource-production**" entityID="https://**monposte.fr/ressource/production**"> <Sessions lifetime="28800" timeout="3600" checkAddress="false" handlerURL="**/ressource/production/Shibboleth.sso**" handlerSSL="true"> ... </ApplicationOverride> </ApplicationDefaults> ...
Suivre les étapes suivantes : https://services.renater.fr/federation/participants/declarer-sp
Cette partie est optionnelle dans la réalisation du TP. Avant d'essayer ce qui y est proposé, vous pouvez si vous le souhaitez vous entretenir avec les formateurs au sujet de la « shibbolisation » de votre propre application.
Exemple avec les briques de test de la fédération :
https://services.renater.fr/federation/faq/wayf#court-circuiter_le_wayf
Vous pouvez vous inspirer de la documentation suivante qui montre comment ajouter la confiance dans plusieurs fédérations :
https://services.renater.fr/federation/technique/configurations/migration
Si l'accès à une application est bloqué à cause d'attributs manquants, le message d'erreur de l'application doit être précis et permettre à l'utilisateur de régler le problème. Cette fiche technique décrit comment exploiter des informations décrivant l'IdP de l'utilisateur, issues des méta-données SAML :
https://services.renater.fr/federation/docs/fiches/metadata-attributes
authentification : processus permettant de vérifier l'identité déclaré par un utilisateur. Exemples de procédé d'authentification : mot de passe, certificat électronique, biométrie.
autorisation : processus qui accorde ou non à un utilisateur authentifié l'accès à un service, selon ses attributs.
contrôle d'accès : voir autorisation.
fédération : ensemble d'organisations dont les membres coopèrent pour partager des services. Les différents acteurs d'une fédération sont les fournisseurs d'identités, les fournisseurs de services et le service de découverte. Le contrôle d'accès à un service est maîtrisé par l'organisation propriétaire du service, mais l'authentification des utilisateurs est déléguée à l'organisation à laquelle appartient l'utilisateur. Cette dernière peut également propager des attributs des utilisateurs jusqu'aux services selon leurs besoins. Ces mécanismes affranchissent les fournisseurs de services de la gestion en local des utilisateurs et de leur authentification. Quand aux utilisateurs, ils évitent l'apprentissage d'un nouveau mot de passe pour chaque service.
fournisseur d'identités ou Identity Provider ou IdP : organisation membre d'une fédération et qui gère l'identité informatique d'un ensemble d'utilisateurs : création, suppression et maintenance de leurs informations d'identification (par exemple une universités avec ses étudiants et ses personnels). Un fournisseur d'identités offre un service d'authentification à ses utilisateurs, qui leur permet de s'authentifier sur le réseau. Lorsqu'un utilisateur veut accéder à un service offert au sein de la fédération, il utilise le service d'authentification de son organisation d'appartenance pour s'authentifier. Un fournisseur d'identités peut définir les attributs de ses utilisateurs qu'il s'autorise à propager aux fournisseurs de services.
ressource numérique : ressource accessible via Internet par un navigateur. Exemples : cours en ligne, ressources bibliographiques, applications web, espace de stockage, etc.
fournisseur de services ou Service Provider ou SP : organisation membre d'une fédération et qui propose un service accessible via Internet : application web ou ressource numérique en ligne (pédagogique, scientifique, bibliothécaire, etc.). Le fournisseur de services n'a pas à gérer l'ensemble des utilisateurs susceptibles d'accéder au service. Il peut s'appuyer sur les fournisseurs d'identités de la fédération pour l'authentification des utilisateurs et pour obtenir les attributs des utilisateurs nécessaires au contrôle d'accès.
service de découverte ou Discovery Service ou Where Are You From ou WAYF : composant central dans une fédération qui permet à un utilisateur accédant à un service de sélectionner son organisation d'appartenance pour s'authentifier. Le service de découverte redirige l'utilisateur vers le service d'authentification de son organisation d'appartenance pour qu'il s'authentifie. Puis l'utilisateur authentifié est renvoyé vers le service voulu.
service d'authentification : service géré par le fournisseur d'identités, accessible en ligne et qui permet à tous ses utilisateurs de s'authentifier. Il peut être le service de Single Sign-On (CAS par exemple) de l'organisation, mais pas nécessairement.
Uniform Resource Name (URN) : identificateur d'une ressource. Un URN doit être choisi de telle sorte qu'il soit persistant, indépendant de la localisation de la ressource et pouvant être facilement mis en correspondance avec d'autres espaces de nommage. Le RFC 2141 définit la syntaxe des URN et cette page liste les RFC relatifs aux URN. Les entités d'une fédération (fournisseurs, attributs) sont désignées par des URN. Le CRU gérait l'espace de nommage urn:mace:cru.fr utilisé notamment pour son service de fédération.