C. Scénarios de mise en œuvre 27








télécharger 325.98 Kb.
titreC. Scénarios de mise en œuvre 27
page1/10
date de publication30.03.2017
taille325.98 Kb.
typeScénario
ar.21-bal.com > loi > Scénario
  1   2   3   4   5   6   7   8   9   10





Méta-système et mash-up des identités avec les produits et technologies Microsoft

Version 1.0

Publication : Décembre 2010

Auteur : Philippe Beraud (Microsoft France), Stéphane Goudeau (Microsoft France), Benjamin Guinebertière (Microsoft France)
Copyright

© 2010 Microsoft Corporation. Tous droits réservés.

Résumé

Ce livre blanc permet de mieux appréhender les scénarios qui peuvent se matérialiser aujourd’hui par la simple concrétisation du méta-système d’identités au sein de l’entreprise, entre organisations, dans le nuage et avec les réseaux sociaux.

Dans ce cadre, le document revient sur les différentes initiatives, et standards relatifs à l’identité et met en évidence les axes d’interopérabilité tels que rendus possibles par les produits et technologies Microsoft.

doccoverbottom.gif

© 2010 Microsoft Corporation. Tous droits réservés.

Les informations contenues dans ce document représentent le point de vue actuel de Microsoft Corporation sur les sujets traités à la date de publication. Etant donné que Microsoft doit s’adapter aux conditions changeantes du marché, ces informations ne doivent pas être interprétées comme un engagement de la part de Microsoft, et Microsoft n’est pas en mesure de garantir l’exactitude de toute information présentée après la date de publication.

MICROSOFT NE DONNE AUCUNE GARANTIE EXPRESSE OU IMPLICITE DANS CE DOCUMENT.

Les autres noms de produits ou de sociétés cités dans ce document peuvent être des marques de leurs propriétaires respectifs.

Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • Etats-Unis
Sommaire

a.Notions de méta-système et de mash-up d’identités 4

b.Protocoles et formats de jetons de sécurité 9

b.1Identités numériques d’entreprise 9

b.2Identités numériques sociales/grand public 24

c.Scénarios de mise en œuvre 27

c.1Cadre d’illustration avec les technologies Microsoft 27

c.2Scénarios B2B de collaboration fédérée entre organisations 37

c.3Scénarios B2C/G2C pour le grand public 41

c.4Expérimentation de ces scénarios au MTC Paris 44

d.Et le respect de la vie privée ? 45

e.En guise de synthèse 49

f.Pour en savoir plus… 50

g.Restons en contact 51



a.Notions de méta-système et de mash-up d’identités


La complexité de mise en œuvre et de gestion de l’authentification et du contrôle d’accès aux applications et aux autres ressources d’une organisation rend difficile la tâche des développeurs et des professionnels de l’informatique pour satisfaire aux besoins de leur organisation.

La plupart des applications, quels que soient la plateforme logicielle et l’environnement technique, s’appuient sur des identités. Une identité numérique est, d’une façon générale, un ensemble d’informations à propos d’une entité, telle qu’un utilisateur. Les informations d’identité influencent le comportement des applications - elles déterminent ce qu’un utilisateur est autorisé à faire, contrôlent la façon dont l’application interagit avec l’utilisateur, par exemple.

La notion d'identité est essentielle, mais travailler avec les identités est devenu difficile : en fonction de la situation et du contexte d’accès à mettre à disposition, de très nombreux choix de technologies (et de standards) en matière d’identité sont possibles, avec à la clé de multiples représentations (et protocoles), ainsi qu’une diversité de modèles de programmation fonction des éléments précédents et/ou des environnements techniques.

Cette multiplicité de technologies d’identité, de protocoles et de formats de jetons de sécurité induit une complexité et un coût d’implémentation notable dans un contexte donné, sans pour autant parvenir à satisfaire l’ensemble des scénarios d’accès souhaités que ce soit au sein d’un même domaine de sécurité et/ou , entre domaines de sécurité, et ce avec les exigences associées en termes de sécurité.

Il n’est donc pas rare de voir une solution tactique bloquer une interopérabilité future : les applications deviennent dépendantes d’une technologie…ET bornées par les contraintes de la technologie choisie.

S’ajoute à cela la difficulté à interopérer avec des applications et des systèmes hétérogènes et à adapter ces mêmes applications à de nouveaux scénarios émergents comme les services hébergés, etc. ; les architectures orientées service (Service Oriented Architecture en anglais ou SOA en abrégé) amplifiant les défis ainsi posés.

Kim Cameron, architecte en chef de l’identité numérique chez Microsoft, lançait, il y a maintenant plus de quatre ans au travers de son blog http://www.identityblog.com, une large initiative visant à améliorer la sécurité et l’interopérabilité des identités en ligne.

Suite à l’expérience Microsoft Passport ou Windows Live ID (aujourd’hui) (Cf. section éponyme § b.2.1) qui est un succès en termes de fournisseur d’identités pour MSN (avec plus de 520 millions d’utilisateurs et plus d’un milliard d’ouvertures de session/jour) mais également un échec comme fournisseur d’identités pour l’Internet, cette initiative s’est d’abord concentrée sur le développement et le partage d’une compréhension formelle des dynamiques amenant des systèmes d’identités numériques en ligne à être couronnés succès ou, au contraire à échouer et ce, dans différents contextes. Les larges discussions qui s’en sont suivi avec l’industrie, les associations de défense des libertés individuelles, etc. ont conduit à établir un consensus autour de 7 lois de l’identité qui sont discutées dans le livre blanc The Laws of Identity1.


Prises dans leur ensemble, ces lois définissent un « méta-système d’identités unifié » qui offre à l’Internet les fondations d’une couche Identité qui, de façon évidente, lui fait défaut. La réponse à un tel défi offre la possibilité de créer, sur la toile, des solutions et des services interopérables très sécurisés à même d’offrir à leur tour au grand public, aux administrations et aux entreprises plus de choix, de flexibilité et de sécurité dans leur utilisation d’Internet au quotidien. Elle est donc bénéfique pour tous.

Un méta-système d’identités (système de systèmes d’identités) constitue une architecture interopérable pour l’identité numérique qui présume que les personnes disposent de plusieurs identités numériques basées sur de multiples technologies/protocoles, implémentations et fournisseurs sous-jacents.

Une telle approche permet de transcender les frontières dans de multiples dimensions et simultanément entre :

  • Les secteurs industriels, le secteur public, etc. fonction du scénario ;

  • Les entreprises et les institutions dans le contexte du scénario considéré ;

  • Les protocoles mis en œuvre dans ce cadre ;

  • Les environnements techniques et plateformes utilisées ;

  • Les produits et technologies d’identités et de sécurité mis en œuvre pour rendre le service ;

  • Et bien sûr les exigences en termes d’identité (allant d’une vérification forte de l’identité à un commentaire anonyme).

Elle permet non seulement, pour les scénarios visés, aux personnes d’être au contrôle, au travers le cas échéant de la notion de « sélecteur d’identités » ou d’autres agents utilisateur, de leurs identités et de l’usage qui en est fait, mais également aux organisations de pouvoir continuer à utiliser et bénéficier de leur investissements existants en termes d’infrastructure d’identités, de choisir la technologie d’identités qui leur est la mieux appropriée, et de plus de migrer facilement d’anciennes technologies vers de nouvelles technologies sans pour autant sacrifier l’interopérabilité avec les autres.

Les organisations recherchent l’interopérabilité pour pouvoir utiliser la mosaïque de technologies la plus proche de leurs besoins. L’interopérabilité (de la gestion) des identités entre plateformes et le Web (sites Web et services Web) est particulièrement importante pour l’amélioration de la valeur des technologies pour les administrations, les entreprises et le grand public.

Le livre blanc The Identity Metasystem2 présente, en partant des conclusions et du large consensus des lois de l’identité, une architecture ouverte et interopérable pour construire un tel méta-système et décrit comment participer à ce méta-système d’identités qui, par nature, n’appartient à et n’est contrôlé par personne en particulier.

L’approche ainsi proposée vise à la base à :

  1. Définir l’identité numérique comme un ensemble de revendications (claims en anglais) qui caractérise un utilisateur (ou entité) dans le monde numérique ;

  2. Externaliser l’authentification de l’application (voir également le contrôle d’accès).

« Stop hard-coding security into applications and stop creating operating system (OS)-level accounts on servers. Consume these as services external to the application. »

Neil MacDonald 13 April 2006

Gartner Group: Achieving agility: building blocks for a policy-driven, agile security services infrastructure

Différentes parties participent au méta-système de diverses façons.

Comme illustré dans la Figure , les trois rôles canoniques au sein du méta-système sont les suivants :

  • Le Sujet (personne ou entité autre) sur lequel des revendications sont effectuées : « Ce que vous dites sur vous-mêmes ou ce que d’autres disent sur vous » - Des exemples de sujets sont des utilisateurs particulier et/ou professionnel, des entreprises, des administrations, etc.

  • Le Fournisseur d’identités qui émet les identités numériques (Identity Provider en anglais ou IdP en abrégé) - Par exemple, les gouvernements peuvent émettre des identités pour leurs citoyens, les sites de commerce en ligne peuvent émettre des identités pour leurs clients, les fournisseurs de cartes de crédit peuvent émettre des identités permettant le paiement, et les utilisateurs finaux peuvent utiliser des identités auto-émises dans les contextes où cela est acceptable comme lors de l’ouverture de session sur des sites Web.

Schématiquement, un fournisseur d’identités constitue une autorité qui fait des revendications sur un sujet. Ces revendications sont physiquement transportées dans ce que nous allons appeler des jetons (d’authentification et/ou d’autorisations). Pour cela, le fournisseur d’identités implémente un service de distribution de jetons (Security Token Service en anglais ou STS en abrégé) qui émet les jetons. En d’autres termes, un jeton représente l’identité émise par le fournisseur d’identités. Les demandes (authentifiées) de jetons sont effectuées à l’aide de protocoles standards.

Les jetons sont utilisés par des consommateurs d’identités qui font confiance au STS.

  • Les Parties en confiance ou Consommateurs d’identités (Relying Party en anglais ou RP en abrégé) qui requiert des identités - Par exemple, une application comme un site Web d’une organisation qui utilise des identités offertes et validées par d’autres organisations dignes de confiance pour la délégation de l’authentification (voir des autorisations).



Figure – Rôles canoniques du méta-système.

Aujourd’hui, une application récupère typiquement une seule information d’identité simple telle qu’un nom d’utilisateur. Pour avoir davantage d’informations, l’application doit interroger un référentiel distant tel qu’un service d’annuaire et/ou une base de données locale.

Avec une identité fondée sur des revendications, chaque application peut demander exactement les revendications dont elle a besoin ; un STS les place dans le jeton qu’il crée. Dans la pratique, une revendication peut :

  • Identifier un utilisateur,

  • Véhiculer l’appartenance à un groupe ou à un rôle,

  • Transporter des informations de personnalisation comme le nom à afficher pour un utilisateur,

  • Donner ou dénier le droit de faire quelque chose comme l’accès à une information particulière ou l’invocation de méthodes spécifiques,

  • Limiter le droit de faire quelque chose comme un montant de délégation,

  • Etc.

Ceci peut supposer, le cas échéant, pour le consommateur d’identités, une évolution bénéfique de l’application considérée de façon à externaliser, dans les faits, son authentification.

Dans de nombreux cas, les participants dans le méta-système sont susceptibles de jouer plus d’un rôle. De ce fait, le méta-système d’identités contribue à établir au global un écosystème de confiance.

A ce titre, un quatrième rôle peut être introduit dans ce modèle, en l’occurrence celui de Fournisseur d’attributs (Attribute Provider en anglais ou AtP en abrégé) qui émet des revendications additionnelles vis-à-vis de l’identité numérique considérée dans le contexte. En effet, pour un scénario donné, le fournisseur d’identité ne dispose pas forcément des informations nécessaires pour produire l’ensemble des revendications nécessaire pour satisfaire la politique de sécurité du consommateur d’identité.

L’authentification initiale auprès d’un fournisseur d’identité et l’émission sur cette base d’un jeton d’authentification peut servir à l’obtention, sous forme d’un autre jeton, de revendications complémentaires en fonction du contexte auprès d’un tel fournisseur de façon à disposer au final d’une identité composite qui réponde aux exigences du consommateur d’identité. On parle ici de « mash-up » d’identité comme suggéré par la Figure .

Cette identité composite peut se présenter sous la forme :

  • D’un nouveau jeton dans lequel l’identité résultante est fondée sur les revendications issues du fournisseur d’identité et sur celles additionnelles en provenance d’un ou de plusieurs fournisseurs d’attributs ;

-ou-

  • Du jeton émis initialement par le fournisseur d’identité et du ou des jetons émis par le ou les fournisseurs d’attributs. L’identité résultante est portée par l’ensemble des jetons. Il peut s’avérer nécessaire dans cette seconde situation de prouver la corrélation entre ces jetons.




Figure – Rôles étendus du méta-système.

Au-delà de ces principes fondateurs, abordons à présent la diversité des protocoles (et des jetons de sécurité à embrasser) avant d’illustrer dans un second temps au travers d’un certain nombre de scénarios concrets combien il est facile de participer au méta-système d’identités quelle que soit la plateforme ou la technologie utilisée.

La mise en œuvre des produits et technologies Microsoft sera mise en perspective dans ce cadre à la section § c Scénarios de mise en œuvre.
  1   2   3   4   5   6   7   8   9   10

similaire:

C. Scénarios de mise en œuvre 27 iconC. Scénarios de mise en œuvre 27

C. Scénarios de mise en œuvre 27 iconScénarios relatifs au service Web de mise à jour des appareils 13

C. Scénarios de mise en œuvre 27 iconCalendrier de mise en œuvre 14

C. Scénarios de mise en œuvre 27 icon"Mise en œuvre de Cisco Unified Communication Manager"

C. Scénarios de mise en œuvre 27 iconScénario pédagogique. Pour de Lièvre, Quintin & Depover (2002), IL...
«activités», «tâches», «scénarios», …, se posent des questions de «granularité», de mise en scène et d’architecture

C. Scénarios de mise en œuvre 27 iconPrincipes et conditions de mise en œuvre du protocole enum en France

C. Scénarios de mise en œuvre 27 iconLa mise en œuvre de la prime d’activité : un enjeu pour la Branche Famille

C. Scénarios de mise en œuvre 27 iconThierry brugvin lipha, Paris Est la difficile mise en œuvre

C. Scénarios de mise en œuvre 27 iconMéthodologie de mise en œuvre et problèmes posés par la première application de la réforme 2005

C. Scénarios de mise en œuvre 27 iconLa mise en œuvre d’une «mixité sociale» dans le parc hlm de la ville de Martigues








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com