Le Jericho Forum s’était illustré en 2005 en jetant son désormais célèbre pavé dans la mare le périmètre : le fameux document intitulé « Moving away from the Firewall-centric view », à l’origine d’un débat animé sur la notion de dépérimétrisation.

L’objectif du forum Jericho était alors de promouvoir l’idée d’une défense en profondeur plutôt que seulement périmétrique. C’était peut-être un peu en avance sur son temps, et certainement très provocateur, mais l’idée a fait son chemin depuis : un concept comme le NAC, ou la mobilité ultra-banalisée tendraient même à lui donner raison.

Aujourd’hui, le groupe s’intéresse au contrôle d’accès et à l’identité, avec toujours la même préoccupation : décentraliser, dépérimétrer (sic) et lancer le débat. En ce sens, le travail actuel du Forum Jericho sur l’avenir du contrôle d’accès risque très certainement de provoquer les mêmes débats, railleries et incompréhensions qu’en 2005.

A l’ordre du jour : la disparition des listes de contrôle d’accès, rien de moins ! Il ne s’agit bien entendu pour l’instant que d’un exercice intellectuel – périlleux et certainement un peu naïf, comme n’ont pas manqués de le souligner plusieurs membres lors de la séance de travail à laquelle nous avons pu participer. Mais il a le mérite d’ouvrir une vraie brèche dans les habitudes.

Les listes de contrôle d’accès, donc. Le Jericho Forum estime qu’elles sont trop statiques et trop complexes entretenir. Et, surtout, qu’elles ne sont pas adaptées aux changements qui se présentent à l’horizon, et notamment en terme de contrôle d’accès décentralisé tel qu’exigé par le Cloud Computing et les applications en mode SaaS.

« Ce n’est pas qui vous prétendez être qui importe, mais ce que vous prétendez être », résume l’un des intervenants. Le Jericho Forum prône ainsi la transition d’un modèle d’ACL actuel dans lequel chaque individu est un nom dans un annuaire interne (et isolé) à un système décentralisé dans lequel l’individu est décrit par une série d’assertions (« claims » en anglais) qui le définissent et qui sont confirmées par une multitude de sources externes autoritatives. Ainsi Monsieur untel est un médecin (c’est confirmé par l’ordre des médecins), ou un employé de telle société (c’est confirmé par l’employeur), ou un membre de telle communauté (c’est confirmé par la communauté).

« Il faut désormais essayer de consommer les identités existante plutôt que d’en créer une nouvelle à chaque fois qu’un utilisateur veut accéder à un nouveau service », poursuit l’intervenant.

Pour un site web, par exemple, cela pourrait se traduire par arrêter de créer un nouveau compte pour chaque utilisateur qui se présente, et plutôt accepter une identité unique (insérez ici le standard émergeant de votre choix) et se contenter de valider simplement une assertion comme quoi il est désormais membre de ce site web. Et si cette information se révèle nécessaire par la suite afin de prendre une décision de contrôle d’accès pour une autre entité (un autre site web, par exemple), ce dernier n’aura alors qu’à interroger le premier site via un Service Web afin de vérifier la validité de l’assertion.

Bien entendu, une telle vision implique non seulement qu’il n’y ait au pire qu’une poignée de standards d’identité universels (bon courage), mais aussi une multitude de « claim providers » capables de d’exposer des Web Services pour répondre aux requêtes en temps réel. Bref, nous en sommes encore (très) loin !

Toutefois l’exemple de l’intervenant, qui a déjà mis en oeuvre une approche de ce type au sein de sa société pharmaceutique, est intéressant et surtout concret : « Certaines informations que nous diffusons ne peuvent être communiquées qu’à des médecins. Nous conservions donc jusqu’à présent dans notre Active Directory un attribut afin de savoir si un utilisateur était ou non médecin. Nous passions beaucoup de temps à maintenir cet attribut à jour. Désormais, celui-ci a disparu et nous l’avons remplacé par un appel à un Service Web qui interroge l’ordre des médecins. Nous avons donc une réponse en temps réel, toujours à jour, afin de prendre notre décision de contrôle d’accès » explique-t-il.

L’avantage majeur de cette approche est qu’elle atomise le contrôle d’accès : l’individu est une identité unique, décorrélée de tout droit et entité spécifique, et à laquelle lui-même ajoute ses propres revendications (« je suis médecin », « je suis employé de telle société »). Celles-ci sont alors vérifiées en temps réel au moment du contrôle d’accès via un Service Web par l’entité autoritative qui la concerne (qui peut-être interne – par exemple pour déterminer si l’individu est toujours employé de l’entreprise – ou externe, via des relations de confiance à négocier).

Dans la vision du Forum Jericho, l’ACL n’existe donc plus : elle n’est qu’une série de revendications rattachées à une identité publique générique. A chaque opération de contrôle d’accès, des requêtes sont émises afin de s’assurer que chacune des revendications nécessaire est encore valide. Le contrôle d’accès devient ainsi totalement dynamique, et basé sur des informations en temps réel.

Vous trouvez cela tiré par les cheveux ? Attendez la suite : l’autre intérêt que le Jericho Forum voit dans cette approche, c’est que dans un second temps l’information elle-même pourra embarquer ses propres exigences en matière de revendications.

Imaginons qu’un document indique que l’information qu’il contient ne peut être lue que par un médecin employé de tel laboratoire pharmaceutique. On peut alors envisager que où qu’il soit, le lecteur chargé d’ouvrir ce document soit capable de demander l’identité de l’utilisateur (via un OpenID, oAuth ou autre procédure devenue standard), récupère les revendications associées à cette identité, puis aille interroger les « claims providers » concernés afin de savoir si l’utilisateur est effectivement toujours employé par le laboratoire en question, et toujours médecin, avant de libérer le document

Il s’agit d’une approche de DRM, certes, mais passée à la vitesse supérieure : le contrôle d’accès est alors parfaitement universel (depuis n’importe quel client ou lecteur logiciel) puisque à chaque étape ce sont des standards connus de tous qui sont utilisés (OpenID, SAML, Web Services…).

Mais revenons sur terre : les critiques ne manquent pas, y compris au sein du Forum Jericho, face à cette vision. D’abord, comme il a été noté, elle repose in fine sur la présence d’un standard unique en matière d’identité : malgré de nombreux efforts de tous horizons ce n’est encore jamais arrivé et d’aucuns estiment que ça n’arrivera jamais (comme le fait remarquer un participant, on n’arrive déjà pas à se mettre d’accord sur un protocole de Messagerie Instantanée commun…).

Ensuite, elle exige la présence de « claim providers » nombreux, tous capables de publier des Services Web pour valider les claims qui les concernent. Là aussi, difficile d’imaginer un enthousiasme planétaire dans la mise en oeuvre ce qui, au final, se révèle un nouveau projet à financer.

Et puis, surtout, cette approche a surtout du sens en présence de sources officielles (l’ordre des médecins, des avocats, des plombiers, voire les DRH des entreprises en interne) capables de s’engager sur la validité des informations fournies.

Mais il n’en reste pas moins que le débat est terriblement intéressant et pose de façon pertinente la question de la gestion des identités dans le nuage, un thème qui va probablement être d’actualité désormais, notamment pour ce qui est des solutions hybrides (locales et distribuées).