De la valorisation d'un projet de gestion des identités

En septembre dernier Eric Domage effectue une interview pour les nouvelles.net dans laquelle il indique qu'un projet de gestion des identités, c'est cher, long et peu profitable. Sur le même site, Bruno Vincent lui apporte une réponse où il essaie de réfuter tout au moins une partie de ces propos.
Personnellement, j'aurais tendance à dire : un projet IAM est effectivement cher, c'est long (et dans la réalité il ne se termine jamais!) et si c'est peu profitable, alors surtout ne le faites pas!

Pourquoi est-ce cher ? Tout d'abord, nombre de projets d'IAM se sont mal terminés et donc les budgets associés ont été gaspillés. Donc dès lors on peut déjà dire que cela revient cher pour ne pas faire grand chose. Maintenant si on prend un projet qui a suivi une démarche correcte de mise en oeuvre sous tous ses angles (processus, organisationnel, technique, humain), il va revenir forcément cher parce que vous devez réunir beaucoup de monde autour de la table (architecte, sécurité, RH, métiers, services généraux, intégrateur, éditeur...). On peut estimer que le coût des licences logiciels pour un grand compte représente moins de 20 % du projet. Vous pouvez aussi estimer que les coûts internes approcheront le coût d'intégration pour la mise en oeuvre. Si à cela, vous ajoutez le fait que le premier déploiement prend en général un périmètre réduit du SI (mais représentatif) et qu'il faudra continuer le déploiement sur plusieurs années (à l'échelle d'un grand compte), alors oui, l'addition commence à être salée, et le projet extrêmement long.

Alors faut-il ne rien faire?
Comme bien souvent, si on se pose la question du coût (en général pas trop difficile même si on a tendance à sous-estimer ces coûts au départ), il paraît normal de se poser la question des gains.
Déjà, il faut bien comprendre que toute entreprise fait déjà de la gestion des identités et des accès et ce de manière diffuse, de manière industrielle ou non. il va donc falloir rechercher les coûts associés à cette gestion d'identité diffuse car elle n'est généralement pas chiffrée (comment est géré le cycle de vie du collaborateur actuellement, quels sont les systèmes de sécurité intrinsèque à chaque application, etc) et se poser la question de ce qui peut être supprimer/améliorer/simplifier dans le cadre du déploiement d'un nouveau projet de gestion d'identité et donc les gains financiers associés.
Par ailleurs, un tel projet doit permettre d'améliorer divers aspects : amélioration de la qualité des données, obtention plus rapide des habilitations, productivité utilisateur... Chacun de ces aspects peut aussi être valorisé. Attention, à ne pas les survaloriser : il est impossible d'atteindre 100 % d'amélioration.
Concernant la sécurité et les aspects réglementaires, j'ai personnellement tendance à les valoriser à zéro. D'abord pour éviter le débat comme quoi on survalorise les gains en sécurité et aussi sur le fait que concernant l'aspect réglementaire, on n'a normalement pas le choix (reste juste à se poser la question des moyens à mettre en oeuvre pour être conforme et quel est le risque en cas de non conformité).
Quand vous aurez recencé tous les coûts et les gains potentiels, le constat est que la phase d'investissement est évidemment en début de projet avec une baisse de l'investissement dans le temps (qui se stabilise à un minima sans être nul car le SI évolue) et que les gains arrivent progressivement pour eux se stabiliser à un plus haut. Pour autant le croisement entre les deux courbes ne s'opèrent pas avant plusieurs années après le T zéro d'un projet.

Donc si vous lancez un projet IAM pour rechercher un retour sur investissment rapide, il y a peu de chances que ce projet aboutisse (à moins de ne déployer qu'une petite partie du fonctionnel de l'IAM).

Si aujourd'hui, on voit tant de projet de gestion d'identité, ce n'est pas tant pour les aspects financiers (même s'il faut bien entendu les prendre en compte) mais bien pour les aspects de conformité et sécurité. Les grands éditeurs l'ont bien compris dès le scandale Enron en 2001 et la naissance de la loi Sarbanes-Oxley puisqu'ils ont procédé à une consolidation du marché. Gageons que la crise actuelle et que la consolidation des acteurs du role management vont aussi permettre de lancer de nouveaux projets. Combien iront au bout? Seuls ceux, qui n'auront rien délivré ou qui n'auront rien fait, coûteront réellement cher.

IAM : la consolidation continue...

CA annonce aujourd'hui l'acquisition de Eurekify. Comme vu dans un de mes précédents billets, la consolidation des acteurs de l'IAM continue.
Désormais les cibles sont les éditeurs liés au role management. Les trois grands éditeurs du role management (Vauu, Bridgestream et Eurekify) auront finalement été racheté. Dans la dernière étude du Gartner, il était pointé du doigt les éditeurs n'ayant pas à leur catalogue une solution de role management. Que vont faire IBM et Novell sur le sujet?
Il est probable que le partenariat existant entre CA et Eurekify et la crise financière actuelle ont accélélé le processus de rapprochement entre les deux sociétés. Les deux produits avaient déjà fait l'objet d'une première intégration. Désormais CA va devoir clarifier sa stratégie afin d'éliminer les redondances entre CA Identity Manager, IdFocus (racheté il y a un mois) et Eurekify.

Consolidation de l'IAM

La consolidation des éditeurs IAM continue avec le rachat la semaine passée d'IdFocus par CA.

Depuis le début des années 2000, nombre de rachats ont pu être constatées :
- IBM a racheté Metamerge (juin 2002), Access360 (septembre 2002), Encentuate (mars 2008)
- Sun a racheté Waveset (novembre 2003), Vauu (fevrier 2008)
- CA a racheté Netegrity (octobre 2004) et IdFocus (octobre 2008)
- Oracle a racheté Oblix (mars 2005), OctetString (novembre 2005), Thor (novembre 2005), BridgeStream (septembre 2007)
- BMC a racheté Calendra (janvier 2005) et OpenNetwork (mars 2005)

Les derniers rachats à la mode sont liés au role management (voir les rachats de Bridgestream, Vauu, IdFocus). Certains à défaut de rachats mettent en oeuvre des partenariats renforcés (ainsi, désormais CA est revendeur des solutions Eurekify).

Role management, nouvel eldorado de l'IAM?

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.

Définir les rôles métiers ?

Définir les rôles métiers est-elle une étape nécessaire d'un projet d'IAM? La réponse à cette question est importante car certains en font un des enjeux du projet. Or cette étape peut être extrêmement difficile à réaliser. Pour autant, le projet d'IAM est-il voué à l'échec?

Avant de décrire comment on peut définir les rôles métiers, il est intéressant de revenir sur le modèle RBAC. L'objectif de ce modèle (défini par le NIST) est de factoriser l'attribution de droits d'accès à des ressources à un utilisateur afin d'éviter N relations entre les droits d'accès et l'utilisateur. Pour ce faire, le modèle introduit la notion de rôle qui permet d'effectuer des regroupements logiques de droits pour ensuite attribuer ces rôles à un utilisateur. Il est clair que cela simplifie les liens entre l'utilisateur et les droits d'accès.

Plusieurs méthodes existent pour définir les rôles métiers au sein d'une entreprise :
- la méthode top-down qui consiste à définir de manière théorique ces rôles métiers et à les appliquer directement sur le SI. Cette méthode a pour principal inconvénient de ne pas tenir compte de l'existant.
- la méthode bottom-up qui, au contraire de la précédente, effectue l'analyse de l'existant en s'appuyant sur des outils de role mining. Ces derniers explorent les bases utilisateurs du SI, effectuent des "calculs savants" pour déterminer les regroupements existant de droits d'accès. Cette méthode a plusieurs défauts : elle ne remet pas en cause l'existant, les regroupements de droits d'accès ne correspondent pas forcément à des rôles métiers.
- la dernière méthode consiste à combiner les deux précédentes et à confronter la théorie avec le relevé de l'existant. Cette méthode semble la mieux adaptée, pourtant, elle est loin d'être simple à mettre en oeuvre.

Les grands comptes français ont des SI complexes, une organisation complexe et un historique complexe. Il n'est pas rare que des personnes aient par exemple des droits pour des raisons historiques (dont personne ne se souvient), voire des passe-droits....
La méthode doit être alors appliquée à un périmètre limité d'applications (et non aux centaines, voire milliers d'applications de l'entreprise).
Définir de manière théorique les rôles métiers au sein de l'entreprise peut relever du sacerdoce et ne jamais se terminer d'autant plus que le métier de l'entreprise évolue.

Dès lors du fait que ce processus est long et jamais terminé, il est préférable de ne pas mettre en pré-requis la définition des rôles métiers pour lancer un projet IAM, voire ne pas en faire un enjeu du projet car le risque d'échec est élevé.

Au pire, si aucun rôle métier n'existe au moment où l'infrastructure IAM devient opérationnel en production, on créera un rôle pour un droit (parfois profil aussi en français) de façon bijective et au fur et à mesure de la définition des rôles, on ajoutera ces derniers en production.