Partager via

Fédération des identités dans un monde de services web

  • Article

Copyright

 

© 2001-2003 International Business Machines Corporation, Microsoft Corporation. Tous droits réservés.

Résumé

Ce document décrit les problèmes liés à la gestion des identités fédérées et décrit une solution complète basée sur les spécifications des services Web décrites dans la feuille de route WS-Security et d’autres spécifications de services Web associées.

L’approche décrite dans ce livre blanc, qui sera définie plus en détail dans la spécification WS-Federation, introduit un fournisseur d’identité en tant que classe de service de jeton de sécurité. En tant que tel, il utilise les mécanismes de WS-Trust et de WS-Federation pour créer et négocier une confiance au sein des fédérations et entre elles. En outre, des mécanismes sont définis pour l’authentification unique et la déconnexion, le partage d’attributs en fonction des stratégies d’autorisation et de confidentialité, ainsi que le traitement intégré des pseudonymes (alias utilisés sur différents sites/fédérations).

Ensemble, les spécifications identifiées dans ce document fournissent un ensemble complet et intégré de protocoles pour sécuriser les messages traités fiables dans et entre les fédérations en les composant avec d’autres spécifications de sécurité et de service Web.

Résumé

Au cours des dernières années, les applications web sont passées d’applications de distribution de contenu simples à des outils de productivité métier sophistiqués et à un mécanisme d’intégration d’applications au sein et entre les entreprises. La croissance des services Web et Web a démontré la nécessité de trouver des solutions ouvertes et interopérables à de nombreux problèmes techniques.

Dans ce document, nous nous concentrons sur un ensemble spécifique de problèmes liés à la sécurité. notamment :

Comment pouvons-nous déterminer les services web d’identité et de localisation sécurisés appropriés : les organisations ont besoin d’un moyen standard pour les demandeurs de services (clients et partenaires) de trouver en toute sécurité les services Web appropriés d’une entreprise donnée, et pour les fournisseurs de services professionnels, d’identifier et d’exposer en toute sécurité le service Web approprié aux seuls demandeurs autorisés.

Comment déterminer l’ensemble des informations d’identification pour activer l’appel sécurisé des services web : un moyen standardisé permettant aux demandeurs de services d’entreprise d’appeler de manière sécurisée les services web avec l’ensemble d’authentification, d’autorisation et de droits appropriés.

Comment fédérer en toute sécurité les services Web : moyen standard permettant aux entreprises de fournir directement des services aux clients inscrits auprès d’autres entreprises ou institutions (partenaires). Au sein d’une fédération de services, une entreprise peut obtenir des informations fiables sur un utilisateur à partir du organization d’origine de l’utilisateur (ou du service fournissant des informations). L’entreprise n’a pas besoin d’inscrire et de conserver l’identité de cet utilisateur, et l’utilisateur n’a pas besoin d’obtenir et de mémoriser une nouvelle connexion pour interagir avec l’entreprise.

Comment activer l’approbation inter-entreprises et inter-domaines : un moyen standard d’établir et de refléter la confiance entre les organisations. Il s’agit d’un problème clé pour les services fédérés.

Comment activer le mappage d’identités fédérées et d’attributs : mécanismes et procédures bien compris pour mapper des informations approuvées sur un utilisateur étranger (par exemple, des utilisateurs de partenaires commerciaux) dans des informations d’authentification et d’autorisation utilisables par les services existants d’une entreprise.

Comment activer des transactions sécurisées et fiables : un moyen standard d’échanger des messages dans un contexte sécurisé, fiable et traité. Les spécifications précédentes (par exemple, WS-ReliableMessaging et WS-Transaction) prennent en charge l’échange de messages fiable et les transactions commerciales. Dans ce document, nous abordons la prise en charge de la sécurité fédérée.

IBM, Microsoft et nos partenaires ont l’intention de travailler avec les clients, les partenaires et les organismes de normalisation pour faire évoluer les spécifications décrites ici, et pour s’assurer que ces spécifications s’intègrent bien avec d’autres éléments de l’architecture des services Web. Pour garantir l’interopérabilité et l’implémentation cohérente des différentes spécifications proposées décrites dans ce document, IBM, Microsoft et nos partenaires travailleront en étroite collaboration avec les organismes de normalisation, la communauté des développeurs et les organisations du secteur, telles que WS-I.org pour développer des profils d’interopérabilité et des tests qui fourniront des conseils aux fournisseurs d’outils.

Étant donné que la terminologie varie d’une technologie à l’autre, ce document définit plusieurs termes qui peuvent être appliqués de manière cohérente dans les différents formats et mécanismes de sécurité. Par conséquent, la terminologie utilisée ici peut être différente des autres spécifications et est définie de sorte que le lecteur puisse mapper les termes à son vocabulaire préféré. Reportez-vous à l'applet de commande Section terminologie pour un résumé de ces termes, ainsi que leur définition et leur utilisation.

1 Introduction et motivation

La gestion des identités fédérées représente un défi important pour les particuliers et les entreprises. Ce chapitre explore le problème, puis identifie les parties concernées et se termine par des objectifs clés pour des solutions viables.

Qu’est-ce que le problème de gestion des identités fédérées ?

Le réseau de valeurs d’une entreprise s’étend sur de nombreuses organisations, systèmes, applications et processus métier. Plusieurs composants différents composent ce réseau de valeur, notamment les clients, les employés, les partenaires, les fournisseurs et les distributeurs. Il n’existe aucune entité ou entreprise unique qui puisse prétendre gérer ou contrôler de manière centralisée les informations d’identité relatives à ses composants dans ce réseau de valeur de bout en bout. Même au sein d’une même entreprise, il peut exister plusieurs sources faisant autorité de données d’identité qui doivent être gérées de manière indépendante et autonome au sein des unités commerciales.

Cette approche de la centralisation en tant que principe sous-jacent de la collaboration inter-entreprise introduit des frictions importantes dans la collaboration, l’intégration et l’automatisation de l’e-business, ce qui entraîne des coûts élevés de gestion des identités et une réduction de l’efficacité. Avec la centralisation, le coût de gestion du cycle de vie des identités utilisateur est très élevé. La plupart des entreprises doivent gérer les identités des employés, des partenaires commerciaux et des clients. En outre, les relations entre l’entreprise et ces personnes changent assez fréquemment, et chaque changement nécessite une action administrative.

Dans certains cas, les entreprises aimeraient sous-traiter certaines fonctions de sécurité à des parties qui gèrent l’identité (comme elles le font aujourd’hui à des sociétés carte de crédit dans des contextes transactionnels), mais elles ne peuvent pas le faire pour deux raisons : premièrement, il n’existe aucun fournisseur d’identité tiers qui dessert des marchés autres que les transactions financières des consommateurs, et deuxièmement, il n’existe aucun modèle d’entreprise et de responsabilité qui permet de s’appuyer sur les services d’un fournisseur d’identité tiers pour les services de services. autres que les transactions financières des consommateurs.

D’autres entreprises souhaitent tirer parti des identités qu’elles conservent pour permettre des interactions métier supplémentaires. Toutefois, il est difficile d’établir les mécanismes d’approbation pour permettre aux entités d’être fédérées au-delà des frontières de l’entreprise. En outre, les entreprises qui gèrent l’identité sont de plus en plus exposées au risque d’atteinte à leur réputation ou de responsabilité réglementaire si leurs actions de gestion des identités publient ou utilisent des informations d’une manière qui entre en conflit avec les droits individuels à la vie privée. Cela augmente considérablement le risque de gestion de l’identité.

Du point de vue d’un individu, il existe plusieurs identités, personnelles et professionnelles. L’individu a également un problème de gestion des identités dû à l’incapacité de réutiliser les identités.

La gestion fédérée des identités offre une flexibilité inter-entreprise tout en permettant aux entreprises de décharger et de simplifier les coûts de gestion des identités. Cela permet aux entreprises de poursuivre des objectifs d’intégration métier qui s’alignent le mieux sur leur modèle d’entreprise, leur stratégie informatique et leurs objectifs et exigences en matière de sécurité et de gouvernance.

Qui a le problème de gestion des identités fédérées ?

La barrière d’intégration main réside dans l’intégration inter-entreprise en raison de l’absence de modèles de communication sécurisés. Le problème touche un large éventail d’entreprises, notamment :

  • Moyennes et grandes organisations qui utilisent les informations d’identité pour fournir des services aux consommateurs (par exemple, les fournisseurs de services de voyage basés sur le Web).
  • Les moyennes et grandes organisations qui font affaire entre elles et qui ont besoin d’échanger des informations sur l’identité des individus (par exemple, une compagnie aérienne et une agence de location de voitures, ou un hôpital et un fournisseur d’assurance maladie)
  • Les organisations qui ont besoin d’intégrer des applications métier au sein de l’entreprise et de la chaîne de valeur des clients et des fournisseurs (par exemple, une chaîne d’approvisionnement) et doivent autoriser leurs employés à effectuer des transactions pour le compte du organization.
  • Les organisations qui sous-traitent des services, tels que les ressources humaines et les avantages sociaux, à des tiers, mais qui appliquent leurs propres marques à ces services externalisés (par exemple, un organization qui fournit à ses employés plusieurs options de plan de retraite ou de plan médical via son propre portail RH interne) et qui doivent donc partager les informations d’identité des employés avec les fournisseurs de services.
  • Organisations (intermédiaires, courtiers, agrégateurs) dont le modèle d’entreprise est piloté par la « propriété de l’expérience client » pour des raisons de désintermédiation.
  • Organisations qui fournissent des portails d’entreprise intégrés basés sur l’identité à service complet (services financiers, services d’assurance, abonnement, etc.) en agrégeant des services entre plusieurs fournisseurs tiers.

Comme indiqué précédemment, les personnes qui participent à des activités web souffrent également de ce problème, car elles ont généralement un grand nombre d’identités indépendantes qu’elles doivent créer et gérer.

Objectifs

Les principaux objectifs de Federated Identity Services sont les suivants :

  • Réduire le coût de la gestion des identités en réduisant la duplication des efforts ; l’identité de chaque individu est presque toujours gérée par un organization de confiance (par exemple, sa banque, son employeur ou son médecin).
  • Tirez parti du travail que ces gestionnaires d’identité existants ont déjà effectué en donnant à d’autres parties l’accès (selon les besoins et avec une protection appropriée de la confidentialité) aux informations d’identité pertinentes.
  • Préserver l’autonomie de toutes les parties : le choix de la technologie d’authentification d’un responsable d’identité ne doit pas imposer cette technologie aux parties qui s’appuient sur ses informations d’identité. Le choix du système d’exploitation, du protocole réseau ou de la base de données d’un gestionnaire d’identités ne doit pas imposer le même choix à ses partenaires.
  • Respecter les contrats et les structures d’approbation préexistants de l’entreprise. L’inscription à la réception des informations d’identité d’un fournisseur d’identité ne doit pas nécessiter qu’un organization établisse une relation d’approbation avec une autre partie que le fournisseur d’identité et ne nécessite pas l’adoption d’une technologie d’authentification utilisateur spécifique.
  • Protéger la vie privée des individus en respectant et en appliquant fortement les préférences des utilisateurs qui régissent l’utilisation des informations d’identification individuelle, en respectant les règles de confidentialité gouvernementales et régionales, en demandant le consentement de l’utilisateur pour de nouvelles utilisations et en mettant en place des mécanismes solides de tenue de dossiers et de responsabilisation pour garantir le respect des pratiques de confidentialité.
  • S’appuyer sur des normes ouvertes pour permettre des transactions fiables sécurisées pour les entreprises et les particuliers.

2. Gestion des Authentification unique fédérés et des identités

L’attrait des fédérations est qu’elles sont destinées à permettre à un utilisateur de parcourir en toute transparence différents sites au sein d’une fédération donnée. Ce document se concentre spécifiquement sur la question de la gestion des identités fédérées et non sur la question plus importante de la fédération générale (au-delà de la sécurité). En raison des relations d’approbation établies entre les participants de fédération, un participant peut authentifier un utilisateur, puis agir en tant que partie émettrice pour cet utilisateur. Les autres participants à la fédération deviennent des parties de confiance. Autrement dit, ils s’appuient sur les informations fournies sur l’utilisateur par la partie émettrice, sans l’intervention directe de l’utilisateur. Dans certains cas, l’utilisateur peut être anonyme auprès de la partie de confiance, par exemple, en raison des différents mécanismes d’authentification et de l’utilisation de mécanismes d’authentification tiers.

La flexibilité et l’attrait du modèle des services web constituent sa base de base par laquelle les entreprises peuvent facilement créer de nouveaux services pour fournir des modèles d’affaires innovants ou lier plus efficacement leur réseau de chaîne de valeur grâce à des relations étroites avec des partenaires, des fournisseurs, des clients et des employés. Un tel modèle ne peut réussir que s’il permet aux clients, partenaires et utilisateurs finaux de naviguer facilement entre les sites Web prenant en charge ces services sans avoir à s’authentifier ou à s’identifier constamment aux différents sites, ni à conserver de manière redondante les informations personnelles de chaque membre au sein de la fédération d’entreprise.

Malheureusement, les schémas actuels d’authentification des utilisateurs et d’obtention d’informations sur les attributs utilisateur (par exemple, les informations de crédit carte) obligent généralement l’utilisateur à s’inscrire auprès de chaque entreprise qui l’intéresse, obligeant constamment l’utilisateur à s’identifier et à s’authentifier (généralement avec un nom d’utilisateur et un mot de passe) et forçant l’entreprise à administrer une base d’identités volumineuse et en évolution rapide qui ne sont pas sous le contrôle de l’entreprise. Un tel modèle est un obstacle majeur à l’adoption des services web et constitue un casse-tête pour les utilisateurs et les entreprises.

Un autre inconvénient du modèle prédominant est qu’une entreprise donnée peut ne pas « donner » une partie de ses informations client à un partenaire commercial, souhaitant plutôt maintenir et contrôler la relation client.

Les fédérations fournissent un mécanisme flexible simple pour identifier et valider les utilisateurs provenant d’organisations partenaires et leur fournir un accès transparent aux sites Web au sein de cette fédération approuvée sans nécessiter une nouvelle authentification avec un mot de passe. En outre, les normes de fédération traitent également de la fourniture d’attributs approuvés (par exemple, des certificats X509, des certificats d’attribut X509v3, des jetons Kerberos, des assertions SAML) sur les utilisateurs (par exemple, y compris les rôles et les informations de groupe) permettant des règles de confidentialité et spécifiques à l’entreprise.

Le concept et la notion de Authentification unique et d’identités fédérées peuvent être illustrés à l’aide d’un exemple simple :

L’utilisateur John Doe travaille pour une société pharmaceutique appelée Pharma456.com; John dispose d’un compte avec Pharma456.com et doit s’authentifier auprès de Pharma456.com pour accéder à ses ressources. En tant qu’employé, John a certains avantages avec l’entreprise, tels que les comptes et les services dans les entreprises partenaires. Dans cet exemple, les services d’épargne de l’entreprise sont gérés par un cabinet de services financiers appelé RetireAccounts.com (un fournisseur de services) et les services d’investissement sont gérés par une entreprise appelée InvestAccounts.com (un fournisseur de services). Pour accéder aux ressources d’un partenaire, par exemple le portail d’économies hébergé par RetireAccounts.com, un utilisateur doit s’authentifier auprès de RetireAccounts.com. L’authentification auprès de RetireAccounts.com nécessite qu’un utilisateur fournisse son numéro de sécurité sociale (SSN), un identificateur d’employé (un identificateur unique émis par l’employeur - dans ce cas Pharma456.com) et un numéro pin personnel (spécifique à RetireAccounts.com).

Sans fédération, John Doe doit s’authentifier explicitement auprès de RetireAccounts.com site pour accéder à son compte d’épargne, même s’il s’est déjà authentifié auprès de Pharma456.com et a accédé aux services web RetireAcounts.com via le portail des employés Pharma456.com.

Toutefois, avec l’authentification unique fédérée, John Doe peut se connecter au portail de son employé, cliquer sur un lien du portail pour accéder aux informations de son compte d’épargne à partir du site partenaire (RetireAccounts.com) et ne pas avoir à s’authentifier à nouveau ou à fournir des informations supplémentaires sur le site partenaire.

La fédération garantit également que les identités distinctes d’un même utilisateur d’une entreprise à l’autre peuvent être liées de manière sécurisée entre deux entreprises à l’aide de techniques de gestion fédérées. Les participants à la fédération peuvent échanger des informations d’identité afin que l’entreprise de confiance puisse valider indépendamment l’identité de l’utilisateur dans leur domaine.

L’authentification unique fédérée entre un domaine émetteur (Pharma456.com) et un domaine de confiance (le fournisseur de services fédérés RetireAccounts.com) facilite le transfert sécurisé et fiable d’identificateurs d’utilisateur et d’autres informations liées aux attributs (telles que les rôles d’autorisation et les appartenances aux groupes, et les droits d’utilisateur tels que EmployeeID, SSN et pin #). Federated Identity Management définit le processus par lequel la partie de confiance (RetireAccounts.com) peut déterminer un identificateur valide localement pour l’utilisateur en fonction des informations (approuvées) reçues de la partie émettrice. Les détails du transfert peuvent impliquer plusieurs messages entre l’entreprise et l’entreprise d’origine de l’utilisateur (et les messages aux services auxiliaires), mais ceux-ci sont gérés de manière transparente pour l’utilisateur.

Pour activer la fédération, nous introduisons des fournisseurs d’identité, des services d’attribut et des services de pseudonyme, qui sont illustrés dans la figure ci-dessus.

Les fournisseurs d’identité, tels que ceux Pharma456.com, InvestAccounts.com et RetireAccounts.com, fournissent des identités utilisées pour le mappage/l’indexation locale (par exemple, les informations de compte). En utilisant des mécanismes d’approbation et de fédération, ainsi que des stratégies d’approbation, ces identités permettent aux fédérations de partager et de mapper automatiquement des identités.

Les services d’attributs permettent de fédérer l’accès aux attributs autorisés pour les identités fédérées. Dans l’exemple ci-dessus, lorsque John Doe visite le portail de chaque partenaire, le service du portail peut accéder aux attributs de John (ceux auxquels il est autorisé) afin d’obtenir les informations requises et de personnaliser l’expérience. Pour garantir la confidentialité, John Doe a un contrôle total sur les attributs autorisés à quels services. Ces accès d’attributs peuvent être surveillés et consignés pour garantir la conformité aux stratégies de confidentialité établies avec Pharma456.com employés. Nous n’exigeons pas un type spécifique de service d’attribut, mais nous autorisons plutôt l’utilisation de différents services, tels que UDDI.

Les mécanismes d’approbation permettent aux parties de confiance d’associer un niveau de confiance à une autorité ou à une identité et de l’utiliser pour les mappages locaux. Toutefois, il existe des situations où des préoccupations en matière de confidentialité souhaitent que ce mappage soit opaque pour le service cible. Autrement dit, la cible sait toujours qu’il s’agit de « John Doe » basé sur le personnage local de John, mais ne comprend pas ou ne connaît pas l’identité globale. Les services de pseudonyme fournissent un mécanisme de mappage qui peut être utilisé pour faciliter ce mappage d’identités approuvées entre les fédérations afin de protéger la confidentialité et l’identité.

Federated Identity Management (y compris federated Authentification unique) est un concept beaucoup plus large que les solutions de Authentification unique web. Bien que cet exemple met en évidence un cas d’usage pour le scénario B2C, où l’authentification unique web est une fonctionnalité importante, Federated Authentification unique est un concept plus large qui permet aux entreprises de créer une infrastructure complète pour sécuriser les activités électroniques B2B et B2C.

3. Modèle d’identité fédérée

Le modèle d’identité fédérée s’appuie sur l’infrastructure et les spécifications de sécurité des services Web et les intègre pour former un modèle de sécurité cohérent et extensible. Le modèle de fédération étend le modèle WS-Trust pour décrire comment les fournisseurs d’identité agissent en tant que services de jeton de sécurité et comment les attributs et les pseudonymes peuvent être intégrés dans le mécanisme d’émission de jetons pour fournir des mécanismes de mappage d’identité fédérés.

En résumé, les principaux se connectent et se déconnectent des fournisseurs d’identité (ou des services de jeton de sécurité). Cela peut être effectué via des messages explicites ou implicitement en tant que jetons de demande de principaux. Un principal demande des jetons pour les ressources/services et les jetons émis peuvent représenter l’identité principale du principal ou un pseudonyme approprié pour l’étendue. Le fournisseur d’identité (ou STS) émet des messages aux destinataires intéressés (et autorisés). Les principaux sont inscrits auprès des services d’attribut/pseudonyme, et les attributs et pseudonymes sont ajoutés et utilisés. Les services peuvent interroger des services d’attribut/pseudonyme à l’aide des identités fournies (potentiellement anonymes, ce qui signifie que la partie qui demande les informations a un jeton opaque et n’a pas connaissance de l’identité réelle) pour obtenir des informations autorisées sur l’identité.

Spécifications Web Services Security

Le modèle et l’approche décrits dans ce document tirent parti des spécifications décrites dans le livre blanc Security in a Web Services World: A Proposed Architecture and Roadmap. Chacune des spécifications clés est résumée ci-dessous :

  • WS-Security décrit comment joindre des en-têtes de signature et de chiffrement aux messages SOAP. En outre, il explique comment attacher des jetons de sécurité, y compris des jetons de sécurité binaires tels que des certificats X.509 et des tickets Kerberos, aux messages.
  • WS-Policy représente un ensemble de spécifications qui décrivent les fonctionnalités et les contraintes des stratégies de sécurité (et d’autres stratégies métier) sur les intermédiaires et les points de terminaison (par exemple, jetons de sécurité requis, algorithmes de chiffrement pris en charge, règles de confidentialité) et comment associer des stratégies aux services et aux points de terminaison.
  • WS-Trust décrit une infrastructure pour les modèles d’approbation qui permet aux services Web d’interagir en toute sécurité en demandant, en émettant et en échangeant des jetons de sécurité.
  • WS-Privacy décrit un modèle pour la façon dont les services web et les demandeurs indiquent les préférences de confidentialité et les énoncés de pratiques de confidentialité de l’organisation.
  • WS-SecureConversation décrit comment gérer et authentifier les échanges de messages entre les parties, y compris les échanges de contexte de sécurité et l’établissement et la dérivation de clés de session.
  • WS-Federation décrit comment gérer et répartir les relations d’approbation dans un environnement fédéré hétérogène, notamment la prise en charge des identités fédérées, le partage d’attributs et la gestion des pseudonymes.
  • WS-Authorization décrit comment gérer les données d’autorisation et les stratégies d’autorisation.

En outre, plusieurs autres spécifications de services Web clés complètent la couche de base des spécifications :

  • WS-Addressing décrit comment spécifier des informations d’identification et d’adressage pour les messages.
  • WS-MetadataExchange décrit comment échanger des métadonnées telles que des informations WS-Policy et WSDL entre les services et les points de terminaison.
  • WS-ReliableMessaging décrit comment garantir une remise fiable des messages en présence de réseaux non fiables.
  • WS-Transactions et WS-Coordination décrivent comment activer les opérations traitées dans le cadre d’échanges de messages de service Web.

La combinaison des spécifications ci-dessus et des profils d’interopérabilité permet aux clients de créer facilement des services Web transactionnés sécurisés et interopérables qui s’intègrent dans et entre les fédérations en composant des spécifications de fédération et de sécurité avec d’autres spécifications de services Web.

Profils

Cet article décrit un modèle général qui peut être utilisé dans différents environnements. Plus précisément, ce modèle peut être utilisé dans des environnements constitués de demandeurs passifs tels que les navigateurs Web ou de demandeurs actifs tels que les demandeurs SOAP.

Les spécifications de fédération fournissent un modèle et un framework généraux ; les profils décrivent comment le modèle est appliqué dans ces différents environnements. Des profils supplémentaires peuvent être spécifiés pour l’intégration du modèle dans d’autres environnements.

Chaque spécification de profil définit la façon dont les mécanismes dans WS-Federation sont appliqués, le cas échéant, à un environnement donné, tel que les demandeurs passifs ou actifs.

Par conséquent, les mécanismes décrits dans ce document (fournisseurs d’identité, connexion/sortie, jetons de sécurité, attributs, pseudonymes, . . ) s’appliquent à la fois aux demandeurs passifs (tels que les navigateurs Web) et aux demandeurs actifs (tels que les services Web agissant à la fois en tant que clients et services), ainsi qu’à d’autres profils qui peuvent être définis à l’avenir.

Identity Providers

La fédération commence par une notion d’identité. Autrement dit, le demandeur ou le délégué du demandeur (un fournisseur d’identité qui est le propriétaire faisant autorité pour ces données d’identité) affirme une identité et le fournisseur d’identité vérifie cette assertion. La fédération devient alors une fonction d’approbation (directe, répartie et déléguée) entre les fournisseurs d’identité et ceux qui s’appuient sur la détermination de l’identité du fournisseur. Parfois, la partie de confiance a besoin de pouvoir mettre en corrélation les identités de plusieurs fournisseurs, par exemple, la corrélation d’une identité sur un case activée, sur un crédit carte et sur un permis de conduire.

Un service de jeton de sécurité (STS) est un service générique qui émet/échange des jetons de sécurité à l’aide d’un modèle commun et d’un ensemble de messages. Par conséquent, n’importe quel service Web peut, lui-même, être un STS simplement en prenant en charge la spécification WS-Trust. Par conséquent, il existe différents types de services de jeton de sécurité qui fournissent différents services supplémentaires. Un fournisseur d’identité (IP) est un type spécial de service de jeton de sécurité qui, au minimum, effectue l’authentification d’entité homologue et peut faire des revendications d’identité ou d’affiliation dans les jetons de sécurité émis. Notez que dans de nombreux cas, une adresse IP et un STS sont interchangeables et de nombreuses références dans ce document identifient les deux.

Le modèle de fédération s’appuie sur le framework défini dans WS-Trust en tirant parti du mécanisme d’émission et d’échange de jetons pour inclure l’émission et la fédération des identités.

L’exemple suivant illustre une combinaison possible d’une adresse IP et d’un STS pour accéder à un service. Dans cet exemple, (1) un demandeur obtient un jeton de sécurité d’identité à partir de son adresse IP (Business456.com), puis présente/fournit l’assertion (jeton de sécurité) au STS pour Fabrikam123. Si Fabrikam123.com approuve Business456.com et que l’autorisation est approuvée, le service STS retourne un jeton d’accès au demandeur. Le demandeur (3) utilise ensuite le jeton d’accès sur les demandes de Fabrikam123.com.

Dans cet exemple, la réponse de l’étape 1 est signée par Business456.com (l’adresse IP approuvée) et le jeton de sécurité retourné dans la réponse est relatif à Fabrikam123.com (par exemple, ils l’ont émis).

Un autre modèle, décrit ci-dessous, permet au service Fabrikam123.com d’inscrire un jeton de sécurité auprès d’un service de pseudonyme et d’extraire ce pseudonyme si nécessaire. Cela permet au service de gérer le mappage tout en fournissant un niveau de confidentialité pour le demandeur.

Authentification unique et Sign-Out

Le modèle décrit dans ce document et dans les spécifications WS-Federation permet d’utiliser différentes notions de sessions utilisateur , telles que le service géré et le demandeur. La création et la gestion des cookies au sein d’une session de navigateur Web sont un exemple de session gérée par le service. Un exemple de session gérée par le demandeur est un demandeur de service Web qui obtient un jeton et l’utilise pendant un certain temps, puis ignore le jeton avant son expiration. Les notions de déconnexion sont introduites pour permettre à différents profils de spécifier la façon dont ces transitions s’appliquent à chaque profil.

L’objectif de Authentification unique est d’établir les jetons de sécurité nécessaires pour accéder à une ressource dans le web de domaines/domaines fédérés. De même, la déconnexion fédérée est utilisée pour propre tous les jetons d’état et de sécurité mis en cache qui peuvent exister au sein de la fédération. Pour ce faire, des mécanismes sont nécessaires pour fournir des messages de connexion fédérée et de déconnexion émis par le fournisseur d’identité aux parties autorisées des actions de connexion et de déconnexion (ce qui leur permet d’effectuer toutes les actions de configuration/nettoyage nécessaires).

Attributs et pseudonymes

Comme nous l’avons vu précédemment, il existe un désir de pouvoir obtenir des informations sur une identité (ou toute ressource fédérée), par exemple pour fournir un message d’accueil « hello » ou obtenir le code postal du demandeur pour personnaliser une expérience, et cela peut être fourni par un service d’attribut. Cette spécification permet d’utiliser différents types de services d’attributs, tels que UDDI.

Il est essentiel que ces informations soient régies par les règles d’autorisation et la sémantique de confidentialité. De même, on s’attend à ce que différents attributs soient partagés différemment et aient des degrés de confidentialité et de protection différents (par exemple, prénom et nom). Par conséquent, chaque expression d’attribut doit être en mesure d’exprimer sa propre stratégie de contrôle d’accès et la stratégie doit prendre en compte la ou les étendues associées et les principaux qui peuvent parler pour la ou les étendues. Par exemple, un utilisateur final (une personne) peut souhaiter configurer ce qui suit : « Mes services dans mon intranet peuvent avoir accès à mon nom de famille, tandis que d’autres services ne peuvent pas sans autorisation expresse de ma part ».

Un service d’attribut peut tirer parti des référentiels existants et peut fournir un certain niveau de organization ou de contexte. Dans l’espace de noms organisationnel, les principaux individuels sont enregistrés et un ensemble de propriétés d’attribut (essentiellement des paires nom/valeur où le nom est un nom de propriété de chaîne et la valeur est un élément XML) représenté en XML sont associés au principal.

Il est important de noter que chaque attribut peut avoir ses propres règles d’autorisation de sécurité et sa propre politique de confidentialité, ce qui permet aux principaux de contrôler qui et comment les informations sont divulguées.

Différents services d’attribut ont des fonctionnalités différentes qui sont exprimées dans leur document de stratégie.

Outre les services d’attributs, il peut également y avoir des services de pseudonyme. Un service de pseudonyme permet à un principal d’avoir différents alias sur des ressources/services différents ou dans des domaines/domaines différents. Certains fournisseurs d’identité utilisent des identités fixes dans leurs jetons de sécurité. Dans certains scénarios, il est souhaité de garantir l’anonymat des jetons ; les pseudonymes fournissent un mécanisme pour permettre cet anonymat. Il y a souvent un compromis de la facilité de gestion qui doit être déterminé par le principal (c’est-à-dire, plus il y a d’identités, plus le risque de problèmes de gestion est grand).

Il convient de noter que dans certains cas, les services d’attribut et de pseudonyme seront combinés et, dans certains cas, ils seront des services distincts.

Par exemple, un demandeur s’authentifie auprès de Business456.com avec son identité principale « Fred.Jones ». Cependant, à Fabrikam123.com, il est connu sous le nom de « Freddo ». Pour préserver l’anonymat, Business456.com pouvez émettre une identité différente chaque fois que Fred.Jones se connecte, apparaissant ainsi comme « anonyme », comme illustré à l’étape 3 de la figure ci-dessous. Fabrikam123.com pouvez définir « Freddo » comme nom local pour ce demandeur au Fabrikam123.com (étape 4) et faire en sorte que le service de pseudonyme, qui comprend le nom anonyme, fournisse le mappage à « Freddo ».

La prochaine fois que le demandeur se connecte à Business456.com’adresse IP (étape 1 ci-dessous), il peut recevoir un nouvel identificateur comme «XYZ321@Business456.com » (étape 2 ci-dessous). Étant donné que Business456.com’adresse IP a le mappage décrit ci-dessus, le service Web à Fabrikam123.com peut maintenant demander un pseudonyme pour XYZ321@Business456.com au Fabrikam123.com (étape 4 ci-dessous) et récupérer ce qu’ils ont défini précédemment - dans ce cas, il s’agit de «Freddo@Fabrikam123.com » (étape 5 ci-dessous).

Le service de pseudonyme est en mesure de le faire, car il a la possibilité de mapper «XYZ321@Business456.com » dans une identité connue à Business456.com qui lui a associé des pseudonymes pour différents domaines/domaines. Ce contre-mappage se produit en fonction d’une relation d’approbation entre l’adresse IP et le service de pseudonyme. De même, il existe une relation d’approbation entre la ressource et le service de pseudonyme (éventuellement démarré par l’adresse IP) qui permet à la ressource d’être autorisée à obtenir et à définir des pseudonymes.

Le fournisseur d’identité (ou STS) peut également fonctionner main dans la main avec le service de pseudonyme. Autrement dit, le demandeur demande à son fournisseur d’identité (ou STS) un jeton pour un domaine/domaine d’approbation ou une ressource/service d’approbation spécifié. Le STS recherche des pseudonymes et émet un jeton qui peut être utilisé au niveau de la ressource/du service spécifié, comme illustré ci-dessous :

Comme illustré, il existe un certain nombre d’approches différentes prises en charge dans ce modèle d’identité fédérée dans lesquelles les pseudonymes peuvent être utilisés pour aider à maintenir la confidentialité. Chacune a des caractéristiques de facilité de gestion et de confidentialité différentes, ce qui permet à chaque fournisseur et principal de choisir la solution appropriée pour répondre à ses exigences spécifiques.

4 Résumé

Dans ce document, nous proposons un modèle de fédération de services Web intégré qui permet aux parties d’émettre et de s’appuyer sur des informations provenant d’autres membres des fédérations et de négocier l’approbation et les attributs entre les fédérations de manière sécurisée qui maintient la confidentialité individuelle et professionnelle.

Ce modèle s’intègre à la sécurité des services Web et aux spécifications associées pour permettre des transactions fiables sécurisées entre les demandeurs et les services au sein et entre les fédérations.

IBM et Microsoft estiment qu’il s’agit d’une étape importante dans la définition d’une stratégie de sécurité complète des services Web.  Il reflète les défis et les solutions que nous avons identifiés jusqu’à présent. Alors que nous continuons à collaborer avec les clients, les partenaires et les organismes de normalisation pour sécuriser les services Web, nous nous attendons à ce qu’il y ait des idées et des spécifications supplémentaires nécessaires pour que la stratégie soit complète. 

Terminologie

Étant donné que la terminologie varie d’une technologie à l’autre, ce document définit plusieurs termes qui peuvent être appliqués de manière cohérente dans les différents formats et mécanismes de sécurité. Par conséquent, la terminologie utilisée ici peut être différente des autres spécifications et est définie de sorte que le lecteur puisse mapper les termes à son vocabulaire préféré.

Navigateur passif : un navigateur passif est un navigateur HTTP capable de prendre en charge http (par exemple, HTTP/1.1).

Demandeur actif : un demandeur actif est une application (éventuellement un navigateur Web) capable d’émettre des messages de services Web tels que ceux décrits dans WS-Security et WS-Trust.

Profil : un profil est un document qui décrit comment ce modèle est appliqué à une classe spécifique de demandeur (par exemple, passif ou actif).

Revendication : une revendication est une déclaration effectuée par une entité (par exemple, nom, identité, clé, groupe, privilège, fonctionnalité, attribut, etc.).

Jeton de sécurité : un jeton de sécurité représente une collection de revendications.

Jeton de sécurité signé : un jeton de sécurité signé est un jeton de sécurité qui est affirmé et signé par une autorité spécifique (par exemple, un certificat X.509 ou un ticket Kerberos)

Preuve de possession - La preuve de possession est des données d’authentification fournies avec un message pour prouver que le message a été envoyé et ou créé par une identité revendiquée.

Jeton de preuve de possession : un jeton de preuve de possession est un jeton de sécurité qui contient des données qu’un expéditeur peut utiliser pour démontrer la preuve de possession. En règle générale, bien que pas exclusivement, les informations de preuve de possession sont chiffrées avec une clé connue uniquement de l’expéditeur et des destinataires.

Digest : une synthèse est une somme de contrôle de chiffrement d’un flux d’octets.

Signature : une signature est une valeur calculée avec un algorithme de chiffrement et liée aux données de telle sorte que les destinataires prévus des données puissent utiliser la signature pour vérifier que les données n’ont pas été modifiées depuis leur signature par le signataire.

Service de jeton de sécurité (STS) : un service de jeton de sécurité est un service web qui émet des jetons de sécurité (voir WS-Security et WS-Trust). Autrement dit, elle fait des assertions basées sur des preuves qu’elle fait confiance à quiconque lui fait confiance. Pour communiquer l’approbation, un service nécessite une preuve, telle qu’un jeton de sécurité ou un ensemble de jetons de sécurité, et émet un jeton de sécurité avec sa propre instruction d’approbation (notez que pour certains formats de jeton de sécurité, il peut simplement s’agir d’une réédite ou d’une co-signature). Cela constitue la base du brokering d’approbation.

Service d’attribut : un service d’attribut est un service Web qui gère des informations (attributs) sur les principaux au sein d’un domaine ou d’une fédération d’approbation. Dans ce contexte, le terme principal peut être appliqué à n’importe quelle entité système, pas seulement à une personne.

Service de pseudonyme : un service de pseudonyme est un service web qui gère d’autres informations d’identité sur les principaux au sein d’un domaine d’approbation ou d’une fédération. Dans ce contexte, le terme principal peut être appliqué à n’importe quelle entité système, pas seulement à une personne.

Confiance - La confiance est la caractéristique selon laquelle une entité est prête à s’appuyer sur une deuxième entité pour exécuter un ensemble d’actions et/ou pour effectuer un ensemble d’assertions sur un ensemble de sujets et/ou d’étendues.

Domaine d’approbation : un domaine d’approbation est un espace de sécurité administré dans lequel la source et la cible d’une requête peuvent déterminer et convenir si des ensembles d’informations d’identification particuliers d’une source satisfont aux stratégies de sécurité pertinentes de la cible. La cible peut différer la décision d’approbation à un tiers, ce qui inclut le tiers de confiance dans le domaine d’approbation.

Service de validation : un service de validation est un service web qui utilise les mécanismes WS-Trust pour valider les jetons fournis et évaluer leur niveau de confiance (par exemple, les revendications approuvées).

Approbation - directeL’approbation directe se produit lorsqu’une partie de confiance accepte comme vraie toutes (ou une partie des) revendications dans le jeton envoyé par le demandeur.

Approbation - directe répartieL’approbation directe par brokered est lorsqu’une partie fait confiance à une autre partie qui, à son tour, fait confiance ou se porte garante des revendications d’un tiers.

Approbation - intermédiaire indirecteL’approbation négociée indirecte est une variante de la confiance négociée directe où la deuxième partie ne peut pas valider immédiatement les revendications du tiers à la première partie et négocie avec le tiers, ou des parties supplémentaires, pour valider les revendications et évaluer l’approbation du tiers.

Authentification des messages - L’authentification de message consiste à vérifier que le message reçu est identique à celui envoyé.

Authentification de l’expéditeur - L’authentification de l’expéditeur est une preuve d’authentification corroborée possiblement entre des acteurs/rôles de service Web indiquant l’expéditeur d’un message de service Web (et ses données associées). Notez qu’il est possible qu’un message ait plusieurs expéditeurs si des intermédiaires authentifiés existent. Notez également qu’il est dépendant de l’application (et hors de portée) quant à la façon dont il est déterminé qui a créé en premier les messages, car l’expéditeur de message peut être indépendant ou caché derrière un expéditeur authentifié.

Domaine ou domaine : un domaine ou un domaine représente une unité unique d’administration de la sécurité ou d’approbation.

Fédération : une fédération est une collection de domaines/domaines qui ont établi une approbation. Le niveau de confiance peut varier, mais inclut généralement l’authentification et peut inclure l’autorisation.

Fournisseur d’identité - Le fournisseur d’identité est une entité qui agit comme un service d’authentification d’entité homologue pour les utilisateurs finaux et un service d’authentification d’origine des données pour les fournisseurs de services (il s’agit généralement d’une extension d’un service de jeton de sécurité).

Authentification unique (SSO) - Authentification unique est une optimisation de la séquence d’authentification pour supprimer la charge des actions répétées placées sur l’utilisateur final. Pour faciliter l’authentification unique, un élément appelé fournisseur d’identité peut agir en tant que proxy au nom d’un utilisateur pour fournir des preuves d’événements d’authentification aux tiers qui demandent des informations sur l’utilisateur. Ces fournisseurs d’identité sont des tiers de confiance et doivent être approuvés à la fois par l’utilisateur (pour conserver les informations d’identité de l’utilisateur, car la perte de ces informations peut entraîner la compromission de l’identité des utilisateurs) et les services Web qui peuvent accorder l’accès à des ressources et des informations précieuses en fonction de l’intégrité des informations d’identité fournies par l’adresse IP.

Mappage des identités - Le mappage d’identité est une méthode permettant de créer des relations entre les propriétés d’identité. Certains fournisseurs d’identité peuvent utiliser le mappage d’id.

Déconnexion : une déconnexion est le processus par lequel les jetons de sécurité sont détruits pour un domaine ou une fédération.

Association - L’association est le processus par lequel les principaux deviennent associés ou affiliés à un domaine d’approbation ou à une fédération.

Contributeurs

Ce document a été rédigé conjointement par IBM et Microsoft.

Les contributions clés incluent (par ordre alphabétique) : Giovanni Della-Libera, Microsoft ; Brendan Dixon, Microsoft; Mike Dusche, Microsoft; Don Ferguson, IBM; Praerit Garg, Microsoft; Tim Hahn, IBM; Heather Hinton, IBM; Maryann Hondo, IBM; Chris Kaler, Microsoft; Frank Leymann, IBM; Brad Lovering, Microsoft; Hiroshi Maruyama, IBM; Anthony Nadalin, IBM; Nataraj Nagaratnam, IBM; Venkat Raghavan, IBM; John Shewchuk, Microsoft

Références

© 2001-2003 International Business Machines Corporation, . Tous droits réservés.

Il s’agit d’un document préliminaire qui peut être modifié sensiblement au fil du temps. Les informations contenues dans ce document représentent la vue actuelle d’International Business Machine et de Microsoft Corporation sur les questions abordées à la date de publication. Étant donné qu’IBM et Microsoft doivent répondre à l’évolution des conditions du marché, il ne doit pas être interprété comme un engagement de la part d’IBM et de Microsoft, et IBM et Microsoft ne peuvent pas garantir l’exactitude des informations présentées après la date de publication.

La présentation, la distribution ou toute autre diffusion des informations contenues dans ce document ne constitue pas une licence, ni expressément ni implicite, à une propriété intellectuelle détenue ou contrôlée par IBM ou Microsoft et/ou tout autre tiers.  IBM, Microsoft et/ou tout autre tiers peuvent avoir des brevets, des demandes de brevet, des marques, des droits d’auteur ou d’autres droits de propriété intellectuelle couvrant l’objet de ce document.  La fourniture de ce document ne vous accorde aucune licence sur les brevets, marques, droits d’auteur ou autres droits de propriété intellectuelle d’IBM ou de Microsoft ou d’autres tiers. Les noms de sociétés, d'organisations, de produits, de domaines, d'adresses de messagerie, de logos, de personnes, de lieux et d'événements mentionnés dans les exemples sont fictifs.  Toute ressemblance avec des noms ou des événements réels est purement fortuite et involontaire.

Ce document et les informations contenues dans le présent document sont fournis en l’état et dans la mesure maximale autorisée par la loi applicable, IBM et Microsoft fournissent le document TEL QUEL ET AVEC TOUTES LES ERREURS, et rejettent par la présente toutes les autres garanties et conditions, qu’elles soient expresses, implicites ou légales, y compris, mais sans s’y limiter, toutes les garanties (le cas échéant) implicites, les devoirs ou les conditions de qualité marchande, d’adéquation à un usage particulier, d’exactitude ou d’exhaustivité des réponses, de résultats, d’effort de travail, d’absence de virus et d’absence de négligence, tout cela à l’égard du document. EN OUTRE, IL N’EXISTE AUCUNE GARANTIE OU CONDITION DE TITRE, DE JOUISSANCE TRANQUILLE, DE POSSESSION TRANQUILLE, DE CORRESPONDANCE À DESCRIPTION OU DE NON-VIOLATION DE DROITS DE PROPRIÉTÉ INTELLECTUELLE À L’ÉGARD DU DOCUMENT.

EN AUCUN CAS IBM OU MICROSOFT NE SERONT TENUS RESPONSABLES ENVERS TOUTE AUTRE PARTIE DU COÛT DE L’ACHAT DE BIENS OU SERVICES DE SUBSTITUTION, DE LA PERTE DE PROFITS, DE LA PERTE D’UTILISATION, DE LA PERTE DE DONNÉES, OU DE TOUT DOMMAGE ACCESSOIRE, CONSÉCUTIF, DIRECT, INDIRECT OU SPÉCIAL, QU’IL S’AGISSE D’UN CONTRAT, D’UN DÉLIT, DÉLICTUEL, D’UNE GARANTIE OU D’UNE AUTRE MANIÈRE, DÉCOULANT DE QUELQUE MANIÈRE QUE CE SOIT DU PRÉSENT CONTRAT OU DE TOUT AUTRE CONTRAT RELATIF À CE DOCUMENT, SI CETTE PARTIE AVAIT OU NON ÉTÉ PRÉVENUE À L’AVANCE DE LA POSSIBILITÉ DE TELS DOMMAGES.