Qualys

Security CommunityLa communauté des experts sécuritéen savoir plus

SecurityVibesQualys Community

Left content

Une seconde chance pour la fédération des identités

auteur de l'article Jerome Saiz , dans la rubrique Produits & Technologies

Il fut un temps où la fédération des identités faisait rêver : l’on parlait alors de « cercles de confiance » entre les entreprises et l’on dessinait sur les nappes en papier des schémas complexes qui comprenaient invariablement des partenaires et des sous-traitants.

L’objectif avoué était de permettre à une entreprise de conserver la maîtrise de son référentiel d’utilisateurs tout en permettant à ces derniers de s’authentifier chez un partenaire éventuel. C’était le temps de Liberty Alliance ou de WS-Federation, par exemple.

Evidemment tout cela était beau sur le papier, mais aussi parfois complexe à mettre en oeuvre et à vrai dire pas très utile pour le commun des mortels. Et sans surprise ce marché n’a donc guère décollé. Aujourd’hui, des projets de fédération, par exemple basés sur Liberty Alliance, continuent certes à être mis en oeuvre (notamment dans l’éducation), mais pour l’essentiel la fédération des identités est un marché qui a consacré plus de temps et d’énergie à essayer de montrer son utilité qu’à se vendre.

Mais tandis que les entreprises en étaient à guetter un besoin qui n’est jamais venu, le grand public, lui, y était confronté de manière très concrète sur le web. Progressivement des acteurs tels Google, Facebook, Amazon ou encore Apple (la fameuse « bande à GAFA ») capturaient dans un premier temps les identités des utilisateurs pour leurs propres besoins, puis offraient dans un second temps aux développeurs web des solutions d’authentification fédérée grand public simples à utiliser, faciles à déployer et parfaitement fonctionnelles. Finalement, le besoin – pragmatique – a fait émerger ses propres standards ouverts (OpenID pour l’authentification et oAuth pour l’autorisation, par exemple) là où le marché de l’entreprises a échoué à convaincre… certainement par excès de rigueur et par incapacité à se remettre en cause. C’est comme si ce marché était resté dans une optique SOAP tandis que le reste du monde migrait vers une approche REST.

Bien entendu les deux univers – le grand public et l’entreprise – sont très différents et il n’est pas question de suggérer ouvrir les applications métiers à la seule authentification Facebook ! Mais il faut reconnaître que les forces qui ont poussé le grand public vers la fédération et la gestion décentralisée des identités sont désormais aussi à l’oeuvre dans le monde de l’entreprise : multiplication des services et des applications web, Cloud omniprésent, frontière réduite entre la vie (et les technologie) personnelle et professionnelle…

Les solutions de gestion des accès et des identités (IAM) vont donc probablement devoir s’adapter afin de prendre en compte ces mouvements de fond, et ce sera alors l’occasion de donner à la Fédération la place qu’elle aurait du avoir.

Mais pour cela il va falloir se remettre en question. Et en premier lieu accepter l’idée que le monde est devenu RESTful : l’approche REST est sans conteste la plus souple dès qu’il s’agit d’intégrer le contrôle d’accès et l’identité à une multitude d’applications hétérogènes indépendantes du socle de gestion.

Ensuite la représentation fortement hiérarchique des identités dans l’entreprise semble mal adaptée à l’environnement décentralisé qui se profile. La vision structurée forcée (ou plutôt « fortement encouragée« ) par LDAP apparaît notamment peu adaptée aux relations et aux projets transverses, qui fonctionnent en réseau plutôt que de manière strictement hiérarchique. Le backend devra donc probablement lui aussi évoluer dans un second temps vers une modélisation des relations plus souple, a priori organisée en réseau.

Evidemment les contraintes spécifiques de l’entreprise, qu’ignore le grand public, dicteront des adaptations nécessaires : toutes les identités n’auront par exemple pas besoin du même niveau de confiance (contrairement au grand public) et la notion de contexte de la connexion (la localisation, par exemple) prendra certainement une importance plus grande.

Et puis, surtout, le concept actuel de partenaire (les fameux « cercles de confiance » hérités de la Fédération actuelle) ne disparaîtra probablement pas du vocabulaire de l’entreprise. Mais un standard comme SAML est justement conçu pour assurer ce lien en permettant l’échange de point à point des informations d’authentification et d’autorisation. Mieux : un standard émerge qui est dédié, justement, à l’authentification multi-domaines via le nuage. Il s’agit de SCIM (System for Cross-domain Identity Management) et nous aurons certainement l’occasion d’en reparler.

Bref, les outils sont là pour que cette évolution puisse avoir lieu. Et d’ailleurs des solutions existent déjà elles aussi : les Ping Identity, Okta ou Salesforce Identity, par exemple, préfigurent déjà la Fédération des identités de demain pour l’entreprise. Tous ces services supportent OpenID et oAuth mais également une intégration à LDAP, ce qui est vital si l’entreprise doit pouvoir exporter ses identités (qui vivent encore dans l’annuaire) vers le reste du monde (qui vit souvent sur le web)

Mais au delà des solutions techniques c’est évidemment avant toute l’approche de l’entreprise vis-à-vis des identités de ses utilisateurs qui devra évoluer. La gestion de ces dernières devra notamment devenir plus granulaire : certaines identités auront plus d’importance que d’autres, voire même leur importance pourra varier en fonction du contexte applicatif. De même pour les applications : dans certains cas un utilisateur pourra s’authentifier avec, pourquoi pas, son compte Facebook, tandis que pour d’autres une authentification forte sera exigée (ne souriez pas : SAP supporte déjà OpenID et certains cherchent même à s’y authentifier grâce à un compte Facebook). Attention toutefois : une telle classification des différents types d’identités et des différentes applications par niveau de criticité s’avère complexe et pourra refroidir les ardeurs des consultants les plus motivés ! (Il n’y a qu’à prendre exemple sur la classification des données…)

Les premières expérimentations viendront probablement des e-commerçants. Car selon Gartner, en 2015 la moitié des identités des cyber-consommateurs seront basées sur un réseau social. Les commerçants n’auront donc plus le choix et devront abandonner leurs pratiques actuelles (des comptes utilisateurs maîtrisés à 100%) et accepter des identités fédérées chez la « bande à GAFA ».

Et comme cela a été le cas avec la consumérisation des équipements mobiles professionnels, ces utilisateurs en viendront probablement à exiger à terme le même confort sur le leur lieu de travail. Le rôle du RSSI sera alors, comme c’est déjà souvent le cas, d’éviter de répondre « Non » mais plutôt de formuler un « Oui, mais » acceptable aussi bien pour les utilisateurs que pour l’entreprise. La solution sera peut-être alors d’autoriser une telle fédération grand public pour contrôler l’accès aux ressources les moins critiques tout en la complétant à la volée par un facteur supplémentaire ou par une information complémentaire dès qu’il s’agit d’accéder à une autre jugée plus critique.

L’on retrouverait alors une hiérarchie basée sur la criticité des ressources de l’entreprise et du mode d’authentification initial. Un utilisateur déjà authentifié sur son poste de travail via sa session Windows / LDAP pourra par exemple accéder sans contrainte aux ressources externes les moins critiques de son entreprise (les photos du dernier événement marketing partagées sur Google Drive, par exemple…) alors que sans cela il aurait du passer par une authentification OpenID sur le portail web du fournisseur tiers.
Mieux : si elle le souhaite (et si lui aussi !) sa propre entreprise pourrait aussi devenir le fournisseur OpenID personnel de l’utilisateur. Ainsi être connecté sur sa session Windows professionnelle pourrait lui permettre d’accéder sans authentification supplémentaire à ses services personnels sur le web (et en permettant à l’entreprise de journaliser au passage l’usage qui en est fait)

Pour l’entreprise, devenir fournisseur OpenID afin d’exporter les identités de ses collaborateurs présente en outre un autre avantage : celui de pouvoir laisser créer des liens de confiance très facilement. Tout consommateur d’identité (le « Relying Party » dans le jargon OpenID) qui souhaite s’ouvrir à l’entreprise n’a alors qu’à accepter les identités qu’elle sert elle-même en tant que Provider OpenID, et il sera assuré que cette dernière a bien authentifié l’utilisateur.
La mise en oeuvre est d’un tel lien de confiance est immédiate et surtout elle peut-être à sens unique si nécessaire : le Relying Party n’a pas besoin de contacter l’entreprise au préalable. Dans le cadre d’un service SaaS dont l’entreprise devient cliente, par exemple, il suffit au fournisseur de l’ajouter comme Provider autorisé pour que tous ses utilisateurs soient immédiatement reconnus.

A l’inverse, le collaborateur de l’entreprise qui surfe sur des services grands publics en étant authentifié par son compte OpenID personnel pourra être reconnu au moment d’accéder à une ressource de l’entreprise (en particulier en situation de mobilité). Celle-ci pourra alors lui demander simplement une étape d’authentification supplémentaire afin d’élever le niveau de confiance que l’on peut lui accorder et ainsi le laisser accéder aux ressources professionnelles. Cela sans devoir se soumettre à un processus d’authentification complet.

Bien évidemment une telle proximité entre les domaines personnels et professionnels pourront laisser sceptiques les RSSI les plus stricts. Mais elle ne fait pourtant que refléter l’existant : bien souvent leurs utilisateurs surfent avec le même navigateur, qui maintient ouvertes des sessions à la fois personnelles (Facebook, Twitter) et professionnelles (une applications en mode SaaS), tout en exécutant en même temps une application Windows classique sur laquelle ils sont également authentifiés. Pourquoi alors ne pas centraliser et rationaliser toutes ces identités ? Et surtout, pourquoi ne pas choisir de rassembler ces identités avant que quelqu’un d’autre ne le fasse ?


Vous avez aimé cet article?

Cliquez sur le bouton J'AIME ou partagez le avec vos amis!

Notez L'article

Participez ou lancez la discussion!

Une réponse à Une seconde chance pour la fédération des identités

Catégories

Étiquettes

Archives

Ce site est une archive des messages à SecurityVibes de Septembre 2000 à Juillet 2014. S'il vous plaît visitez le Qualys Community pour les dernières nouvelles.