30 oct 2008 1 Installation d’un fournisseur de services Shibboleth Formation CRU 30 octobre 2008, Paris UPMC Formateurs : Vincent Carpier

Présentation au sujet: "30 oct 2008 1 Installation d’un fournisseur de services Shibboleth Formation CRU 30 octobre 2008, Paris UPMC Formateurs : Vincent Carpier"— Transcription de la présentation:

1 30 oct 2008 1 Installation d’un fournisseur de services Shibboleth Formation CRU 30 octobre 2008, Paris UPMC Formateurs : Vincent Carpier vincent.carpier@cru.fr Mehdi Hached mehdi.hached@cru.fr Olivier Salaün olivier.salaun@cru.fr

2 30 oct 2008 2 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

3 30 oct 2008 3 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

4 30 oct 2008 4 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

5 30 oct 2008 5 Rappels sur Shibboleth –Logiciel « open source » : http://shibboleth.internet2.edu http://shibboleth.internet2.edu –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)

6 30 oct 2008 6 Démonstration de Shibboleth

7 30 oct 2008 7 Référentiel utilisateurs Cinématique

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

9 30 oct 2008 9 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 »

10 30 oct 2008 10 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

11 30 oct 2008 11 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

12 30 oct 2008 12 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

13 30 oct 2008 13 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

14 30 oct 2008 14 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

15 30 oct 2008 15 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

16 30 oct 2008 16 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

17 30 oct 2008 17 Seconde partie : « Shibboliser » une application

18 30 oct 2008 18 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

19 30 oct 2008 19 1. 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

20 30 oct 2008 20 Gestion des utilisateurs Application IdP Jean Dupont dupont@univ1.fr jdupont (login)‏ Nom prénom / email / privilèges Jean Dupont / dupont@univ1.fr / admin projet X Yves Durant / durant@univ2.fr / membre projet Y SP Shibbole th ?

21 30 oct 2008 21 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)‏ –email (connu de l’utilisateur mais peut changer)‏

22 30 oct 2008 22 Les applications déjà compatibles https://spaces.internet2.edu/pages/viewpage.action?pageId=11484

23 30 oct 2008 23 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

24 30 oct 2008 24 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

25 30 oct 2008 25 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

26 30 oct 2008 26 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

27 30 oct 2008 27 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}1-341725201') { &accesAutorise() }

28 30 oct 2008 28 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

29 30 oct 2008 29 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 30 oct 2008 30 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

31 30 oct 2008 31 Troisième partie : Mise en production

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

33 30 oct 2008 33 La fédération du CRU Sauf besoin « immédiat » (2 mois) d'un service de production => Fédération Renater https://federation.cru.fr/ Guide de transition

34 30 oct 2008 34 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

35 30 oct 2008 35 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)

36 30 oct 2008 36

37 30 oct 2008 37 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é