SHIBBOLET

1. SHIBBOLET Vitthagna BARNIER Paul CLEMENT M2 MIAGE Nancy 2009/2010

2. Plan • Introduction • Origines • Objectifs • I Fonctionnement • 1 Définitions : les briques • 2 Déroulement • 3 Confiance • 4 Socle organisationnel

3. Plan (suite) • II Intégration • 1 Sans fédération d’identités • 2 Avec fédération d’identités • 3 Requêtes • 4 Délégation avec Shibboleth • III Avantages / Inconvénients • 1 Avantages • 2 Inconvénients • IV Conclusion

4. Introduction • Shibboleth • Mot hébreu : épi, branche, flot, torrent • Signification : phrase ou un mot ne pouvant être utilisé ou prononcé correctement que par les membres d'un groupe (Wikipédia) • Qu’est-ce que c’est ? • Logiciel open source pour l’identification sur le web • Mécanisme de propagation d’identité développé par Internet2 regroupant universités et centres de recherches.

5. Introduction (suite) • Internet2 : consortium à but non lucratif pour le développement des technologies permettant de faire atteindre de hauts débits au réseau Internet (Sun Microsystems, Intel, Cisco, etc.) • Très utilisé par la communauté enseignement / recherche

6. Introduction (suite) • Objectifs de Shibboleth : • Gain de temps • Déléguer l'authentification à l'établissement d'origine de l'utilisateur • Obtenir certains attributs de l'utilisateur (gestion du contrôle d'accès ou personnalisation des contenus)

7. I Fonctionnement • Basé sur Security Assertion Markup Language (SAML v2 depuis 2005) • Standard définissant un protocole pour échanger des informations liées à la sécurité (authentification, autorisation, attributs) entre un fournisseur d’identités et un fournisseur de services • Interconnexion des Single Sign-On (redirection, cookies, …) entre établissements • Single Sign-On : centralisation des authentifications • Approche coopérative avec Shibboleth • Chaque utilisateur dépend d'une des entités partenaires • L'utilisateur est authentifié par le partenaire dont il dépend lors de l’accès à un service du réseau. • Chaque service du réseau gère indépendamment sa propre politique de sécurité.

8. I Fonctionnement (suite) • La délégation d’authentification est basée sur le SSO web : une seule authentification pour accéder à plusieurs ressources informatiques. • Réduction de temps • Centralisation des informations • Simplification • Propagation des attributs utilisateur • Partage de méta données • Définition de règles de confiance

9. I.1 Définitions : les briques • Fournisseur de services (service provider SP) : module d’authentification pour le serveur Web • Délègue l'authentification des utilisateurs à un fournisseur d'identités • Transmet le profil utilisateur • Gère le contrôle d'accès de manière optionnelle • Un SP choisit à quels fournisseurs de services ses utilisateurs accèdent

10. I.1 Définitions : les briques (suite) • Fournisseur d’identités (Identity provider idP) : module de gestion d’authentification des utilisateurs en réponse à la requête d’un SP • L’authentification peut être déléguée à un serveur CAS (Central Authentification Service) • Authentification via login / mot de passe ou certificat électronique ou les deux • Les attributs de l'utilisateur sont extraits d'un annuaire LDAP, d'une base SQL ou bien calculés, puis propagés au fournisseur de services • Un SP choisit à quels fournisseurs d’identités il ouvre l’accès

11. I.1 Définitions : les briques (suite) • Service de découverte (WAYF) : permet à un utilisateur de sélectionner son organisme de rattachement, c'est-à-dire celui auprès duquel il pourra s'authentifier. • Fédération d’identités : délégation d’authentification et propagation des attributs • Niveau de confiance minimal partagé entre les fournisseurs

12. I.1 Définitions : les briques (suite)

13. I.2 Déroulement • Etapes • Accès à une ressource numérique • Redirection vers le service de découverte de la fédération • Sélection de l’établissement d’origine • Renvoi vers le fournisseur d’identités • Le fournisseur doit disposer d’une Central Authentification Service (CAS) : système d’authentification unique • Obtention des attributs selon l’utilisateur définis par le fournisseur d’identités

14. I.3 Confiance • Confiance accordée par un SP • Qualité d’authentification des utilisateurs • Qualité des attributs propagés • Disponibilité des services d’authentification et de propagation des attributs • Confiance accordée par un idP • Les attributs propagés ne servent qu’aux usages initialement prévus (accès authentifié mais anonyme avec Shibboleth)

15. I.3 Confiance (suite) • Formalisation des relations de confiance • établir un niveau de confiance minimal • Exemples d’engagements pour un idP • Disponibilité et sécurisation du service d’authentification • Mise à jour du référentiel • … • Les formes possibles • Respect des bonnes pratiques • Engagement contractuel • …

16. I.4 Socle organisationnel • Utilisation d’un socle organisationnel : fédération d’autorités d’authentification. • Ex : organismes publics, universités, etc. • Les autorités d’identification peuvent définir et normaliser les attributs d’authentification

17. II Intégration • Intérêt de la mise en place d’une fédération d’identités • Gérer des accès à des ressources en ligne • Accessibilité aux utilisateurs externes • Contexte • Mise en place de SSO dans les établissements • Nécessité de collaboration entre les établissements

18. II Intégration • Shibboleth fournit un module pour le serveur Web (Apache et IIS). • Ce module permet de protéger des ressources Web sur le serveur de façon assez sommaire. • Si ces ressources sont des scripts, les attributs de l’utilisateur leur seront passés via des variables d’environnement comme pour les scripts CGI. • Tous les fournisseurs de ressources doivent être dûment validés a priori auprès de l’IdP avant de pouvoir l’utiliser, ce qui est une contrainte assez lourde.

19. II.1 Sans fédération d’identités

20. II.2 Avec fédération d’identités

21. II.3 SSO + WAYF • Service Provider • Le consommateur d’assertions agit comme un pré-filtre • Le demandeur d’attributs est chargé de la récupération des attributs des utilisateurs auprès de l’IdP • Le contrôleur d’accès est chargé d’autoriser ou non l’accès aux ressources demandées • Identity Provider • Le service SSO est chargé de l’authentification des utilisateurs • L’autorité d’authentification associe le nameIdentifier à l’identifiant de l’utilisateur. • L’autorité d’attributs délivre, en réponse à une demande d’un SP

22. II.3 SSO + WAYF (suite) Celui-ci ne sachant pas quel IdP sera utilisé, le SP redirige le navigateur vers le WAYF 1ère requête vers un SP 1 Le WAYF affiche à l’utilisateur une liste d’IdP possibles.

23. II.3 SSO + WAYF (suite) La requête suivante vers le WAYF redirige le navigateur vers l’IdP choisi 1 qui a son tour redirige le navigateur vers le serveur SSO, qui propose alors un formulaire d’authentification

24. II.3 SSO + WAYF (suite) Le navigateur s’authentifie auprès du serveur SSO, et l’authentification se déroule comme suit : 1 Login + Password

25. II.3 SSO + WAYF (suite) Requêtes suivantes vers le même SP 1 Une session étant mise en place entre le navigateur et le SP (ou plutôt le consommateur d’assertions du SP), ni le WAYF, ni l’IdP ni le serveur SSO n’interviennent ensuite pour l’accès au même SP

26. II.3 SSO + WAYF (suite) • Requêtes suivantes vers un autre SP • Lors du choix de l’IdP par l’utilisateur : • Possibilité pour le WAYF de mémoriser ce choix dans le navigateur (à l’aide d’un cookie). • Le WAYF peut utiliser ultérieurement cette information • les requêtes suivantes deviennent non bloquantes (en redirigeant automatiquement vers l’IdP choisi la première fois).

27. II.3 SSO + WAYF (suite) Dans ce cas, l’authentification de l’utilisateur est totalement transparente lors de l’accès à un autre SP. 1

28. II.4 Délégation avec Shibboleth • L’utilisateur contacte un SP1. • SP1 fait appel à un SP2. L’utilisateur n’est pas directement en contact avec le SP2, SP1 joue le rôle d’intermédiaire entre l’idP et le SP Final. • Les assertions SAML délivrées par le fournisseur d’identités pourront être chiffrées à destination du SP2 afin d’en assurer la confidentialité (vis-à-vis du SP1).

29. II.4 Délégation avec Shibboleth (suite) nameId attributs pour SP2 cryptés attributs pour SP1 attributs pour SP2 cryptés

30. III Avantages / Inconvénients • Listing des principaux avantages et inconvénients

31. III.1 Avantages • Basé sur des standards (Single sign on, etc.). Interopérabilité avec d’autres logiciels utilisant les mêmes standards. • Apache License 2.0 : open source • Publication sélective des informations • Accès protégé aux ressources en ligne + simplication • Augmentation de la sécurité • Préservation des données personnelles

32. III.2 Inconvénients • Complexité technique • SAML, SSL, Tomcat, Apache, LDAP • Edition des fichiers de configuration manuelle • Complexité organisationnelle • Répartition des tâches • Migration des comptes • Dédoublonnage de compte • Usine à gaz, formations et supports auprès du CRU ou RENATER

33. IV Conclusion • Bonne solution en termes de gestion de ressources avec accès sécurisé à ces dernières • Gratuité et interopérabilité • Complexe : des formations existent • Intéressant à utiliser pour les institutions publiques ou université pour le partage des ressources communes