Arismore était présent pour la seconde fois aux Assises de la Sécurité du 7 au 10 octobre 2009. L'occasion pour Arismore de se faire connaître :
- de par le nombre de clients fréquentant ce salon,
- de faire faire à GDF SUEZ un retour d'expérience du projet IAM réalisé par Arismore,
- de participer à une table ronde sur sécurité et architecture d'entreprise.
vendredi 23 octobre 2009
jeudi 18 décembre 2008
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.
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.
jeudi 13 novembre 2008
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.
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.
samedi 25 octobre 2008
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.
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.
mardi 14 octobre 2008
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?
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?
mercredi 30 avril 2008
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 :
- 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.
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...)
- 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.
mercredi 5 mars 2008
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 :
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 :
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.
- la vision de l'identité fédérée par les entreprises,
- la vision utilisateur (user-centric)
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
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.
Inscription à :
Articles (Atom)
Articles
