Maraachli Malic

Abstract

Authentication in companies is a recurring problem. This problem is even more crucial in the medical world where, on the one hand, we have medical confidentiality and, on the other hand, we need fast access to the patient’s records. As social media progressively infiltrate human activity, they could be a solution to this dual problem.

We have developed a JAVA web application which, based on the authentication and the security inherent in these networks, allows users to authenticate themselves through media such as Facebook and Google or resorting to a key like the SuisseID. The Single Sign-On principle and the SAML standard are the drivers of the resulting authentication. Single Sign-On solves the problem of forgetting/losing multiple passwords, promoting fast and easy connection.

Our application provides strong authentication as well as a Single Sign-On property. Its design is open to various new identity providers. An interesting future perspective.

Introduction

L’authentification dans le monde professionnel, sujet sensible s’il en est, nourrit de multiples débats. Il se décompose en deux problèmes corollaires mais néanmoins distincts: la sécurité des données d’une part, leur accessibilité d’autre part. Dans le monde médical, où toute information revêt potentiellement une valeur vitale, ces questions se posent de façon aiguë. Dès lors, toute la difficulté consiste à trouver le juste équilibre entre la facilité d’accès aux données et leur protection. Offrir aux personnes autorisées un accès rapide et simple à leurs ressources tout en maintenant un niveau de protection efficace sur ces ressources semble s’apparenter à la quadrature du cercle. Cependant, il est possible et nécessaire de tenter de s’en approcher, comme nous allons l’exposer. Notre article est basé sur un travail de Bachelor que nous avons réalisé au sein de la Haute Ecole Spécialisée Bernoise de Bienne [1].

Analyse

Dans la perspective d’un accès rapide aux données, l’idéal serait de disposer d’un unique mot de passe: une sorte de clé «passe-partout».

Une réduction du nombre de sessions et de couples utilisateur/mot_de_passe pour un même utilisateur physique diminuerait mécaniquement le nombre de déchets (pertes d’identifiants, verrouillages de comptes) que tout utilisateur lambda génère avec la régularité d’un métronome.

Concernant la protection des données, nous voulons une authentification de qualité pour assurer la confidentialité. Nous voulons que toutes les communications se fassent avec SSL/TLS afin d’assurer l’intégrité des données. Et nous voulons que le système d’authentification soit disponible en permanence.

Aujourd’hui, les réseaux sociaux tels que Facebook, Twitter, Google, LinkedIn ont définitivement changé nos habitudes de communication et, parfois, nos habitudes de vie au quotidien, à tel point que certaines personnes connaissent mieux leur identifiant Facebook que celui de leur banque en ligne! En croissance constante, le nombre d’inscrits suisses à Facebook approche les 4millions (début février 2015), avec près de 500 000 nouveaux arrivants en une année [2]! Cette augmentation des utilisateurs des réseaux sociaux se fait même à toutes les tranches d’âges [3], ce que reflète le diagramme de la figure 1.

De par leur nature, les réseaux sociaux, s’ils souhaitent perdurer, ne peuvent pas se permettre de proposer une authentification peu fiable. Au contraire, conscients que l’aspect ludique de leur business model n’incite pas les utilisateurs à la plus grande prudence quant à la gestion de leur identité, ils se sont vus de fait forcés de mettre en œuvre des politiques sécuritaires poussées, répondant à toutes les notions évoquées plus haut.

La combinaison entre leurs politiques de sécurité, leur bonne pénétration du marché et leur mise à disposition proactive d’outils techniques dédiés, a fait de ces réseaux sociaux les candidats parfaits pour être utilisés comme fournisseurs d’identité.

Transposés au monde médical, ces principes permettraient la mise à disposition de modes d’authentification à la fois robustes et simples. Le médecin, tout comme l’ambulancier ou la secrétaire médicale, accéderait immédiatement au dossier patient!

Ainsi l’utilisation des réseaux sociaux comme fournisseurs tiers d’identité assurerait une authentification simple et rapide couplée à un niveau de sécurité élevé.

Une telle authentification n’est pas l’exclusivité des réseaux sociaux. Elle peut être fournie également par des systèmes dédiés à cet effet, tels que la SuisseID [4] ou les bases de données Shibboleth [5]. Notre travail de Bachelor traite également ces deux cas spéciaux.

Considérations techniques

Les fonctionnalités envisagées doivent s’intégrer à l’infrastructure déjà en place dans l’entreprise de façon transparente pour les utilisateurs.

fullscreen

Par exemple, les utilisateurs internes à l’entreprise ne doivent observer aucun changement quant aux modes d’authentification et d’enregistrement qu’ils utilisent déjà. Nous voulons leur proposer une authentification unique capable de leur donner l’accès global aux diverses ressources désormais agrégées, jusqu’alors gardées internes à chaque application.

Sur ce principe, nous optons pour les réseaux sociaux comme alternative aux fonctionnalités de base.

Les utilisateurs existants qui apprécient cette idée auront la possibilité de lier leur compte actif à un fournisseur d’identité externe et, par la suite, d’utiliser ce dernier pour se connecter.

Pour les nouveaux utilisateurs, nous offrons la possibilité de créer directement leur compte par l’intermédiaire d’un de ces fournisseurs d’identité externes facilitant le remplissage du formulaire d’inscription/enregistrement et la gestion des mots de passe.

Méthodes

Nous avons développé une application Web, en Java, qui recouvre les concepts que nous venons de mettre en évidence. Les articles d’Asela Pathberiya sur la «SOA Security» [6] ont servi de base pour notre travail.

fullscreen

En utilisant un serveur d’identité, à savoir l’Identity Server [7] de la plateforme middleware WSO2 [8], nous sauvegardons des profils d’utilisateurs, provenant de fournisseurs d’identité externes. Cette approche permet, en premier lieu, une bonne gestion des identités externes, puis une bonne gestion des associations entre comptes «internes» et comptes «externes» et, enfin, un contrôle permanent sur toutes les identités qui utilisent notre application.

Les communications entre notre application et l’Identity Server suivent le standard SAML2. L’Identity Server trie et distribue «les messages» vers les différents fournisseurs d’identité, au moyen de divers protocoles. Voici, par exemple, le schéma de communication pour les cas Facebook et Shibboleth.

Le standard SAML2 permet alors un login Single Sign-On (SSO), un atout significatif pour un accès rapide aux données.

Le Single Sign-On est un procédé d’authentification qui permet à l’utilisateur d’entrer un identifiant unique afin de s’authentifier ou de débloquer de multiples applications. Il peut s’appliquer à des sites Web. Le système accédé gérera alors les permissions, les accès et les services mis à disposition. Parmi les avantages du Single Sign-On, citons un gain de temps lors du login, puis une gestion des utilisateurs facilitée pour l’administrateur.Il y a gain de temps en évitant la multiplication de mots de passe et leurs pertes fréquentes. Ainsi, un médecin pourra se connecter une seule fois sur son ordinateur et avoir ensuite l’accès à toutes les applications ou données qui lui sont autorisées.

Le standard SAML2 offre l’authentification. La gestion des autorisations, elle, passe par des «token», provenant du standard de communication OAuth2. Ces token sont ensuite exploités pour identifier l’utilisateur et déterminer les ressources auxquelles il peut accéder. L’attribution de ces droits incombe à un administrateur. Cette intervention de l’humain constitue un contrôle supplémentaire pour identifier l’utilisateur.

Dans tous ces échanges, la sécurité est assurée par le protocole SSL.

Le schéma ci-après explique le fonctionnement du standard SAML2.

Résultats

Notre application permet aujourd’hui d’authentifier des utilisateurs provenant d’une base de données ou d’un LDAP tel qu’Active Directory.

fullscreen

fullscreen

Ces utilisateurs peuvent choisir de se connecter à notre application à l’aide de leur compte existant.

Ils peuvent également choisir de lier ce compte à un de leurs comptes hébergés chez des fournisseurs d’identité externes. S’ils font cette association, ils peuvent alors passer par le compte externe pour accéder aux données.

Une personne, non enregistrée dans l’entreprise, peut utiliser notre application et créer un compte, en s’appuyant sur un fournisseur d’identité externe. Au bout du processus, elle obtient un compte qui lui permet d’accéder aux données, en utilisant les attributs puisés chez le fournisseur d’identité choisi. L’attribution des droits d’accès aux ressources est réalisée «à la main» par un administrateur.

Nous utilisons un standard de communication unique, SAML2, entre notre application et l’Identity Server de WSO2 quel que soit le fournisseur d’identité externe. Une telle structure simplifie l’ajout de nouveaux fournisseurs d’identité.

Avec le Single Sign-On mis en place, l’utilisateur s’authentifie une seule fois et il peut ensuite accéder aux données dont il a besoin, en fonction des rôles qu’il a dans l’entreprise.

Actuellement, notre application dessert les fournisseurs d’identité suivants: Facebook, Google et LinkedIn en ce qui concerne les réseaux sociaux, puis la SuisseID et une base de données Shibboleth en ce qui concerne des institutions plus traditionnelles du monde de l’authentification. Nous envisageons d’ajouter à la liste les fournisseurs suivants: Twitter, Xing, Windows Live.

Avec la structure proposée, l’Identity Server est le multiplexeur de l’authentification. Toutes les identités y sont centralisées: qu’elles viennent de Facebook, de Google, d’un LDAP, ou d’une base de données classique. Cette approche nous permet une meilleure gestion des identités ainsi qu’une gestion centralisée de la sécurité.

Le schéma suivant est une représentation simplifiée de l’architecture de notre système.

Discussion

D’aucuns pourraient se demander si une authentification à l’aide d’un compte Facebook est tout aussi robuste que celle obtenue avec la SuisseID. La réponse est immédiate. Sur le plan de l’authentification, avec l’architecture que nous proposons, les deux paradigmes sont de même valeur. Dans les deux cas, nous utilisons les mêmes protocoles et les mêmes standards. La différence se situe au niveau de la sécurité interne de chaque fournisseur d’identité. La sécurité des réseaux sociaux s’est énormément renforcée ces dernières années, si bien qu’il est devenu difficile d’usurper une telle identité. Aujourd’hui, la principale vulnérabilité des identités électroniques est l’ingénierie sociale. C’est ici le point sensible: une application, aussi sécurisée soit-elle, repose toujours sur le bon comportement de l’utilisateur. Notre application ne peut pas empêcher un utilisateur de noter ses mots de passe sur un post-it. Elle ne peut pas l’empêcher de divulguer ses mots de passe. Mais elle peut diminuer les risques de ce genre de pratiques, en offrant une flexibilité dans l’authentification.

fullscreen

Par ailleurs, la centralisation des données améliore l’administration des identités et focalise les mesures de sécurité en un seul point. Cela peut cependant être une arme à double tranchant: si l’entité centrale est compromise, toutes les identités utilisant l’application le seront également.

L’architecture complexe de notre application répond aux besoins d’une moyenne ou grande entreprise. Pour une petite entreprise, une structure plus simple serait à envisager.

Nous concluons avec une observation sur le choix technologique. On peut utiliser «OAuth2/Open-ID connect» pour arriver à ce type d’authentification. Nous avons préféré SAML2 à OAuth2,car SAML2 a été conçu pour l’authentification et possède une architecture simple.

Correspondence

Correspondance:

Malic Maraachli

GSMN

Zuchwilerstrasse 27

CH-4500 Solothurn

malic.maraachli[at]gsmn.ch

Références

1 Maraachli M. Secured access to a corporate eHealth community through social media identities. Haute Ecole Spécialisée Bernoise, Bienne (Suisse), Février 2015.

2 Tandem Advertising. [Online]. http://www.tandemadvertising.com/les-reseaux-sociaux-en-2015-incontournables-aussi-en-b2b/

3 Dean et Stevens Berson. [Online]. https://bersondeanstevens.wordpress.com/2013/08/21/social-media-usage-by-age/

4 Confédération suisse. SuisseID. [Online]. https://www.e-service.admin.ch/wiki/display/suisseid/Home

5 Shibboleth. Shibboleth Consortium. [Online]. https://shibboleth.net/

6 Asela Pathberiya. WSO2 SOA Security. [Online]. http://soasecurity.org/

7 WSO2. Identity Server WSO2. [Online]. http://wso2.com/products/identity-server/

8 WSO2. Page d’accueil. [Online]. http://wso2.com/

Copyright

Published under the copyright license
“Attribution – Non-Commercial – NoDerivatives 4.0”.
No commercial reuse without permission.
See: emh.ch/en/emh/rights-and-licences/