Social2saml : déléguer l authentification à des opérateurs tiers

Transcription

1 Social2saml : déléguer l authentification à des opérateurs tiers Olivier Salaün GIP RENATER Campus de Beaulieu 263, Avenue du Gal Leclerc CS RENNES Cedex Résumé La fédération d identités et le protocole SAML [1] permettent d ouvrir l accès à des services en ligne dans la communauté Éducation-Recherche, en évitant à chaque opérateur de services en ligne de gérer les identités de tous ses utilisateurs potentiels. Cependant certains services destinés à un public plus large ne peuvent reposer sur l infrastructure SAML de la Fédération Éducation-Recherche [2] ; notamment les futurs étudiants, les anciens étudiants, les parents d élèves ou plus généralement les utilisateurs de type «invité». Or la plupart de ces utilisateurs disposent déjà, à travers leur participation à des réseaux sociaux, d un mécanisme permettant de les authentifier. En effet, la plupart des opérateurs de réseaux sociaux publient leur API d authentification afin de permettre à des services tiers d authentifier leurs utilisateurs. Ces modes d authentification alternatifs permettent de compléter l infrastructure SAML utilisée par les établissements, au même titre que les Comptes Réseaux Universels (comptes CRU) [3] déjà proposés par RENATER. RENATER, opérateur de l infrastructure SAML nationale, développe un service pilote afin d unifier l accès aux mécanismes d authentification de quelques réseaux sociaux : Facebook, Google, LinkedIn, Yahoo, Microsoft Live@edu. Le service proposé permettrait aux établissements d étendre leurs comptes invités et de déléguer l authentification, pour certains de leurs services, à ces opérateurs d authentification sans devoir implémenter de nouveaux protocoles d authentification. L architecture social2saml est composée de plusieurs passerelles (une par réseau social) agissant en tant que fournisseur d identités (IdP) dans l environnement SAML et en tant client OAuth2 [4] vis à vis du réseau social choisi. Mots-clefs Fédération d identités, SAML, fournisseur d identités, comptes invités, réseaux sociaux, OAuth, OpenID Connect, API 1 Introduction Depuis 2005, la communauté éducation-recherche française dispose d une infrastructure de fédération d identités permettant d utiliser le service d authentification web de chaque établissement, au-delà des usages internes. Ce cercle de confiance favorise la mise en œuvre de services numériques mutualisés à l échelle nationale. Récemment, l interfédération edugain [5] a permis d étendre encore le périmètre des utilisateurs disposant d un service d authentification (i.e. un fournisseur d identités, selon la terminologie SAML) compatible avec le protocole SAML [1]. L accès à un service en ligne (i.e. un fournisseur de service, selon la terminologie SAML) pose toujours un problème : les utilisateurs du service ne disposent pas tous d un fournisseur d identités. Parfois il s agit d un organisme n ayant pas encore mis en œuvre un fournisseur d identités SAML. Dans d autres cas l utilisateur ne disposera jamais d un compte reconnu ; il s agit par exemple de partenaires, de prestataires, des anciens étudiants, des parents d élèves. JRES Montpellier 1/9

2 C est pour répondre à ce besoin que RENATER a très tôt mis en place un fournisseur d identités pour gérer des comptes invités : les Comptes Réseaux Universels [3]. D autres solutions sont envisageables pour gérer l authentification et les contrôles d accès pour ces populations spécifiques, dont la passerelle avec des fournisseurs d identités tiers que RENATER a maquetté. Dans la première partie, le fonctionnement d un service de gestion de comptes invités sera présenté, en particulier le service des Comptes CRU proposé par RENATER. Dans la seconde partie nous présenterons comment des opérateurs tiers exposent leur service d authentification. La troisième partie présentera l architecture de la passerelle social2saml développée par RENATER. Enfin, la quatrième partie présentera les modalités d utilisation du service social2saml. 2 L authentification via des comptes invités Il est intéressant de comparer le fonctionnement de la passerelle Social2Saml avec la gestion de comptes invités puisque les deux services ont la même population cible : les utilisateurs ne disposant pas d un fournisseur d identités SAML institutionnel. Le gestionnaire de comptes invités proposé par RENATER et appelé Comptes CRU [3] servira d exemple. 2.1 Les Comptes Réseaux Universels Provisionnement et profil utilisateur Le service des Comptes Réseaux Universels permet la création de comptes en mode auto-enregistrement, sans restriction sur la population utilisateurs. Pour initier la création du compte, le demandeur fournit son adresse et choisit un mot de passe. L opération d activation du compte consiste à envoyer un mail de validation à ladite adresse renseignée et vérifier que le demandeur valide la demande en cliquant sur le lien. Figure 1 - formulaire de création d'un Compte CRU Le profil utilisateur d un Compte CRU comprend des attributs ayant un mode de provisionnement et des processus de validation différents : commonname, displayname, givenname, preferredlanguage et surname : informations saisies par l utilisateur, sans processus de validation. Ces informations ne peuvent être utilisées que pour personnaliser les contenus d un service en ligne ; JRES Montpellier 2/9

3 mail : information saisie par l utilisateur puis validée par une confirmation. Cette information peut-être utilisée pour contacter l utilisateur ou comme identifiant utilisateur ; edupersonprincipalname et edupersonpersistentid : informations générées à la création du compte CRU, non ré-assignable à un autre compte. Ces informations peuvent être utilisées comme identifiant utilisateur. Un fournisseur d identités SAML est associé au référentiel des Comptes Réseaux Universels, permettant à l utilisateur d utiliser son compte CRU pour accéder à des services en ligne implémentant le protocole SAML (i.e. des fournisseurs de services). A l inverse des comptes associés au fournisseur d identités et gérés par des établissements E/R qui peuvent porter des privilèges (attributs edupersonaffiliation indiquant la catégorie d utilisateur ou edupersonentitlement indiquant un droit d accès plus spécifique), un compte CRU ne véhicule aucun attribut susceptible de porter un privilège. Chaque service en ligne utilisant des comptes CRU attribuera des droits associés à l identifiant utilisateur Relation avec le cercle de confiance de la fédération Les fournisseurs d identités, membres de la Fédération Education-Recherche [2], ont un périmètre de population défini, puisque les comptes utilisateurs associés correspondent à la population de l établissement E/R concerné. Les fournisseurs de services consommant ces identités gèrent les droits d accès à leur service en fonction de la provenance des utilisateurs. Le périmètre du fournisseur d identités des Comptes CRU étant plus large, RENATER ne l intègre pas dans le cercle de confiance de la fédération. Dès lors, chaque fournisseur de services doit explicitement ajouter les Comptes CRU parmi ses fournisseurs d identités de confiance. 2.2 Gestion des comptes invités interne aux établissements E/R La plupart des établissements E/R mettent en œuvre leur propre service de gestion de comptes invités, afin d ouvrir ponctuellement un sous-ensemble de leurs services (Wi-Fi, accès aux postes de travail, impression, etc.) à des personnes externes. La gestion de ces comptes invités peut être complexe pour les établissements concernés. Dans l article «Sésame 2 : vers une gestion d identités moderne» [6] présenté aux JRES en 2013, les auteurs évoquaient : «Des comptes pourront être créés par les utilisateurs eux-mêmes, en lien avec une identité externe au Système d Information de l établissement, fournie par un prestataire externe (un numéro de téléphone, une adresse électronique, un identifiant Facebook, Twitter, LinkedIn, OpenID ). Cette ouverture vers des systèmes d'authentification externes devra permettre entre autre d'ouvrir nos outils à des coopérations avec des personnes externes. Elle n'est possible qu'en séparant fortement authentification et autorisation.». 3 L authentification via un opérateur type de réseau tiers De nombreuses personnes disposent d un compte auprès d opérateurs de réseaux tiers tels que Facebook, Google, LinkedIn, Yahoo. Ces opérateurs proposent des APIs permettant à des services tiers d utiliser leur mécanisme d authentification ; il est donc envisageable pour des établissements E/R d authentifier certains utilisateurs via un compte externe. Ce mode d authentification représente une alternative à la gestion des comptes invités. 3.1 Gestion des comptes et API d authentification Le processus de création d un compte auprès d un opérateur tiers est généralement comparable à celui utilisé pour un compte invité, à savoir la collecte de certaines données (nom, prénom) de manière déclarative et de l adresse qui sera ensuite validée via un processus de validation par . Nous pouvons considérer que le niveau de confiance dans un compte géré par un opérateur tiers est équivalent à un compte invité type Compte CRU. Les opérateurs tiers proposent des APIs permettant à des services externes de leur déléguer l authentification des utilisateurs. La majorité de ces opérateurs implémentent le protocole OAuth2 [4] pour le transfert du profil utilisateur. Selon la terminologie OAuth2 l opérateur tiers agit en tant que Resource Server et Authorization Server et le service client agit en tant que Client. JRES Montpellier 3/9

4 Le processus de transfert du profil utilisateur au Client fait l objet d un recueil de consentement utilisateur de la part de du Authorization Server, après la phase d authentification, voir la figure 2. Figure 2 - étape de consentement utilisateur de Google 3.2 Profil utilisateur issu d un opérateur tiers La richesse du profil utilisateur que les opérateurs tiers peuvent transmettre via le protocole OAuth2 est variable. Les nom et prénom de l utilisateur, son adresse et son identifiant utilisateur sont transmis systématiquement, tout comme pour les comptes invités. La valeur de l identifiant utilisateur peut être globale pour tous les services clients (équivalent de l attribut uid de SupAnn [7]), mais certains opérateurs (comme LinkedIn) fournissent une valeur d identifiant différente à chaque service client (équivalent de l attribut edupersontargetedid [8]). 4 Le service social2saml expérimenté par RENATER 4.1 Architecture du service RENATER a mis en place un prototype de service social2saml visant à interconnecter des fournisseurs d identités issus de la sphère des réseaux sociaux avec des fournisseurs de services implémentant le protocole SAML [1]. Le service doit permettre à un service en ligne de la communauté éducation-recherche de proposer à ses utilisateurs une authentification auprès de certains opérateurs tiers, sans devoir implémenter de nouveaux protocoles d authentification (notamment OAuth2 [4]). Le service social2saml est architecturé autour d une passerelle capable de dialoguer en SAML avec des fournisseurs de services et en OAuth2 avec des opérateurs de réseaux sociaux. Comme l illustre la figure 3, un fournisseur de service SAML voit la passerelle «Google» comme un IdP SAML classique. Le fournisseur d identités «Google» voit la passerelle RENATER comme une application cliente OAuth2 et n a pas d échange direct avec les fournisseurs de services de la communauté E/R. Pour l utilisateur du service, la passerelle est invisible. JRES Montpellier 4/9

5 Figure 3 - architecture de la passerelle Social2Saml La passerelle social2saml utilise le logiciel simplesamlphp [9], une alternative au logiciel Shibboleth [10]. Contrairement à Shibboleth, SimpleSAMLphp propose nativement un large choix de modules d authentification, comme Facebook Connect, Linkedin, Sign-in with Twitter, Windows Live. RENATER a par ailleurs développé un module d authentification pour Google. 4.2 Mapping SAML des attributs utilisateurs La passerelle assure le rôle de traduction en SAML [1] des attributs utilisateurs transmis par les Resource Servers OAuth2 [4] ; cette fonction est gérée par le logiciel simplesamlphp. Les attributs utilisateurs SAML utilisés pour véhiculer le profil utilisateur sont définis dans les recommandations SupAnn [7], comme précisé dans le cadre technique de la Fédération Éducation-Recherche [11]. Nous indiquons dans le tableau ci-dessous la liste des attributs utilisateurs gérés par la passerelle social2saml. Donnée utilisateur Attribut supann Exemple de valeur Prénom givenname Jules Nom sn César Nom complet displayname Jules César Adresse mail jules.cesar@gmail.com Identifiant utilisateur Identifiant utilisateur global uid edupersonprincipalname jcesar72 jcesar72@google.com 5 Utilisation du service social2saml 5.1 Modalités de mise en œuvre La passerelle Social2Saml est composée de plusieurs fournisseurs d identités SAML, un par opérateur de réseau social supporté. RENATER n inclura pas ces fournisseurs d identités dans la Fédération Éducation-Recherche [2] puisque la JRES Montpellier 5/9

6 population utilisateurs couverte est très différente du fournisseur d identités d un établissement E/R composé uniquement d étudiants, de chercheurs, d enseignants et de personnels administratifs et techniques. Ainsi le gestionnaire d un service en ligne désirant proposer l authentification via une des instances social2saml (Facebook par exemple) devra ajouter à la configuration de son fournisseur de service SAML le chargement des métadonnées SAML de ce fournisseur d identités ; RENATER publiera les méta-données SAML de chacun des fournisseurs d identités concernés. Dès lors les utilisateurs du service pourront sélectionner leur réseau social préféré pour s authentifier sur le service, comme le montre la figure Le processus d authentification Figure 4 - sélection du fournisseur d'identités par l'utilisateur Le processus d authentification d un utilisateur auprès d un fournisseur d identités social2saml est identique au processus d authentification auprès d un fournisseur d identités standard (IdP Shibboleth [10] d un établissement, par exemple). Comme l illustre la figure 5, l articulation entre la passerelle et le Resource Server de l opérateur de réseau social concerné est déléguée à un module d authentification implémentant le protocole OAuth2 [4]. Cette mise en œuvre de deux protocoles (SAML et OAuth2) est transparente pour l utilisateur ; ceci est comparable au fonctionnement d un fournisseur d identités Shibboleth qui délègue l authentification à un serveur CAS [12]. Figure 5 - le processus d'authentification complet 5.3 Ergonomie utilisateur Lorsqu un service en ligne utilisant une authentification SAML active l utilisation de la passerelle social2saml, les utilisateurs de ce service disposent de nouvelles sources d authentification dans le menu du service de découverte du JRES Montpellier 6/9

7 service, à savoir des opérateurs de réseaux sociaux (Google, Facebook, LinkedIn, Yahoo, Microsoft Par défaut la présentation de ces nouvelles options est similaire aux autres fournisseurs d identités d établissement : les intitulés des réseaux sociaux sont ajoutés au menu déroulant des 250 établissements E/R français. Cette présentation n est pas adaptée car il sera alors difficile pour l utilisateur concerné d identifier facilement cette possibilité d authentification via un réseau social. Une solution envisagée par RENATER consiste à adapter la mise en forme de la page du service de découverte pour mettre en évidence ces réseaux sociaux, sous forme de logos, voir la figure 6. Figure 6 - alternative pour présentation du service de découverte À l étape suivante, l utilisateur est redirigé (redirection HTTP) vers le service d authentification du réseau social qu il a sélectionné. L ergonomie varie ensuite selon le réseau social sélectionné : Google propose d abord à l utilisateur une bannière d authentification puis une demande de consentement lors du premier accès à la passerelle social2saml (voir la figure 2) ; LinkedIn propose une page d'authentification intégrant une indication sur les informations qui seront transmises au service client (voir la figure 7). Figure 7 - bannière d'authentification LinkedIn 6 Conclusion Le service social2saml étudié par RENATER permet d offrir une solution aux services en ligne fédérés (i.e. proposant une authentification SAML [1]) pour donner accès à des utilisateurs ne disposant pas d un compte auprès d un des fournisseurs d identités SAML de la Fédération Éducation-Recherche [2]. Actuellement ces utilisateurs doivent se créer un compte invité (par exemple un Compte Réseau Universel) pour accéder à ces services, étape qui complexifie l accès au service. La passerelle social2saml évite par ailleurs aux administrateurs de ces services d implémenter d autres modes d authentification (OpenID Connect basé sur OAuth2 [4]) puisque la passerelle est pourvue d une interface SAML. JRES Montpellier 7/9

8 La maquette initiale du service conçue par RENATER a expérimenté avec succès l authentification auprès de cinq opérateurs de réseaux sociaux : Facebook, Google, LinkedIn, Yahoo et Windows Live@edu. Une version pilote du service social2saml est prévue pour le premier semestre Ce service pilote prévoit l interconnexion avec un sousensemble de ces réseaux sociaux. La liste des réseaux sociaux adaptés aux contraintes des services utilisateurs sera notamment déterminée par une étude de sécurité du GIP RENATER. Le rapport du groupe de travail américain External Identities Working Group [13] fournit déjà des critères d évaluation pertinents. RENATER ne prévoit pas d intégrer la passerelle social2saml dans le cercle de confiance de la Fédération Éducation- Recherche [2], afin de préserver le périmètre actuel de l infrastructure de la fédération. Comme c est déjà le cas pour les Comptes CRU, l authentification via les réseaux sociaux devra être explicitement activée par le responsable d un service en ligne qui souhaite utiliser ce mode d authentification. En parallèle de ce projet, RENATER met en place une passerelle d interconnexion entre les fournisseurs d identités SAML de la communauté Education-Recherche et les services de l administration en ligne via France Connect [14]. Ce projet sera également présenté à la conférence JRES Bibliographie [1] (2005, Mar.) Security Assertion Markup Language (SAML) v2.0. [Online]. [2] RENATER. La Fédération Education-Recherche. [Online]. [3] RENATER. Le service des Comptes CRU. [Online]. [4] (2012, Oct.) The OAuth 2.0 Authorization Framework. [Online]. [5] GEANT. Le service edugain. [Online]. [6] Henry Jacob et Saâd Aït Omar Pascal Aubry. (2013) Sésame 2, vers une gestion d identités moderne. [Online]. [7] (2009) Recommandations pour les annuaires de l enseignement supérieur, Supann [Online]. [8] RENATER. Génération de l attribut edupersontargetedid. [Online]. [9] Logiciel simplesamlphp. [Online]. [10] Logiciel Shibboleth. [Online]. [11] RENATER. Cadre technique de la Fédération Education-Recherche. [Online]. [12] JASIG. Logiciel CAS, Enterprise Single Sign-On. [Online]. [13] (2015, May) External Identities Working Group Report. [Online]. [14] France Connect. [Online]. JRES Montpellier 8/9

9 JRES Montpellier 9/9