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.