30 oct Installation d’un fournisseur de services Shibboleth Formation CRU 30 octobre 2008, Paris UPMC Formateurs : Vincent Carpier Mehdi Hached Olivier Salaün

30 oct Logistique Pause déjeuner : ~12h30 –où vous voulez –retour à 14h00 Fin de la formation : 17h00 Connexion sur les postes –identifiant : eleve ; MP : eleveshib –identifiant : root ; MP : 52!centos

30 oct Terminologie –IdP : fournisseur d’identités –SP : fournisseur de services –WAYF : service de découverte –SAML (Security Assertion Markup Language) : Protocole sous-jacent à Shibboleth –CAS : serveur de Single Sign-On

30 oct Objectif de la formation 1)Installation de la brique SP Shibboleth 2)Test auprès du fournisseur d'identités du CRU (« comptes CRU ») 3)Adaptation (« shibbolisation ») d'un exemple d'application 4)Discussions individualisées en fin de séance Ne couvre pas : –Mise en place d’un service opérationnel –Installation d’un fournisseur d'identités

30 oct Rappels sur Shibboleth –Logiciel « open source » : –Développé par un consortium issu de l'enseignement supérieur et recherche Internet2. –Deux briques distinctes : –fournisseur d'identités (1 par établissement membre) –fournisseur de services (1 par organisme partenaire) –Le TP couvre l'installation la brique SP Shibboleth en version 2.1 (publiée en juillet 2008)

30 oct Démonstration de Shibboleth

30 oct Référentiel utilisateurs Cinématique

30 oct Référentiel utilisateurs userId attributes userId attributes ticket Cinématique attributs password attributs

30 oct Fédération de test et fournisseur d'identités du CRU –Fédération de Test du CRU –Enregistrement validé automatiquement –Ouvert à tout SP/IdP –Compte de test à disposition –Pas d’usages en production –Fournisseur d'identités du CRU –Utilisable avec n’importe quel SP de test –Fonctionnement : authentification SSO-CAS et propagation d'attributs basiques –« Comptes CRU »

30 oct Les comptes CRU Pour les utilisateurs ne faisant pas partie d'un établissement ayant déjà un IdP : leur permet d'accéder à des ressources en production (ex. : SourceSup) Permettent l'accès aux gestionnaires Shibboleth à l'application de gestion des IdP/SP de la fédération du CRU Les comptes CRU sont shibbolisés par l'IdP du CRU, l'authentification est laissée au serveur CAS du CRU

30 oct La fédération du CRU –Service opérationnel depuis janvier 2006 –Le CRU gère –L’enregistrement des entités –La distribution des méta-données –Le support aux sites –Les membres –IdP : 49 établissements d’enseignement supérieur –SP : 54 ressources, principalement éditeurs de contenus + ressources régionales

30 oct Les 49 fournisseurs d'identités ENS LSH ENSAIT IUFM de Bretagne IUFM de Montpellier INPL PRES Nancy Université UTC Université Jean Monnet Université Paul Cézanne Université d'Angers Université d'Artois Université de Bordeaux 4 Université de Bourgogne Université de Bretagne Occidentale Université de Bretagne Sud Université de Grenoble 1 Université de Grenoble 2 Université de Grenoble 3 Université de Haute Alsace Université de La Rochelle Université de La Réunion Université de Lille 1 Université de Lille 2 Université de Limoges Université de Lyon 1 Université de Montpellier 1 Université de Montpellier 2 Université de Montpellier 3 Université de Nancy 1 Université de Nancy 2 Université de Nantes Université de Nice Université de Paris 1 Université de Paris 5 Université de Paris 7 Université de Pau Université de Perpignan Université de Poitiers Université de Provence Université de Reims Université de Rennes 1 Université de Rennes 2 Université de Rouen Université de Technologie de Troyes Université de Toulouse 1 Université de Valenciennes Université de la Méditerrannée Université du Littoral Université du Maine

30 oct La fédération RENATER Fédération à spectre élargi : Enseignement Supérieur + Recherche Notion d'organismes membres et d'organismes partenaires Une migration de la fédération du CRU vers la fédération Renater est en cours de préparation Entrée en phase pilote au 8 Décembre 2008 Ouverture prévue en production au mois de Février 2008

30 oct Compatibilité entre Shibboleth 1.3 et 2.x ● Le SP 2.x est est rétro-compatible avec un IdP 1.3 ● L'IdP 2.x est rétro-compatible avec un SP 1.3 ● Les fichiers de configuration pour une même brique entre versions 1.3 et 2.x ne sont pas compatibles

30 oct Quelques différences entre le SP 1.3 et le SP 2.0 ● Shibboleth SP 2.x supporte nativement le protocole SAML 2.0 à qui il doit la majeure partie des changements ● Cela assure une inter-opérabilité avec les autres produits implémentant SAML 2 ● Changements de nom des fichiers ➢ shibboleth.xml devient shibboleth2.xml ➢ AAP.xml est décomposé en attribute-map.xml et attribute-policy.xml

30 oct Quelques différences entre le SP 1.3 et le SP 2.x ● Dans shibboleth2.xml SessionInitiator change beaucoup (SAML 2 et rétro-compatibilité) ● Les variables d'environnement contenant les attributs Shibboleth ne sont plus préfixées par 'HTTP_' ● Apparition d'un nouveau service de découverte qui remplacera le WAYF à terme c'est le « Discovery Service (DS) » qui a un fonctionnement quelque peu différent du WAYF

30 oct Seconde partie : « Shibboliser » une application

30 oct Cerner le contexte d’utilisation de l’application –Tous les utilisateurs du service peuvent-ils utiliser Shibboleth ? –Comment contrôler l’accès des utilisateurs ? –Comment identifier les utilisateurs ? Shibboliser l’application 1.Déléguer l’authentification au SP Shibboleth 2.Changer le mode de contrôle d’accès 3.Modifier la gestion des utilisateurs 4.Sessions, logout, WAYF Shibboliser un service ou une application

30 oct Contrôler l’accès sur la base d’attributs fournis par les IdPs Application 1. Accès via Shibboleth IdP studentstaff studentfaculty 2. Accès seulement si eduPersonAffiliation = student

30 oct Gestion des utilisateurs Application IdP Jean Dupont jdupont (login)‏ Nom prénom / / privilèges Jean Dupont / / admin projet X Yves Durant / / membre projet Y SP Shibbole th ?

30 oct Comment identifier les utilisateurs ? Si l’on ne veut pas l’identité réelle des utilisateurs –avec l’attribut persistent NameId, identifiant persistant mais opaque Pour avoir l’identité réelle des utilisateurs –eduPersonPrincipalName (pérenne mais peu connu des utilisateurs et des gestionnaires d’application)‏ – (connu de l’utilisateur mais peut changer)‏

30 oct Les applications déjà compatibles

30 oct Fonctionnement du SP Shibboleth Environnement Apache ou IIS Scénario 1.redirection vers WAYF 2.redirection vers IdP 3.retour vers le SP 4.récupération attributs SP Apache / IIS Application IdP WA YF Attributs utilisateur

30 oct Configuration de mod_shib Configuration Apache –S’applique à un chemin d’accès –Agit en rupture de flux Mais l’authentification peut être plus souple –Mécanisme des lazy sessions AuthType shibboleth ShibRequire Session On require valid-user AuthType shibboleth ShibRequire Session Off require shibboleth

30 oct Le mécanisme des lazy sessions SP Apache / IIS Application WA YF SP Apache / IIS Application Navigation anonymeDéclenchement de la lazy session Login Shibboleth URL : /Shibboleth.sso/WAYF/CRU?target=url_app

30 oct Le mécanisme des lazy sessions Mécanisme propre au SP Shibboleth Permet de déclencher l’authentification Shibboleth à l’initiative de l’application protégée par le SP Utile dans les cas suivants –l’application propose certaines fonctionnalités sans besoin d’authentification –plusieurs mécanismes d’authentification sont supportés –la fonction WAYF est intégrée à l’application

30 oct Réaliser le contrôle d'accès dans Shibboleth ou dans l’application Au niveau de Shibboleth Dans l’application AuthType shibboleth ShibRequireSession On ShibRequireAll On require affiliation student require homeOrganization ~ ^univ-test.fr$ if ($ENV{‘HTTP_SHIB_EP_AFFILIATION’} == ‘student’ && $ENV{'HTTP_SHIB_SUPANN_SUPANNORGANISME'} == '{ILN} ') { &accesAutorise() }

30 oct Transmission des attributs utilisateurs SP IdP LDAP SAML Applicatio n resolver.xm l arp.site.xmlAAP.xml uid urn:mace:dir:attribute-def:eduPersonPrincipalName REMOTE_USER schéma inspiré d’une présentation de Switch

30 oct Les sessions et le logout Constat : l’utilisateur a plusieurs sessions actives –CAS > IdP Shib > SP Shib > Application Prévoir un logout du SP Shibboleth quand l’utilisateur se déconnecte de l’application Remarque : la version 1.3 de Shibboleth ne propage pas le logout jusqu’à l’IdP et les autres applications –À venir dans Shibboleth 2.0 –D’ici là, l’utilisateur doit fermer son navigateur

30 oct Quelques considérations, en vrac Ampleur de la tache variable Mettre en place une session applicative Intégrer un WAYF dans l'application Architecture proxy Désactiver l'usage des mots de passe Utiliser un mot de passe « statique » Nommage Supann des attributs Des messages d'erreur précis Un plugin Shibboleth paramétrable

30 oct Troisième partie : Mise en production

30 oct Configuration de la brique SP Utilisation des méta-données de la « vrai » fédération Si bessoin : utilisation des comptes CRU

30 oct La fédération du CRU Sauf besoin « immédiat » (2 mois) d'un service de production => Fédération Renater Guide de transition

30 oct La fédération Renater Périmétre élargi Modification de terminologie : –Membres : IdP, ressources –Partenaires : ressources Un cadre technique : –Shib 1.3 et 2.x –Utilisation Supann 2008 –Profile attribut Push –URL pour les IdP –OID pour les attributs

30 oct Workflow d'inscription dans la fédération RENATER Membre –Saga => charte –Formulaire Web –Install Shib pour IdP et/ou ressource(s) Partenaires –Charte –Formulaire Web –Install Shib pour ressource(s)

30 oct

30 oct Relation avec les fournisseurs d'identités Description des attributs attendus (requis lors de l'enregistrement) Le CRU notifie tous les fournisseurs d'identités dès l'enregistement d'une ressource Un problème « classique » : => transfert des attributs => chercher sur le site de la fédération, le contact technique de l'IdP concerné