Actu
Paul Baas, Tools4ever : Facebook peut-il devenir l’avenir du Single Sign On ?
mai 2014 par Paul BAAS, directeur France de Tools4ever
Il n’y a pas si longtemps encore, les applications étaient systématiquement gérées en interne. Le département informatique avait la mainmise sur le réseau de l’entreprise et le préservait du monde extérieur au moyen de firewalls et d’antivirus. Dans ce contexte, mettre en place une solution de SSO sur le réseau était relativement aisé. Après tout, le poste de travail de chaque collaborateur constituait un élément du réseau, tout comme les applications auxquelles ils devaient avoir accès. Les utilisateurs pouvaient, de facto, s’authentifier en soumettant leurs noms d’utilisateurs et leurs mots de passe à l’Active Directory et, grâce au protocole LDAP, bénéficier des avantages du Single Sign On. Cela revenait à ce que, pour chaque application lancée par la suite, les utilisateurs n’avaient pas besoin de saisir une combinaison nom d’utilisateur/mot de passe.
Le SSO et le Cloud, une nouvelle donne pour le SSO
Avec l’avènement des applications Cloud, la mise en place d’une solution de SSO (Single Sign On) au sein du réseau d’une entreprise, est devenue bien plus complexe. De nombreuses applications sont désormais hébergées au sein d’un domaine technique différent, à savoir le Cloud. Cela revient à dire que la relation entre l’utilisateur et l’application, c’est-à-dire entre le réseau et l’Active Directory, n’existe plus. Avec l’émergence des applications Cloud et du BYOD (Bring Your Own Device – Venez avec vos propres terminaux), les entreprises se retrouvent confrontées à une nouvelle tendance qui complexifie encore davantage la mise en place du Single Sign On. En effet, les utilisateurs finaux ont la possibilité de pouvoir utiliser à leur convenance leur matériel personnel à des fins professionnelles et notamment pour se connecter au réseau de l’entreprise. Il peut s’agir d’un PC, d’un smartphone ou encore d’une tablette numérique. Sachant que s’ajoute à cela le fait que les utilisateurs veulent pouvoir accéder aux applications de l’entreprise où qu’ils se trouvent. Cela a pour effet de rendre la mise en œuvre du Single Sign On bien moins simple pour le service informatique de l’entreprise.
OpenID et SAML, vous avez dit compatibles ?
Le SSO signifie à la base que les utilisateurs s’authentifient par rapport à une source fiable. S’ils s’authentifient avec succès, ils recevront un jeton (token) leur permettant de s’authentifier automatiquement par la suite pour d’autres ressources. Lorsque des applications sont hébergées via le Cloud, il n’existe plus de source fiable à laquelle les utilisateurs peuvent s’authentifier pour pouvoir accéder aux applications de l’entreprise – telles que, typiquement, l’Active Directory.
Les entreprises tentent de pallier ce problème en ayant recours à des mécanismes d’authentification décentralisés, à savoir les protocoles OpenID et SAML. Seulement, le vrai challenge est qu’en tant qu’entreprise, vous êtes dépendant des fournisseurs d’applications de Cloud. Imaginons par exemple que votre organisation ait sélectionné OpenID comme dispositif d’authentification pour activer le Single Sign On. Si les applications Cloud requises ne supportent que le protocole SAML, vous risquez fort de rencontrer de sérieux problèmes pour gérer l’authentification de vos utilisateurs. Malheureusement, les fournisseurs d’applications de Cloud n’accordent que très peu d’importance au processus de connexion (login), lui préférant largement le fait de pouvoir développer de nouvelles fonctionnalités pour leurs applications.
Le SSO, un outil dédié aux entreprises, en pleine mutation
Ce que nous recommanderions aux entreprises, c’est de sélectionner un modèle qui ne les rende pas dépendantes d’interfaces et de fournisseurs. Il existe différents fournisseurs de solutions dites « Enterprise Single Sign On », pour lesquelles le client SSO est hébergé sur du matériel non fiable et appartenant à un salarié donc favorable au BYOD. Lorsqu’un collaborateur lance une application hébergée sur site ou en mode Cloud, le logiciel reconnaîtra l’écran de connexion de l’application et entrera automatiquement les bons identifiants. Ces informations de connexion sont stockées de façon codée dans une base de données SSO sur le réseau.
Rendre le SSO 100% opérationnel
Ce modèle est basé sur la reconnaissance des écrans de connexion plutôt que sur le mécanisme d’authentification supporté par le fournisseur, ce qui en fait dès lors une solution dotée d’un potentiel incroyable. Le principal avantage est que cela fonctionne quel que soit le type d’application (web, java, client/server, telnet, mainframe, Unix, Windows, etc.), le type d’hébergement (LAN, datacenter, cloud, etc.), le type de matériel (Windows, Androïd, une tablette, un smartphone, un iOS, etc.), et le lieu d’utilisation (le lieu de travail, le domicile, sur la route, à l’étranger, sans que votre portable soit branché, etc.). En d’autres mots, il est possible d’offrir aux utilisateurs finaux une solution de SSO 100% opérationnelle, et ce, dans n’importe lequel des cas de figure.
Facebook, un Identity Provider qui pourrait nous vouloir du bien/qui nous veut du bien
Sur le marché grand public, les comptes liés aux réseaux sociaux tels que Facebook et Google sont souvent utilisés comme des Identity Providers (IdP). Une fois connectés à Facebook, les utilisateurs peuvent également se connecter automatiquement à d’autres applications, sans avoir à saisir à nouveau leurs identifiants. Par exemple, si un utilisateur se connecte à Facebook, il peut accéder automatiquement à Spotify si ces comptes ont été reliés. Autre cas de figure, les photos circulant sur Facebook peuvent être stockées automatiquement dans Picasa.
Les internautes ont tendance à se sentir plus concernés lorsqu’il s’agit de leur compte Facebook, que par le compte Active Directory de leur employeur. Ajouter à cela le fait qu’ils sont moins enclins à noter leurs identifiants de leurs réseaux sociaux sur un post-it. A l’inverse, c’est souvent le cas lorsqu’il est question des applications professionnelles.
Bring Your Own Identity (Venez avec votre propre identité)
Dès lors que les employés sont très attachés à leurs comptes de réseaux sociaux, on pourrait se demander s’il ne serait pas envisageable d’utiliser ces comptes comme IdP pour l’accès au SSO pour accéder aux données de l’entreprise via le SSO. En se connectant à leurs comptes Facebook, les collaborateurs pourraient accéder automatiquement (via le SSO), aux données de l’entreprise stockées à la fois sur site et sur le cloud. Il s’agit du phénomène du BYOI (Bring Your Own Identity ou Venez avec votre propre identité). Notamment à une époque où les fournisseurs de réseaux sociaux concentrent leurs investissements dans les moyens d’authentification (notamment dans les services localisés), je suis convaincu qu’à l’avenir, les réseaux sociaux pourront légitimement servir de fournisseurs IP pour les applications dédiées aux entreprises et à leurs données. Mais avant d’en arriver là, les responsables informatiques devront d’abord se remettre en question et faire davantage confiance aux fournisseurs d’identité des réseaux sociaux.
