La Fédération Éducation-Recherche met en relation des organismes proposant des ressources web (applications, portail, documents…) avec d'autres organismes gérant les identités d'utilisateurs accédant à ces ressources, les fournisseurs d'identité. Elle permet aux utilisateurs de réduire le nombre de mots de passe à retenir, étend les bénéfices de Single Sign On jusqu'à des applications hébergées en dehors de leurs institutions et offre à ces dernières une meilleure maîtrise de la diffusion de données à caractère personnel.

Pour plus d'informations, il vous est possible de consulter la documentation suivante.

Vous pouvez également vous abonner et échanger avec les autres membres dans la liste federation-utilisateurs@listes.renater.fr : https://listes.renater.fr/sympa/info/federation-utilisateurs

Dans une architecture de fédération d'identité, la brique Fournisseur d'Identité (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é reçoit des requêtes d'authentification de la part du fournisseur de services, via le navigateur web de l'utilisateur. L'utilisateur est ensuite orienté vers le fournisseur d'identité de son organisme, éventuellement associé à un 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é 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é consiste à :

1. gérer l'authentification de l'utilisateur, en relation avec l'annuaire LDAP ou le serveur CAS de l'organisme ;
2. établir les relations de confiance avec tous les fournisseurs de services membres de la fédération ;
3. configurer la constitution du profil utilisateur en relation avec le référentiel de l'organisme (typiquement un serveur LDAP) ;
4. paramétrer les règles de diffusion du profil utilisateur aux fournisseurs de service.

Les certificats x509 sont couramment utilisés dans la technologie de fédération d'identité. Il faut toutefois en distinguer 3 utilisations différentes :

1. pour la couche SSL, des certificats d'autorités de certifications reconnus dans les navigateurs doivent être utilisés pour sécuriser les flux SSL au niveau des serveurs web frontaux (Apache httpd) ou serveur d'application Java (Tomcat ou Jetty) si ce dernier n'est pas mis derrière un frontal HTTP.
2. pour la couche SAML, des certificats auto-signés sont générés lors de l'installation des briques IdP ou SP ou sont à créer afin de sécuriser les échanges entres ces mêmes briques techniques ; chiffrement ou signature des assertions SAML. La confiance dans ces certificats vient du fait qu'ils ont été déclarés et ajoutés aux enregistrements de tout fournisseur d'identité ou de service dans la fédération Éducation-Recherche.
   • Inline / Explicit Key Trust Engine, consortium Shibboleth
3. pour la signature des méta-données de la fédération Éducation-Recherche, un certificat est utilisé par RENATER pour signer ces méta-données et ainsi garantir leur intégrité.

• Upgrading from V2, consortium Shibboleth

Les développeurs du logiciel Shibboleth recommandent de ne pas effectuer une mise à jour de votre IdP Shibboleth 2.x en 3.x. En effet la version 3.x est une version majeure, impliquant de nombreuses modifications dans l'organisation des fichiers de configuration et le processus d'installation.

Vous devez donc prévoir l'installation de l'IdP Shibboleth 3.x sur un nouveau serveur, reporter vos éléments de configuration, vérifier son bon fonctionnement puis organiser la bascule vers ce nouveau serveur auprès du guichet fédération de RENATER.
Une procédure de migration vous est proposée dans les derniers chapitres de cette formation.

La procédure de migration d’un IdPV2 à un IdPV3:

1. Configurez un IdP V3 avec un entityID différent dans la fédération de test (ou fédération local dans votre cas);
2. Reportez les configuration de l’ancien IdP V2 de production (attribute filter, attribute resolver …);
3. Testez le bon fonctionnement de cet IdP dans la fédération de test;
4. Configurez l'IdP pour utiliser les métadonnées de la fédération de production;
5. Remplacez l'entityID de l'IdP v3 avec l'ancien entityID de l'IdP v2;
6. Si applicable, copiez la BDD SQL de l’IdP v2 sur le nouveau serveur et utiliser le même salt pour la génération du persistentID;
7. Au niveau du guichet de la fédération, remplacez le certificat de l'IdP2 en production avec le nouveau certificat (ou afin de limiter une interruption de service, ajoutez le nouveaux certificat tout en gardant l'ancien, puis attendre que ce dernier soit pris en compte dans la fédération de production par les différents SP de la fédération, maximum une journée);
8. Test depuis votre poste local (en modifiant votre /etc/host) que l’IdP est bien fonctionnel en production;
9. Changement DNS pour pointer sur le nouveau serveur avec l'IdP V3;
10. Après validation finale du fonctionnement, supprimer l’ancien certificat.

N'hésitez pas à nous contacter via https://assistance.renater.fr si vous avez des questions concernant cette procédure.

Dans le TP nous procèderons par étapes pour aboutir à un fournisseur d'identité Shibboleth opérationnel:

1. installer les prérequis.
2. installer la brique logicielle IdP Shibboleth.
3. effectuer une configuration minimale de l'IdP Shibboleth.
4. effectuer une relation bilatérale entre l'IdP Shibboleth et un SP local.
5. enregistrement de l'IdP Shibboleth dans la fédération de test.
6. validation de la configuration dans la fédération de test.
7. procédure d'inscription dans la fédération de production.
8. explorer les fonctionnalités avancés de l'IdP Shibboleth : Consentement utilisateur, personnalisation de l'IdP …