Qu'est ce que la gestion des identités en entreprise ?

Le CLUSIF a sorti en juillet 2007 un livret sur la gestion des identités. J'ai été agréablement surpris de constater que la définition donnée dans ce livret sur la gestion des identités était celle, mot à mot, que j'ai pu rédiger dans un cahier des charges rédigé en 2004 pour La Poste. Mais soyons franc aussi, autant cette définition pouvait à l'époque être représentative de la gestion de l'identité, qu'aujourd'hui cela ne me paraît plus être le cas. Reprenons la définition donnée à l'époque :

"La gestion des identités consiste à gérer le cycle de vie des personnes (embauche, promotion, mutation, départ...) au sein de la société avec tous les impacts sur le SI (création de Comptes utilisateurs, attribution de Profils utilisateurs, mise en oeuvre du contrôle d'accès...). Cette gestion des identités doit pouvoir être faite d'un point de vue fonctionnel par des non-informaticiens (exemple : Ressources Humaines, MOA, l’utilisateur lui-même) et d'un point de vue technique par des informaticiens (exemple : administrateur, MOE). La solution de gestion d’identité se veut être une solution globale sur la base d’une infrastructure centralisée avec une gestion fonctionnelle distribuée cohérente et efficace, et qui intègre les fonctionnalités suivantes :

• la gestion du référentiel central des utilisateurs (alimentation à partir de référentiels utilisateurs externes),
  
• la gestion du référentiel central des ressources concernées par la gestion des droits d'accès,
• la gestion des habilitations (gestion des profils, rôles, utilisateurs et workflow),
  
• le provisioning (synchronisation vers des référentiels cibles de sécurité),
• l'administration décentralisée,
• le self-service,
• l'audit et le reporting,
• le contrôle d'accès (authentification, autorisation, SSO)"

Cette définition me paraît aujourd'hui plus désuète et non représentative de tout ce que englobe la gestion des identités. Cette définition est centrée sur la gestion des utilisateurs en entreprise. La gestion des identités sur Internet est ignorée.

Pour donner une définition exacte de la gestion d'identité, il faut s'appuyer sur une architecture de services de gestion d'identités. Il est aussi indispensable de différencier référentiel utilisateurs (bases possédant des données maîtres ou autoritaires) et bases utilisateurs (bases de comptes associée à une application).

Une telle architecture peut être représentée sur le schéma ci-dessous que ce soit pour l'intra-entreprise que pour l'internet :
















Une architecture de services de gestion d'identité intra-entreprise s'appuie sur les composants suivants :

• un référentiel d'identité ; ce dernier stocke l'ensemble des fiches d'Identités ayant besoin d'accéder à des ressources SI (applications métier, intranet...) ou à des ressources matérielles (badge, PC...); une fiche d'identité est composée d'un ensemble d'attributs caractérisant cette identité,
• la gestion des habilitations ; ce composant permet de se synchroniser (alimentation amont) avec des sources amonts (RH, achats, définition de l'organisation...), de gérer les utilisateurs via une administration déléguée et décentralisée, de gérer les habilitations à l'aide d'un système de workflow et d'offrir une interface d'auto-administration aux utilisateurs,
• un service de provisioning (aussi appelé alimentation aval) ; ce composant permet de répercuter les modifications du référentiel d'identité sur les bases utilisateurs du SI mais aussi potentiellement d'explorer les bases utilisateurs du SI,
• un service de contrôle d'accès permettant de d'authentifier et d'autoriser un utilisateur à accéder à une ressource du SI en fonction des droits stockés dans le référentiel d'identité et relatif à cet utilisateur ; ce service peut offrir la notion de SSO (Single Sign On)
  
• un service de fédération d'identité permettant à l'utilisateur d'accéder sans contrainte de ré-authentification ou de re-saisie de donnée à des ressources de différents SI et protégés par des systèmes de contrôle d'accès technologiquement différents
  
• un service d'audit permettant de tracer ce qui est effectué par les autres composants et permettant de construire des rapports répondants aux différents besoins de la réglementation
  

Nous donnerons dans un prochain billet une description de la même architecture de gestion d'identité appliqué au monde de l'Internet.

Qu'est ce que l'identité?

Comment définir l'identité dans le monde actuel?
En termes de gestion d'identité, plutôt orienté intra entreprise, la tendance serait de définir l'identité numérique comme un ensemble d'attributs permettant de caractériser une personne. Dans le monde actuel, et plus particulièrement du web 2.0, est-ce bien vrai?

Est ce qu'un ensemble d'attributs tels que nom, prénom, adresse, téléphone, métier, etc constituent à eux seuls mon identité?
Est-ce que quand je surfe sur Internet sur certains sites webs après m'être authentifié et qu'on analyse les clics réalisés, la collecte d'informations relative à ma navigation n'est elle pas constitutive de mon identité?
Est-ce que quand je passe au supermarché, que je donne ma carte de fidélité et que par des outils de CRM on analyse mes habitudes d'achat, ces informations ne sont-elles pas constitutives de mon identité?
Est-ce que les écrits que je laisse sur ce blog sont constitutifs de mon identité?
Est-ce que quand je m'inscris sur un réseau social type facebook et que je me fais plus beau que je ne le suis, ces informations révées sont-elles constitutives de mon identité?

Au final, je pense qu'il faut retenir que l'identité d'une personne est l'image qu'on renvoie aux autres de façon volontaire (je donne les informations que je souhaite) ou de façon involontaire (je donne des informations car je n'ai pas le choix ou certaines informations sont collectées à mon insu).

Globalement, on peut retenir, à mon sens, que l'on renvoit quatre grand types d'identité pour une même personne physique :

• mon identité dans le monde professionnel : je suis créé au niveau RH, au niveau SI, je suis connu de mes collaborateurs, etc...
• mon identité dans l'administration (sécurité sociale, ANPE, impôt...) : bien que reprenant certaines informations de mon identité professionnelle, les informations dans l'administration ne communiquent pas totalement vers mon identité du monde professionnel
• mon identité personnelle qui me permet de naviguer sur Internet ou d'être affilié à un réseau de points-cadeaux. Je fournis quelques informations, véridique mais en nombre extrêmement limité. Par contre on essaye d'en capter un maximum à mon insu.
• mon identité fictive qui me permet de naviguer sur Internet en étant personne ou une personne fictive.

Ma Personne est bien constituté de l'ensemble de ces identités (voire plus) mais chaque ensemble d'interlocuteurs ne voit qu'une seule de mes identités (ou facette de ma Personne).

On comprend dès lors qu'un système tel que OpenID ou Windows CardSpace tente de répondre à un tel besoin en permettant à toute Personne de se créer N identités.

A l'inverse, il est aisé de comprendre que pour des raisons business, les entreprises marchandes souhaitent bénéficier d'identités véridiques et non fictives.

L'approche limité des standards ?

Les standards énoncés ne doivent pas être mélangés de façon encore à faire croire que cela est complexe.
- Liberty Alliance (ID-FF 1.2) et SAML ont convergé pour donner naissance à SAML 2.0. Désormais, depuis 2005, on ne devrait plus dire (n'en déplaise à Sun), je fais de la fédération d'identités compatible Liberty mais plutôt SAML 2.0. Rappelons que Liberty Alliance a laissé le soin à l'OASIS de faire évoluer SAML si cela s'avérait nécessaire, Liberty se focalisant sur les couches WSF et SIS (nous reviendrons sur ces dernières dans un billet ultérieur).
- dans l'article énoncé, il est mélangé sécurité des web services et fédération des identités dès lors qu'on parle des protocoles liés à WS-*. Il est vrai que vu la complexité de la pile WS-*, on peut se demander si une simple protection HTTPs n'est pas suffisante (mais là encore cela dépendra de l'architecture mise en oeuvre et du niveau de sécurité souhaité). Si l'on veut faire de la fédération d'identité, on sera amener à utiliser WS-federation (et donc WS-*) ce qui revient potentiellement à faire des choses très complexes. Le fait que WS-* soit porté par Microsoft et fourni dans ADFS sera certainement un frein pour WS-Federation (alors qu'il devrait l'être moins pour le reste de la pile WS-*)
- OpenID provient du monde open source et avait pour but au départ de fournir une fonction de SSO aux internautes navigant sur le web. OpenID a la particularité de donner à l'utilisateur la possibilité de se définir de multiples identités de façon à se garantir une certaine anonymité. Le fait que certains acteurs comme Orange mette en oeuvre OpenID en garantissant la véracité des données fournies détourne OpenID de son modèle original.

Il est clair qu'au délà de la complexité technique de mise en oeuvre :
- il existe des complexités organisationnelles et juridiques de mise en oeuvre,
- les éditeurs ne veulent pas rester dans le carcan d'un protocole et préférent fournir des solutions fonctionnant comme des hubs multi-protocoles.

Dans tous les cas, il est clair que l'apport de ces standards est une vraie avancée dans le monde de l'identité et que demain verra la mise en oeuvre de nombreux projets de ce type car la fédération d'identités est le futur de la gestion des identités du fait que les systèmes d'informations s'ouvrent de plus en plus sur Internet.

Allouer les ressources : moins de techniques, plus de worklow ?

Toujours dans le dossier 01 Informatique du 15/11/2007 consacré à la gestion des identités, un article indique l'importance vitale du workflow et du self-service afin que l'utilisateur puisse demander lui-même l'attributation de certaines ressources après validation des acteurs adéquats et cet article laisse à penser que le provisioning de ressources est chose aisée.

Il est vrai que l'une des briques importantes est le moteur de workflow et qu'il est attendu que ce moteur soit de bonne qualité pour s'adapter au métier de l'entreprise. Remarquons qu'à ce stade, la gestion des identités recouvre, quel que soit le métier de l'entreprise, les mêmes processus : arrivée / mutation / départ d'une Personne... il est donc attendu que le workflow puisse s'appuyer sur une organisation spécifique (propre à chaque entreprise), offrir des IHMs de validation paramétrables, prendre en compte le modèle de droits de l'entreprise...

Pour autant, de nombreux grands comptes ont déjà mis en oeuvre des systèmes de workflows dans le cadre de dématérialisation de processus internes et il peut être légitime de se poser la question de savoir s'il n'est pas plus judicieux d'appuyer un système de workflow connu de l'entreprise à un outil de provisioning du marché. Il n'existe pas de réponse type à cette question. Chaque entreprise devra étudier l'intêret ou non de ré-utiliser un workflow connu plutôt que celui inclu dans l'outil de provisioning. On peut toutefois noter que, évidemment il n'y a pas de prise en main de l'outil de workflow car il est déjà connu mais il sera nécessaire de mettre en oeuvre un interfaçage avec l'outil de provisioning. A l'inverse, si l'on retient l'outil de workflow inclu dans l'outil de provisioning, il sera nécessaire de prévoir une phase de prise en main de ce moteur de workflow et de prévoir potentiellement un interfaçage avec l'outil de workflow déjà retenu au sein de l'entreprise. L'un des critères de choix de prendre ou non le moteur de workflow inclu dans la solution de gestion des identités est aussi le fait que ce moteur de workflow est déjà pré-packagé pour la gestion des identités ce qui n'est pas forcément le cas pour un moteur de workflow standard. A l'inverse, il sera difficile de faire autre chose que de la gestion d'identités avec un moteur de workflow de gestion d'identités.

Au final, ce qu'il faut retenir c'est que la complexité ne provient pas de la technique. Implémenter un workflow avec un processus bien décrit n'est pas extrêmement difficile s'il a été bien spécifié. La difficulté provient de l'organisation à mettre en place pour être acteur de ces processus et surtout des modifications d'organisations qui auront un impact fort sur les processus.

Le fait de donner la possibilité à l'utilisateur final de demander l'attribution à des ressources me paraît à mon sens être une hérésie à plusieurs titres :
- ceci va à l'encontre de la définition de rôles métiers puisque l'utilisateur demandera l'accès à des ressources et non l'attribution d'un rôle métier (laisser la possibilité à l'utilisateur final demander un rôle métier aurait encore moins de sens).
- ceci amène un niveau de complexité à l'utilisateur final qui n'est pas forcément apte à comprendre l'objet de la demande : comment l'utilisateur sait choisir quel est le bon accès auquel il devrait avoir droit au sein d'une application?

Au pire, il devrait pouvoir être créer une IHM pour l'utilisateur final permettant de demander l'attribution de certaines ressources spécifiques connues de tous et ne nécessitant pas de connaissances spécifiques à l'avance.

Concernant le provisioning, je m'étonne qu'on puisse dire que cela soit chose aisée. En effet, les solutions de gestion des identités offrent des connecteurs de provisioning pour systèmes d'exploitation, les annuaires, les SGBDs, les ERPs et c'est à près tout. Or plus de 80 % des applications d'un SI s'appuient sur des progiciels spécifiques ou des développement à façon ce qui complexifie énormément la tâche de provisioning.
A mon sens, provisioner une application devrait être le choix de dernier recours et ne devrait être effectué que si le jeu en vaut économiquement la chandelle. Je reviendrais dans un prochain billet sur comment on peut éviter les problématiques de provisioning en faisant un peu d'architecture.