Social2saml : déléguer l`authentification à des

Social2saml : déléguer l’authentification à des
opérateurs tiers
Olivier Salaün
GIP RENATER
Campus de Beaulieu
263, Avenue du Gal Leclerc CS 74205
35042 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 2015 - Montpellier
1/9
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
2.1.1
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 email et
choisit un mot de passe. L’opération d’activation du compte consiste à envoyer un mail de validation à ladite adresse
email 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 2015 - Montpellier
2/9
•
•
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.
2.1.2
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 email qui
sera ensuite validée via un processus de validation par email. 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 2015 - Montpellier
3/9
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 email 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 2015 - Montpellier
4/9
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 email
mail
[email protected]
Identifiant
utilisateur
uid
jcesar72
Identifiant
utilisateur global
eduPersonPrincipalName
[email protected]
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 2015 - Montpellier
5/9
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 4.
Figure 4 - sélection du fournisseur d'identités par l'utilisateur
5.2
Le processus d’authentification
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 2015 - Montpellier
6/9
service, à savoir des opérateurs de réseaux sociaux (Google, Facebook, LinkedIn, Yahoo, Microsoft Live@edu). 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 2015 - Montpellier
7/9
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 2016. 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 ÉducationRecherche [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 2015.
Bibliographie
[1] (2005, Mar.) Security Assertion Markup Language (SAML) v2.0. [Online]. https://www.oasis-open.org/standards
[2] RENATER. La Fédération Education-Recherche. [Online]. https://services.renater.fr/federation/index
[3] RENATER. Le service des Comptes CRU. [Online]. https://cru.renater.fr
[4] (2012, Oct.) The OAuth 2.0 Authorization Framework. [Online]. https://tools.ietf.org/html/rfc6749
[5] GEANT. Le service eduGAIN. [Online]. http://services.geant.net/edugain
[6] Henry Jacob et Saâd Aït Omar Pascal Aubry. (2013) Sésame 2, vers une gestion d’identités moderne. [Online].
https://2013.jres.org/archives/22/index.htm
[7] (2009) Recommandations pour les annuaires de l’enseignement supérieur, Supann 2009. [Online].
https://services.renater.fr/documentation/supann/2009/documentcomplet
[8] RENATER.
Génération
de
l’attribut
https://services.renater.fr/federation/docs/fiches/persistentid
eduPersonTargetedID.
[Online].
[9] Logiciel simpleSAMLphp. [Online]. https://simplesamlphp.org/
[10] Logiciel Shibboleth. [Online]. http://shibboleth.net/
[11] RENATER.
Cadre
technique
de
la
Fédération
https://services.renater.fr/federation/technique/cadre-technique
Education-Recherche.
[Online].
[12] JASIG. Logiciel CAS, Enterprise Single Sign-On. [Online]. http://jasig.github.io/cas/
[13] (2015,
May)
External
Identities
Working
Group
Report.
https://spaces.internet2.edu/display/EXTID/External+Identities+Working+Group+Report
[Online].
[14] France Connect. [Online]. https://doc.integ01.dev-franceconnect.fr/
JRES 2015 - Montpellier
8/9
JRES 2015 - Montpellier
9/9