Interopérabilité de Federated Identity Management
Microsoft Corporation
Mai 2004
Résumé: À mesure que les entreprises étendent des systèmes internes à des utilisateurs externes, il est important de s’assurer que les systèmes peuvent interagir avec les applications d’autres organisations. Les principaux fournisseurs de solutions de gestion des identités ont présenté leurs solutions qui répondent à ce besoin dans un atelier récent sur l’interopérabilité. (7 pages imprimées)
Note Ce document décrit les résultats de cet atelier dans lequel les implémentations d’un scénario d’interopérabilité utilisant le profil de demandeur passif WS-Federation basé sur l’ensemble de normes de sécurité des services web ont été testées.
Contenu
Federated Identity Management
Ateliers sur le protocole des services web
Interopérabilité du profil de demandeur passif WS-Federation
Résultats et discussion de l’atelier
Liens associés
Federated Identity Management
Pour relever le défi des tendances actuelles du secteur, telles que la croissance du commerce interentreprises, l’augmentation de la mobilité et la nécessité d’une connectivité permanente, les organisations étendent les systèmes internes aux utilisateurs externes fournissant une connectivité aux clients, partenaires, fournisseurs et employés mobiles. Pour fournir une connectivité efficace et transparente, vous devez créer des relations « basées sur la confiance » qui permettent aux organisations de partager en toute sécurité les informations d’identité d’un utilisateur. Les relations d’approbation permettent aux informations d’identité et de stratégie de circuler entre les organisations indépendamment de la plateforme, de l’application ou du modèle de sécurité. Les relations d’approbation doivent être établies rapidement et efficacement pour optimiser la productivité et éliminer les processus manuels qui ont souvent lieu aujourd’hui. Federation décrit les dispositions technologiques et commerciales nécessaires à cette interconnexion.
Les systèmes fédérés doivent interagir au-delà des limites de l’organisation et connecter des processus à l’aide de différentes technologies, de stockage d’identités, d’approches de sécurité et de modèles de programmation. Dans un système fédéré, les identités et leurs informations d’identification associées sont toujours stockées, détenues et gérées séparément. Chaque membre individuel de la fédération continue de gérer ses propres identités, mais est capable de partager et d’accepter en toute sécurité les identités et les informations d’identification provenant des sources d’autres membres.
Au sein d’un système fédéré, un organization a besoin d’un moyen standardisé et sécurisé d’exprimer non seulement les services qu’il met à la disposition des partenaires et clients de confiance, mais également les stratégies par lesquelles elle gère son activité, telles que les autres organisations et utilisateurs auxquels elle fait confiance, les types d’informations d’identification et de demandes qu’elle accepte, et ses stratégies de confidentialité.
Pour répondre à ce besoin, Microsoft collabore avec les leaders du secteur pour développer un ensemble de spécifications pour l’architecture d’application distribuée communément appelée services web. L’architecture des services Web est basée sur des normes du secteur telles que SOAP, XML, WSDL et UDDI et fournit une base pour fournir des solutions métier complètes et interopérables pour l’entreprise étendue, y compris la possibilité de gérer l’identité et la sécurité fédérées. Le modèle de services Web repose sur l’idée que les systèmes d’entreprise sont écrits dans différents langages, avec différents modèles de programmation, qui s’exécutent sur et sont accessibles à partir de nombreux types d’appareils différents. Les services web sont un moyen indépendant de la plateforme et du langage de créer des systèmes distribués qui peuvent se connecter et interagir les uns avec les autres facilement et efficacement sur Internet. Pour plus d’informations sur les services Web et les spécifications des services Web, consultez le Centre de développement des services web MSDN.
Interopérabilité
La réussite de l’architecture des services Web et des applications qu’elle permet dépend de la capacité de ces applications à interagir avec un réseau approuvé d’entreprises, de partenaires et de services, quel que soit la plateforme, le langage de programmation ou l’application avec lequel elles interagissent. À cette fin, les entreprises qui implémentent des services Web souhaitent que leurs applications soient conformes aux normes des services Web pour garantir l’interopérabilité. Les normes de services web, notamment SOAP, XML, WSDL et UDDI, permettent aux développeurs de créer des solutions de service Web qui sont interopérables sur plusieurs plateformes, langages de programmation et applications. L’une des main façons de confirmer l’existence de cette interopérabilité, et le fait que les spécifications des services Web correspondent à ces objectifs métier, consiste à utiliser des ateliers d’interopérabilité de protocole.
Ateliers sur le protocole des services web
Les ateliers sur le protocole des services web permettent d’impliquer la communauté des services Web (y compris les entreprises d’utilisateurs finaux, les éditeurs de logiciels indépendants et d’autres fournisseurs) dans le processus de validation et d’affinement des spécifications WS-*. Il existe deux types d’ateliers : les commentaires et l’interopérabilité. Les ateliers de commentaires permettent à l’auteur de chaque protocole de services web de partager des informations générales sur la conception et de recevoir des commentaires des participants sur la pratique de l’implémentation. Les ateliers d’interopérabilité sont organisés pour les mêmes raisons et permettent en outre aux entreprises de tester l’interopérabilité de leur implémentation avec d’autres participants à l’atelier.
Une fois que tous les commentaires et les résultats de mise en œuvre ont été recueillis à partir des ateliers, les auteurs mettent à jour et affinent la spécification pour les soumettre à un organization d’établissement de normes.
atelier d’interopérabilité du profil de demandeur passif WS-Federation
Les 29 et 30 mars 2004, les auteurs de la spécification de profil de demandeur passif WS-Federation ont organisé un atelier d’interopérabilité de deux jours sur le campus Microsoft à Redmond, Washington.
L’atelier de deux jours était un forum ouvert pour les entreprises qui ont des implémentations basées sur la spécification WS-Federation publiée le 8 juillet 2003 et le WS-Federation Passive Requester Profile, également publié le 8 juillet 2003. Un document de scénario a été fourni avant l’événement et les participants ont été invités à tester leurs implémentations du scénario avec des implémentations d’autres entreprises. Les participants à l’atelier comprenaient IBM Corporation, Microsoft Corporation, Netegrity Inc., Oblix Inc., OpenNetwork Corporation, Ping Identity Corporation et RSA Security Inc. Vous trouverez plus d’informations sur cet atelier et d’autres ateliers sur le protocole des services web sur MSDN.
spécification WS-Federation
La spécification WS-Federation fait partie de l’ensemble de spécifications de sécurité des services web. Il définit un modèle et un ensemble de messages pour le répartiteur de l’approbation et la fédération des informations d’identité et d’authentification dans différents domaines d’approbation.
La spécification WS-Federation identifie deux sources de demandes d’identité et d’authentification dans les domaines d’approbation : les demandeurs actifs, tels que les applications soap, et les demandeurs passifs définis en tant que navigateurs HTTP capables de prendre en charge HTTP à grande échelle (par exemple, HTTP 1.1).
profil de demandeur passif WS-Federation
Le profil de demandeur passif WS-Federation est une implémentation de WS-Federation et propose un protocole standard pour la façon dont les demandeurs passifs (tels que les navigateurs Web) appliquent l’infrastructure de fédération. Dans ce protocole, les demandeurs de services Web sont censés comprendre les nouveaux mécanismes de sécurité et être capables d’interagir avec les fournisseurs de services Web.
Interopérabilité du profil de demandeur passif WS-Federation
profil d’interopérabilité du demandeur passif WS-Federation
Le profil d’interopérabilité du demandeur passif WS-Federation est une contrainte supplémentaire sur le profil de demandeur passif dans le but de fournir davantage de garanties d’interopérabilité. Le profil définit une norme pour la demande, l’échange et l’émission de jetons de sécurité dans le contexte d’un demandeur passif utilisant SAML (Security Assertion Markup Language) comme type de jeton.
Le profil d’interopérabilité du demandeur passif WS-Federation a été créé et distribué aux participants avant l’atelier comme guide de création d’implémentations interopérables du profil de demandeur passif WS-Federation. Pour tester le protocole recommandé, les fournisseurs ont collaboré à la création d’un scénario d’implémentation. Ce scénario reflète le besoin courant pour les organisations d’externaliser des services, tels que des avantages, à des tiers, mais de fournir un accès personnalisé au service par le biais d’un site Web interne (le demandeur passif dans ce scénario).
Scénario d’interopérabilité
Dans le scénario de l’atelier d’interopérabilité, une entreprise, My Employer (ME), externalise la gestion des avantages sociaux des employés à un tiers, Benefits Company (BC). Mon employeur et ma compagnie d’avantages sociaux ont établi des fiducies et des politiques pour une fédération d’entreprise. Dans le cadre de la coordination de sa fédération commerciale avec Benefits Company, Mon employeur accepte d’envoyer certains attributs spécifiques à l’utilisateur, ainsi que la demande de ressource à Benefits Company. L’application de gestion des avantages sociaux sur Benefits Company exige que ces attributs existent avant d’afficher la ressource spécifique demandée par l’employé de Mon employeur.
L’objectif de ce scénario était triple :
- Illustrer une fédération interentreprises entre un organization et un fournisseur de services tiers en permettant à ME d’externaliser la gestion des avantages sociaux des employés.
- Testez l’interopérabilité entre les différentes solutions de fournisseurs créées à l’aide des normes décrites dans le profil de demandeur passif WS-Federation.
- Bénéficiez de l’avantage d’une fédération d’entreprise en :
- Élimination de la nécessité pour BC de gérer l’identité et les mots de passe pour les employés d’ME afin d’administrer les avantages.
- Fournir une Authentification unique Web approuvée (SSO) pour les employés me au domaine BC.
Procédure pas à pas du scénario
Un employé me est au travail et accède à une page du portail d’avantages sociaux interne. Si l’employé ne s’est pas encore connecté à son domaine chez ME, il doit le faire avant de pouvoir accéder à la page du portail des avantages. La page du portail des avantages affiche des informations pertinentes pour l’utilisateur individuel, ou me lui-même, et contient des liens pour gérer les avantages de l’utilisateur.
L’employé clique sur le lien de gestion des avantages et est authentifié auprès de l’entreprise d’avantages à l’aide des informations d’identification précédemment fournies pour l’authentification sur la page du portail des avantages ME.
L’application de gestion des avantages sociaux présente à l’employé une « page d’accueil » personnalisée qui fournit des informations personnalisées sur les choix d’avantages sociaux de l’employé.
Ici, une implémentation d’application d’avantages réels permettrait à un employé de mettre à jour ses options de plan d’intégrité et de cliquer sur un lien pour gérer son plan d’intégrité. L’employé se voit montrer les différentes options de régime d’assurance-santé disponibles et le coût de chaque plan. L’employé sélectionne un nouveau plan de santé et affiche le nouveau montant à déduire de chaque chèque de paie. L’employé est invité à confirmer cette transaction.
L’employé confirme sa sélection et retourne à la « page d’accueil » personnalisée qui affiche désormais les informations mises à jour sur le plan d’intégrité.
Si l’employé clique à nouveau sur le lien vers son plan de santé, il affiche les détails du plan d’intégrité qu’il a choisi et a la possibilité de modifier son choix avant la fin de la période d’inscription.
Une fois la transaction terminée, l’employé clique sur un lien de déconnexion sur le site de la Colombie-Britannique et est transféré vers un portail interne à ME qui affiche la confirmation que l’employé a été déconnecté de l’application Benefit Company.
Résultats et discussion de l’atelier
L’atelier d’interopérabilité du profil de demandeur passif WS-Federation a montré des niveaux élevés d’interopérabilité entre toutes les implémentations de tous les fournisseurs participants, ce qui a été réalisé beaucoup plus rapidement que prévu et avec moins de problèmes, ce qui est un signe clair de la maturité croissante de ces implémentations.
Les clients qui implémentent des services Web aujourd’hui veulent savoir que leurs applications sont conformes aux normes existantes et qu’elles sont capables d’interopérabilité avec d’autres produits prenant en charge les services Web. Les implémentations du scénario d’interopérabilité testées lors de l’atelier ont démontré l’interopérabilité entre toutes les solutions des fournisseurs.
La fourniture d’un modèle complet, cohérent et extensible pour les services Web et Federated Identity Management nécessite des efforts coordonnés de la part des fournisseurs de plateformes, des développeurs d’applications, des fournisseurs de réseaux et d’infrastructure et des clients. Des événements tels que le récent atelier d’interopérabilité du profil de demandeur passif WS-Federation favorisent une large participation du secteur à l’évolution des normes de services Web et garantissent que les clients, les développeurs et les fournisseurs disposent de protocoles éprouvés pour créer des services Web cohérents, fiables et interopérables entre les plateformes, les applications et les langages de programmation.
L’interopérabilité est, et continuera d’être, un facteur croissant dans les décisions des clients concernant les implémentations de services Web. Pour prendre en charge l’interopérabilité dans l’implémentation des services Web, Microsoft recommande :
- Suivez les protocoles d’implémentation des services Web établis. Vous trouverez des spécifications de services web et une prise en charge supplémentaire pour le développement et l’implémentation de services Web dans le Centre de développement des services Web MSDN.
- Participez aux prochains ateliers sur les commentaires et l’interopérabilité des services web. Cliquez pour obtenir plus d’informations sur l’atelier.
- Familiarisez-vous avec les directives d’interopérabilité WS-I. Vous trouverez plus d’informations sur les instructions et d’autres ressources de développement WS-I à l’adresse http://www.ws-i.org/.
- Utilisez les outils de test WS-I pour vérifier que votre application de services Web est conforme aux directives d’interopérabilité WS-I.
L’ensemble de spécifications de sécurité des services web fournit une solution complète pour Federated Identity Management permettant une communication et une collaboration sécurisées et efficaces entre les organisations et les utilisateurs externes. La création de solutions interopérables basées sur les normes de sécurité WS accélérera davantage l’adoption de Federated Identity Management et permettra aux clients d’implémenter des solutions de services web avec des coûts d’implémentation et des risques réduits.
Liens associés
Pour plus d’informations, consultez les ressources suivantes :
- Solutions de gestion des identités et des accès Microsoft
- Page d’index spécifications de sécurité des services web sur MSDN
- Security in a Web Services World: A Proposed Architecture and Roadmap (livre blanc), version 1.0, avril 2002, International Business Machines Corporation et Microsoft Corporation
- Spécification WS-Federation Language (WS-Federation), version 1.0, juillet 2003, International Business Machines Corporation, Microsoft Corporation, BEA Systems, Inc., RSA Security, Inc., et VeriSign, Inc.
- Federation of Identities in a Web Services World (livre blanc), juillet 2003, International Business Machines Corporation et Microsoft Corporation
- WS-Federation: Passive Requestor Profile Specification, version 1.0, juillet 2003 version 1.0, International Business Machines Corporation, Microsoft Corporation, BEA Systems, Inc., RSA Security, Inc., et VeriSign, Inc.
- WS-Federation Passive Requestor Interoperability Profile (télécharger), février 2004, version 0.4, International Business Machines Corporation et Microsoft Corporation
- Secure, Reliable, Transacted Web Services: Architecture and Composition (livre blanc), septembre 2003, International Business Machines Corporation et Microsoft Corporation
- Ateliers sur le protocole des services web
- Liste de diffusion WS-Security-Workshops
- Centre de développement MSDN Web Services
- Organisation d’interopérabilité des services web (WS-I)
- Spécification SAML (Security Assertions Markup Language), novembre 2002, version 1.0
© 2004 Microsoft Corporation. Tous droits réservés.
Il s’agit d’un document préliminaire qui peut être modifié considérablement au fil du temps. Les informations contenues dans le présent document reflètent l'opinion de Microsoft Corporation sur les sujets abordés à la date de publication. Étant donné que Microsoft doit répondre à l’évolution des conditions du marché, il ne doit pas être interprété comme un engagement de la part de Microsoft et Microsoft ne peut 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 constituent pas une licence, expresse ou implicite, à toute propriété intellectuelle détenue ou contrôlée par Microsoft et/ou tout autre tiers. Microsoft et/ou tout autre tiers peuvent avoir des brevets, des demandes de brevets, des marques commerciales, des droits d’auteur ou d’autres droits de propriété intellectuelle couvrant le sujet de ce document. La fourniture de ce document ne vous accorde aucune licence sur les brevets, marques commerciales, droits d’auteur ou autres droits de propriété intellectuelle 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.
Le présent 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, Microsoft fournit le document TEL QUEL ET AVEC TOUTES LES FAUTES, et décline par la présente toutes autres garanties et conditions, expresses, implicites ou légales, y compris, mais sans s’y limiter, toute garantie (le cas échéant) implicite, obligations ou conditions de qualité marchande, d’adéquation à un usage particulier, d’exactitude ou d’exhaustivité des réponses, de résultats, d’effort professionnel, d’absence de virus et d’absence de négligence, le tout en ce qui concerne le document. EN OUTRE, IL N’Y A PAS DE GARANTIE OU DE CONDITION DE TITRE, DE JOUISSANCE TRANQUILLE, DE POSSESSION SILENCIEUSE, DE CORRESPONDANCE À LA DESCRIPTION OU DE NON-VIOLATION DE DROITS DE PROPRIÉTÉ INTELLECTUELLE À L’ÉGARD DU DOCUMENT.
EN AUCUN CAS, MICROSOFT NE SERA RESPONSABLE ENVERS UNE AUTRE PARTIE DU COÛT DE L’ACHAT DE BIENS OU SERVICES DE SUBSTITUTION, DES PERTES DE PROFITS, DE LA PERTE D’UTILISATION, DE LA PERTE DE DONNÉES OU DE TOUT DOMMAGE ACCESSOIRE, INDIRECT, DIRECT, INDIRECT OU SPÉCIAL, QU’IL S’AGISSE D’UN CONTRAT, DÉLICTUEL, DÉLICTUEL, DE GARANTIE OU AUTRE, DÉCOULANT DE QUELQUE MANIÈRE QUE CE SOIT DU PRÉSENT OU DE TOUT AUTRE CONTRAT RELATIF AU PRÉSENT DOCUMENT, SI CETTE PARTIE AVAIT ÉTÉ AVISÉE À L’AVANCE DE LA POSSIBILITÉ DE TELS DOMMAGES.
Microsoft et Microsoft Web Services sont des marques déposées ou des marques déposées de Microsoft Corporation dans le États-Unis et/ou dans d’autres pays.
Les noms des sociétés et des produits mentionnés dans le présent document peuvent être des marques de leurs propriétaires respectifs.