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.

Fédération d'identité : çà bouge chez les éditeurs...

Sun annonce la sortie imminente de la version commerciale d'OpenSSO Enterprise qui reprend les briques Sun Access Manager, Sun Federation Manager et une nouvelle brique concernant la sécurisation des web services (voir le site SUN), le tout dans une appli J2EE. Du point de vue marketing, SUN reprend surtout le nom de la solution en OpenSource...
A l'inverse, CA qui possédait déjà une solution (mais pas J2EE) permettant de faire du web SSO (CA SiteMinder), de la fédération d'identité (CA SiteMinder Federation Security Services) et de la sécurisation des web services CA SOA Security Manager) tous basés sur SiteMinder, choisit de proposer désormais des solutions fonctionnant avec CA SiteMinder mais ne le nécessitant plus en pré-requis. Ainsi, début d'année 2009, devrait sortir CA Federation Manager permettant de faire de la fédération d'identité sans nécessiter CA SiteMinder ou un autre WAM (Web Access Management).
Oracle pour sa part avait déjà choisi d'avoir une solution de fédération d'identité (Oracle Identity Federation) ayant la capacité de s'interfacer avec différents WAM (en l'occurence Oracle Access Manager et CA SiteMinder).
Il en va de même pour PingIdentity qui propose un produit PingFederate permettant de s'interfacer avec différents WAM (PingFederate, Oracle Access Manager, IBM Tivoli Access Manager).
Je ne vous parlerais pas de la stratégie d'IBM et autres consorts car je n'ai pas encore eu le temps d'y jeter un oeil.
Quelle que soit la stratégie retenue de concentration ou de déconcentration retenue, il est sûr que le client final ne devrait pas voir se réduire la partie financière associée mais cela devrait lui permettre soit de rationaliser les éditeurs présents en son sein ou au contraire lui permettre une concurrence accrue (pour au final peut-être gagner sur les prix...).

Toujours est-il que ces positionnements et repositionnements préparent une bataille rude pour un marché qui va exploser dans les années à venir.

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?

Explications sur le modèle RBAC

Absent quelques semaines pour cause de paternité, je reviens maintenant sur quelques éléments de l'IAM.

RBAC (Role Based Access Control) définit un modèle d'autorisation pour accéder à des ressources. Ce modèle a été mis en oeuvre par le NIST (National Institute of Standard and Technology). Le schéma ci-dessous représente ce modèle avec les dénominations du NIST (traduction littérale des termes employés).



On appelle "Permissions" l'ensemble des opérations qui peuvent être réalisé sur un ensemble de ressources appartenant à une même application ou infrastructure. Des exemples de "Permission" peuvent être des groupes Unix ou Oracle, un profil dans une application web permettant d'accéder à des menus spécifiques...

Le rôle est un élément de factorisation permettant de donner un ensemble de Permissions à des utilisateurs en une seule opération ("j'ai ce rôle donc j'ai ces Permissions"). Le modèle permet aussi de créer des rôle imbriqué ou héritage de rôle. Il est intéressant de noter qu'il n'existe pas de sémantique spécifique sur la notion de rôle. Certains essaieront d'y associer la notion de métier ou fonction mais rien n'y oblige.

Il est possible de mettre des contraintes sur la notion de rôle :

• une date de début d'activation,
• une date de fin d'activation,
• un périmètre permettant de contraindre le rôle (périmètre sur les données via un recoupement géographique, organisationnel, valeur chiffrée permettant à un acheteur de na pas passer de demande d'achat supérieur à ce montant...)

Un rôle devra pouvoir être donné de deux manières :
- statique (il est donné manuellement par quelqu'un).
- dynamiquement (il est donné de manière automatique par le module de gestion des habilitations selon certaines valeurs des attributs des identités répondant à des règles implémentées).

Il est à noter qu'un rôle peut être soumis à workflow mais que les Permissions associées ne devraient jamais être soumise à workflow sous peine de rendre le modèle incohérent. Imaginons qu'un rôle X donne les permissions A et B. Le rôle X est validé, la permission A est validé mais la permission B est refusée. Que doit-on faire? Refuser aussi X et A : cela rendrait inconsistant la notion même du rôle. Donner X et A mais ne pas donner B : il serait difficile de comprendre cet état de fait sur la fiche de la personne en question à postériori à moins de tracer ces éléments dans la fiche ce qui devient très complexe.

Si on veut soumettre une Permission à workflow, cela est possible mais cette Permission ne doit pas être incluse dans un rôle.

La notion de rôle n'a de sens que pour le module de gestion des habilitations. Elle n'a aucun sens pour les applications provisionnées ou protégées par un web SSO.
Par contre afin que le module de gestion des habilitations puissent propager les droits dans les systèmes cibles ou puissent protéger ces systèmes cibles, il est nécessaire de modéliser le nom de chaque Permission dans le module de gestion des habilitations. L'erreur à ne pas commettre est de modéliser la définition des Permissions dans le module de gestion des habilitations (quelles opérations sur quelles ressources). Ces couples Opérations-Ressources doivent rester la propriété des applications sous peine de mettre en oeuvre un système non maintenable.

La mise en oeuvre de rôle impliquera une gestion de ces rôles :
- les définir et les faire vivre (modification, suppression),
- les faire prendre en compte les réorganisations,
- définir les propriétaires, les administrateurs.

Cette gestion de rôle (role management) s'avère souvent complexe et sera abordée dans un prochain billet.

La gestion de l'identité sur Internet

Dans le billet précédent, nous avons tenté d'expliquer la gestion de l'identité en entreprise (interne au SI). Le présent billet a pour objectif d'expliquer cette gestion de l'identité sur Internet. Dès lors, deux visions s'affrontent :

• la vision de l'identité fédérée par les entreprises,
• la vision utilisateur (user-centric)

Vision de l'identité fédérée par les entreprises :
Dans le cadre de cette vision, l'architecture de service que nous avons décrite pour la gestion de l'identité en entreprise reste valable mais doit être interprétée quelque peu différemment :

Dans ce contexte, l'objectif est d'exposer des services sur Internet à des internautes et de leur offrir la possibilité de naviguer en SSO. Dès lors, les différentes fonctions doivent être interprétées comme suit :

• le référentiel d'identités qui stocke la liste des identités autorisées à accéder à des services,
• gestion des habilitations : ce module permet au internautes de souscrire à différents services en ligne ; il fonctionne généralement comme un self-service et embarque rarement des notions de workflow,
• provisioning : ce module permet de créer les comptes sur des systèmes cibles après inscription à un nouveau service,
• contrôle d'accès : permet d'authentifier un utilisateur et lui permet de naviguer en SSO entre plusieurs services souscrits,
• fédération : ce module permet de fédérer des services inter-entreprises afin d'offrir une navigation fluidifiée à l'utilisateur (pas de nécessite de plusieurs authentifications, pas de nécessité de re-saisie de données personnelles). Ce type de fédération est associé aux protocoles Liberty Alliance, SAML, WS-*
• Audit : ce module permet de tracer ce qui est effectué dans les autres modules et d'effectuer un reporting adéquat

Dès lors que la fédération est mise en œuvre sur ce type de vision (Liberty Alliance, SAML, WS-*), elle nécessite de mettre en œuvre des accords juridiques entre les entreprises ainsi que des contrats d'interface pour que cela fonctionne bien tant au niveau business que technique.

La vision utilisateur (user-centric) :
L'objectif de cette vision est de donner la main à l'utilisateur de sorte qu'il n'y ait pas besoin d'accords entre les entreprises au préalable. L'architecture précédemment décrite n'a pas d'utilité vu de l'utilisateur mais peut exister pour autant pour les services exposés par les entreprises.

Dans cette vision utilisateur, l'idée est que l'utilisateur est complètement maître de son identité (ou ses identités), peut choisir de les stocker chez l'Identity Provider de son choix, de partager les informations relatives à son identité vers qui il veut.

Cette vision s'appuie sur des protocoles de type OpenID ou CardSpace. A noter que le premier nécessite de faire opérer un Identity Provider alors que le second s'appuie sur le stockage de vos cartes d'identité sur votre poste de travail.

Nous détaillerons dans un prochain billet le fonctionnement de ces protocoles.

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.