Partager via

Sécurité dans un monde de services web : architecture et feuille de route proposées

  • Article

 

7 avril 2002
Version 1.0

© 2001-2002 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.

Résumé

Ce document décrit une stratégie proposée pour traiter la sécurité au sein d’un environnement de service Web. Il définit un modèle de sécurité de service Web complet qui prend en charge, intègre et unifie plusieurs modèles, mécanismes et technologies de sécurité populaires (y compris les technologies symétriques et à clé publique) de manière à permettre à divers systèmes d’interagir de manière sécurisée de manière indépendante de la plateforme et du langage. Il décrit également un ensemble de spécifications et de scénarios qui montrent comment ces spécifications peuvent être utilisées ensemble.

Résumé

L’industrie informatique parle de services web depuis près de deux ans. Les avantages d’une méthode faiblement couplée, indépendante de la langue et indépendante de la plateforme pour relier des applications au sein des organisations, entre les entreprises et dans Internet sont de plus en plus évidents à mesure que les services Web sont utilisés dans des programmes pilotes et dans le cadre d’une production à grande échelle. À l’avenir, nos clients, les analystes du secteur et la presse identifient un domaine clé qui doit être traité à mesure que les services web deviennent plus courants : la sécurité. Ce document propose une stratégie technique et une feuille de route permettant à l’industrie de produire et de mettre en œuvre une architecture basée sur des normes qui est complète mais suffisamment flexible pour répondre aux besoins de sécurité des services Web des entreprises réelles.

L’un des principaux avantages de l’architecture émergente des services Web est la possibilité de fournir des solutions intégrées et interopérables. Il est essentiel de garantir l’intégrité, la confidentialité et la sécurité des services Web par l’application d’un modèle de sécurité complet, tant pour les organisations que pour leurs clients.

En réponse aux préoccupations exprimées à la fois par nos clients et par l’industrie, IBM et Microsoft ont collaboré sur ce plan de sécurité et cette feuille de route proposés pour le développement d’un ensemble de spécifications de sécurité des services web qui traitent de la façon de fournir une protection pour les messages échangés dans un environnement de service Web.

Pour la première fois, nous avons créé un modèle de sécurité qui regroupe des technologies de sécurité auparavant incompatibles telles que l’infrastructure à clé publique, Kerberos et d’autres. En bref, il ne s’agit pas d’une infrastructure idéalisée, mais d’une infrastructure pratique qui peut nous permettre de créer des services Web sécurisés dans le monde informatique hétérogène dans lequel nos clients vivent aujourd’hui.

Dans ce document, nous présentons un large ensemble de spécifications qui couvrent les technologies de sécurité, notamment l’authentification, l’autorisation, la confidentialité, la confidentialité, la confiance, l’intégrité, la confidentialité, les canaux de communication sécurisés, la fédération, la délégation et l’audit dans un large éventail de topologies d’application et d’entreprise. Ces spécifications fournissent une infrastructure extensible, flexible et qui optimise les investissements existants dans l’infrastructure de sécurité. Ces spécifications sous-fondent et s’étendent sur les idées exprimées dans des spécifications similaires précédemment proposées par IBM et Microsoft (à savoir les spécifications SOAP-Security, WS-Security et WS-License).

En tirant parti de l’extensibilité naturelle qui est au cœur du modèle de services Web, les spécifications s’appuient sur des technologies fondamentales telles que SOAP, WSDL, signatures numériques XML, chiffrement XML et SSL/TLS. Cela permet aux fournisseurs de services Web et aux demandeurs de développer des solutions qui répondent aux exigences de sécurité individuelles de leurs applications.

IBM et Microsoft ont l’intention de travailler avec les clients, les partenaires et les organismes de normalisation pour faire évoluer et améliorer ce modèle de sécurité dans une approche par étapes. Nous sommes en cours d’amorçage de cet effort avec la spécification WS-Security . WS-Security définit les principales fonctionnalités pour protéger l’intégrité et la confidentialité d’un message, ainsi que les mécanismes d’association des revendications liées à la sécurité au message. Bien que WS-Security soit la pierre angulaire de cet effort, ce n’est que le début et nous coopérerons avec l’industrie pour produire des spécifications supplémentaires qui traiteront des questions de politique, de confiance et de confidentialité.

Pour rendre les problèmes et les solutions abordés dans ce document aussi concrets que possible, nous abordons plusieurs scénarios qui reflètent les applications actuelles et prévues des services Web. Il s’agit notamment du traitement du pare-feu, de la confidentialité, de l’utilisation du navigateur et des clients mobiles, du contrôle d’accès, de la délégation et de l’audit.

Nous anticipons des préoccupations quant à ce qui peut être fait pour garantir l’interopérabilité et la mise en œuvre cohérente des différentes spécifications proposées. Pour résoudre ce problème, IBM et Microsoft travailleront en étroite collaboration avec les organisations de normalisation, la communauté des développeurs et les organisations du secteur, telles que WS-I.org, pour développer des profils et des tests d’interopérabilité qui fourniront des conseils aux fournisseurs d’outils.

Ce document décrit une solution complète et modulaire qui, une fois implémentée, permettra aux clients de créer des services Web interopérables et sécurisés qui tirent parti des investissements existants dans l’infrastructure de sécurité tout en leur permettant de tirer pleinement parti des avantages de l’intégration et de l’interopérabilité des technologies de service web.

1 Introduction et motivation

La fourniture d’un modèle complet de fonctions et de composants de sécurité pour les services Web nécessite l’intégration des processus et technologies actuellement disponibles avec l’évolution des exigences de sécurité des applications futures. Elle exige des concepts fédérateurs ; elle nécessite des solutions aux problèmes technologiques (messagerie sécurisée) et de processus métier (stratégie, risque, confiance) ; enfin, elle nécessite des efforts coordonnés de la part des fournisseurs de plateforme, des développeurs d’applications, des fournisseurs de réseau et d’infrastructure et des clients.

L’unification de la gamme des technologies de sécurité disponibles signifie que les exigences fonctionnelles de la sécurité des applications doivent être extraites des mécanismes spécifiques utilisés. Par exemple, un client effectuant un achat en ligne ne devrait pas être affecté par l’utilisation d’un téléphone portable ou d’un ordinateur portable, tant que chaque appareil peut exprimer en toute sécurité l’identité appropriée.

L’objectif est de permettre aux clients de créer facilement des solutions interopérables à l’aide de systèmes hétérogènes. Par instance, le modèle de messagerie sécurisée proposé plus loin dans ce document prend en charge l’infrastructure à clé publique (PKI) et les mécanismes d’identité Kerberos en tant qu’incarnations particulières d’une installation plus générale et peut être étendu pour prendre en charge des mécanismes de sécurité supplémentaires. L’intégration via les abstractions d’un modèle de sécurité unique permet aux organisations d’utiliser leurs investissements existants dans les technologies de sécurité tout en communiquant avec les organisations à l’aide de différentes technologies.

En outre, comme les organisations utilisant différents mécanismes d’identité collaborent à l’aide de services web, le modèle d’approbation de sécurité fournit une infrastructure flexible au sein de laquelle les organisations peuvent s’interconnecter lorsqu’elles sont configurées avec l’autorisation appropriée.

En même temps, chaque client et chaque service Web ont leurs propres exigences de sécurité uniques en fonction de leurs besoins métier et de leur environnement opérationnel. Dans les paramètres de groupe de travail, pour instance, la simplicité et la facilité d’exploitation sont une préoccupation majeure, tandis que pour les applications Internet publiques, la capacité à résister aux attaques concertées par déni de service est une priorité plus élevée. Étant donné que ces exigences peuvent être combinées de plusieurs manières et exprimées à différents niveaux de spécificité, une approche réussie de la sécurité du service Web nécessite un ensemble de primitives de sécurité flexibles et interopérables qui, par le biais de la stratégie et de la configuration, permettent diverses solutions sécurisées.

Pour relever ces défis, ce document propose une approche évolutive de la création de services Web sécurisés et interopérables basés sur un ensemble d’abstractions de sécurité qui unifient des technologies autrefois dissemblables. Cela permet de se spécialiser en fonction des besoins particuliers des clients au sein d’une infrastructure globale tout en permettant aux technologies d’évoluer au fil du temps et d’être déployées de manière incrémentielle.

À titre d’exemple de cette approche évolutive, le modèle de messagerie sécurisée peut être ajouté aux solutions de sécurité au niveau du transport existantes. Un client peut ajouter une intégrité au niveau du message ou une confidentialité persistante (chiffrement des éléments de message) à un service Web existant dont les messages sont transmis via, par exemple, SSL/TLS (Secure Sockets Layer). Les messages ont désormais une intégrité (ou une confidentialité) qui persiste au-delà de la couche de transport.

Nous prévoyons que le modèle et les spécifications proposés seront largement disponibles auprès de plusieurs fournisseurs et seront pris en compte par les organismes de normalisation appropriés. Ensemble, le modèle, les spécifications et le processus de normalisation permettent aux entreprises d’augmenter rapidement et à moindre coût la sécurité de leurs applications existantes et de développer en toute confiance de nouveaux services Web sécurisés et interopérables.

L’avantage commercial d’un tel modèle est clair. En définissant une architecture de sécurité complète pour les services Web, les organisations et les clients peuvent être mieux assurés que leurs investissements et leurs ressources sont protégés à mesure que les processus métier deviennent de plus en plus recastrés en tant que services web.

Terminologie du modèle de sécurité des services web

É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é.

  • Service web : le terme « service web » est largement applicable à un large éventail de topologies d’applications réseau. Dans ce document, nous utilisons le terme « service web » pour décrire les composants d’application dont les fonctionnalités et les interfaces sont exposées aux utilisateurs potentiels par le biais de l’application de normes de technologie web existantes et émergentes, notamment XML, SOAP, WSDL et HTTP. Contrairement aux sites Web, aux interactions basées sur les navigateurs ou aux technologies dépendantes de la plateforme, les services Web sont des services offerts d’ordinateur à ordinateur, via des formats et protocoles définis, de manière indépendante de la plateforme et sans langue.

  • Jeton de sécurité : nous définissons un jeton de sécurité comme une représentation des informations liées à la sécurité (par exemple, certificat X.509, tickets Kerberos et authentificateurs, jetons de sécurité des appareils mobiles provenant de cartes SIM, nom d’utilisateur, etc.).

    Le diagramme suivant montre certains des différents types de jetons de sécurité.

  • Jeton de sécurité signé : nous définissons un jeton de sécurité signé comme un jeton de sécurité qui contient un ensemble de revendications (assertions) associées approuvées par un émetteur. Les certificats X.509 et les tickets Kerberos sont des exemples de jetons de sécurité signés.

  • Revendications : une revendication est une déclaration au sujet d’un sujet par le sujet ou par une autre partie qui l’associe à la revendication. Un point important est que cette spécification ne tente pas de limiter les types de revendications qui peuvent être effectuées, ni de limiter la façon dont ces revendications peuvent être exprimées. Les revendications peuvent concerner des clés potentiellement utilisées pour signer ou chiffrer des messages. Les revendications peuvent être des instructions que le jeton de sécurité transmet. Les revendications peuvent être utilisées, par exemple, pour affirmer l’identité de l’expéditeur ou un rôle autorisé.

  • Objet : l’objet du jeton de sécurité est un principal (par exemple, une personne, une application ou une entité commerciale) auquel s’appliquent les revendications exprimées dans le jeton de sécurité. Plus précisément, le sujet, en tant que propriétaire du jeton de sécurité possède les informations nécessaires pour prouver la propriété du jeton de sécurité.

  • Preuve de possession : nous définissons la preuve de possession comme des informations utilisées dans le processus de preuve de la propriété d’un jeton de sécurité ou d’un ensemble de revendications. Par exemple, la preuve de possession peut être la clé privée associée à un jeton de sécurité qui contient une clé publique.

  • Stratégie de point de terminaison de service web : les services web disposent d’une flexibilité totale dans la spécification des revendications dont ils ont besoin pour traiter les messages. Collectivement, nous faisons référence à ces revendications requises et aux informations associées sous le nom de « stratégie de point de terminaison de service web ». Les stratégies de point de terminaison peuvent être exprimées en XML et peuvent être utilisées pour indiquer des exigences liées à l’authentification (par exemple, la preuve d’identité de l’utilisateur ou du groupe), à l’autorisation (par exemple, la preuve de certaines fonctionnalités d’exécution) ou à d’autres exigences personnalisées.

  • Exigences de revendication : les exigences de revendication peuvent être liées à des messages entiers ou à des éléments de messages, à toutes les actions d’un type donné ou à des actions uniquement dans certaines circonstances. Par exemple, un service peut exiger qu’un demandeur prouve son autorité pour les montants d’achat supérieurs à une limite indiquée.

  • Intermédiaires : comme les messages SOAP sont envoyés d’un demandeur initial à un service, ils peuvent être exploités par des intermédiaires qui effectuent des actions telles que le routage du message ou même la modification du message. Par exemple, un intermédiaire peut ajouter des en-têtes, chiffrer ou déchiffrer des éléments du message, ou ajouter des jetons de sécurité supplémentaires. Dans de telles situations, il faut veiller à ce que les modifications apportées au message n’invalident pas l’intégrité du message, ne violent pas le modèle d’approbation ou ne détruisent pas la responsabilité.

  • Acteur : un acteur est un intermédiaire ou un point de terminaison (tel que défini dans la spécification SOAP ) identifié par un URI et qui traite un message SOAP. Notez que ni les utilisateurs ni les logiciels clients (par exemple, les navigateurs) ne sont des acteurs.

Principes du modèle de sécurité des services web

Les services web sont accessibles en envoyant des messages SOAP aux points de terminaison de service identifiés par des URI, en demandant des actions spécifiques et en recevant des réponses de message SOAP (y compris les indications d’erreur). Dans ce contexte, l’objectif général de la sécurisation des services Web s’inscrit dans les objectifs subsidiaires consistant à fournir des moyens de garantir l’intégrité et la confidentialité des messages et de s’assurer que le service agit uniquement sur les demandes dans les messages qui expriment les revendications requises par les stratégies.

Aujourd’hui, le protocole SSL (Secure Socket Layer) ainsi que le protocole TLS (Transport Layer Security) de facto sont utilisés pour fournir une sécurité au niveau du transport pour les applications de services web. SSL/TLS offre plusieurs fonctionnalités de sécurité, notamment l’authentification, l’intégrité des données et la confidentialité des données. SSL/TLS active les sessions sécurisées point à point.

IPSec est une autre norme de la couche réseau pour la sécurité du transport qui peut devenir importante pour les services Web. Comme SSL/TLS, IPSec fournit également des sessions sécurisées avec l’authentification de l’hôte, l’intégrité des données et la confidentialité des données.

Les topologies d’applications de service web d’aujourd’hui incluent une vaste combinaison d’appareils mobiles, de passerelles, de proxys, d’équilibreurs de charge, de zones démilitarisées (DMZ), de centres de données externalisés et de systèmes mondialement distribués et configurés dynamiquement. Tous ces systèmes s’appuient sur la capacité des intermédiaires de traitement des messages à transférer des messages. Plus précisément, le modèle de message SOAP fonctionne sur des points de terminaison logiques qui font abstraction de l’infrastructure du réseau physique et de l’application et, par conséquent, intègrent fréquemment une topologie multi-hop avec des acteurs intermédiaires.

Lorsque des données sont reçues et transférées par un intermédiaire au-delà de la couche de transport, l’intégrité des données et toutes les informations de sécurité qui circulent avec elles peuvent être perdues. Cela force les processeurs de messages amont à s’appuyer sur les évaluations de sécurité effectuées par les intermédiaires précédents et à faire entièrement confiance à leur gestion du contenu des messages. Ce qui est nécessaire dans une architecture de sécurité de service Web complète est un mécanisme qui fournit une sécurité de bout en bout. Les solutions de sécurité de service Web réussies pourront tirer parti des mécanismes de sécurité de la couche transport et application pour fournir une suite complète de fonctionnalités de sécurité.

Configuration point à point

Configuration de bout en bout

Le modèle de sécurité de service Web décrit ici nous permet d’atteindre ces objectifs par un processus dans lequel :

  • Un service Web peut exiger qu’un message entrant prouve un ensemble de revendications (par exemple, nom, clé, autorisation, fonctionnalité, etc.). Si un message arrive sans avoir les revendications requises, le service peut ignorer ou rejeter le message. Nous faisons référence à l’ensemble des revendications requises et des informations associées en tant que stratégie.
  • Un demandeur peut envoyer des messages avec la preuve des revendications requises en associant des jetons de sécurité aux messages. Ainsi, les messages demandent une action spécifique et prouvent que leur expéditeur a la revendication pour exiger l’action.
  • Lorsqu’un demandeur n’a pas les revendications requises, il peut essayer d’obtenir les revendications nécessaires en contactant d’autres services Web. Ces autres services Web, que nous appelons services de jeton de sécurité, peuvent à leur tour nécessiter leur propre ensemble de revendications. Les services de jeton de sécurité répartit l’approbation entre différents domaines d’approbation en émettant des jetons de sécurité.

Ce modèle est illustré dans la figure ci-dessous, montrant que n’importe quel demandeur peut également être un service, et que le service d’émission de jetons de sécurité peut également être entièrement un service Web, y compris exprimer une stratégie et exiger des jetons de sécurité.

Ce modèle de messagerie général (revendications, stratégies et jetons de sécurité) sous-regroupe et prend en charge plusieurs modèles plus spécifiques tels que la sécurité basée sur l’identité, les listes de contrôle d’accès et la sécurité basée sur les fonctionnalités. Il permet d’utiliser des technologies existantes telles que les certificats de clé publique X.509, les tickets de secret partagé Kerberos et même les synthèses de mot de passe. Comme nous l’aborderons plus loin, il fournit également une abstraction d’intégration permettant aux systèmes de créer un pont entre différentes technologies de sécurité. Le modèle général est suffisant pour construire des mécanismes d’échange de clés, d’authentification, d’autorisation, d’audit et d’approbation de niveau supérieur.

2 Spécifications de sécurité des services web

La stratégie de sécurité exprimée ici et la spécification WS-Security introduite ci-dessous fournissent les objectifs stratégiques et la pierre angulaire de ce modèle de sécurité des services Web proposé.

À l’avenir, nous poursuivons le processus de collaboration avec les clients, les partenaires et les organisations de normes pour développer un ensemble initial de spécifications de sécurité des services Web.

Cet ensemble inclut un modèle de sécurité de message (WS-Security) qui fournit la base des autres spécifications de sécurité. Nous avons une couche de stratégie qui inclut une stratégie de point de terminaison de service web (WS-Policy), un modèle d’approbation (WS-Trust) et un modèle de confidentialité (WS-Privacy). Ensemble, ces spécifications initiales fournissent la base sur laquelle nous pouvons travailler pour établir des services Web interopérables sécurisés dans des domaines d’approbation.

En nous appuyant sur ces spécifications initiales, nous continuerons à travailler avec les clients, les partenaires et les organisations de normes pour fournir des spécifications de suivi pour la sécurité fédérée, qui incluent des conversations sécurisées (WS-SecureConversation), l’approbation fédérée (WS-Federation) et l’autorisation (WS-Authorization).

La combinaison de ces spécifications de sécurité permet de nombreux scénarios (dont certains sont décrits plus loin dans ce document) qui sont difficiles à implémenter avec les mécanismes de sécurité de base actuels.

En parallèle, nous allons proposer et aller de l’avant avec des activités connexes qui améliorent l’infrastructure de sécurité des services Web avec des spécifications liées à l’audit, à la gestion et à la confidentialité.

En outre, IBM et Microsoft s’engagent à travailler avec des organisations telles que WS-I sur des profils d’interopérabilité.

La combinaison de spécifications de sécurité, d’activités associées et de profils d’interopérabilité permet aux clients de créer facilement des services Web sécurisés interopérables.

Chacune des spécifications proposées est résumée ci-dessous :

Spécifications initiales

  • 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 : décrit 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, les jetons de sécurité requis, les algorithmes de chiffrement pris en charge, les règles de confidentialité).
  • WS-Trust : décrit une infrastructure pour les modèles d’approbation qui permet aux services web d’interagir en toute 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 déclarations de pratiques de confidentialité de l’organisation.

Spécifications de suivi

  • WS-SecureConversation : décrit comment gérer et authentifier les échanges de messages entre les parties, y compris l’échange 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, y compris la prise en charge des identités fédérées.
  • WS-Authorization : décrit comment gérer les données d’autorisation et les stratégies d’autorisation.

La sécurité de WS-Security nécessite une diligence raisonnable dans la production des descriptions, des spécifications et des profils dans un certain nombre de domaines fonctionnels. Ces documents changeront et évolueront à travers un processus qui équilibre les besoins des clients avec les besoins de la communauté de développement des services Web et notre propre processus éducatif à mesure que nous suivons le processus de spécification.

WS-Security

WS-Security décrit les améliorations apportées à la messagerie SOAP pour fournir une qualité de protection grâce à l’intégrité des messages et à la confidentialité des messages. En outre, cette spécification définit comment attacher et inclure des jetons de sécurité dans les messages SOAP. Enfin, un mécanisme est fourni pour spécifier des jetons de sécurité encodés binaires (par exemple, des certificats X.509). Ces mécanismes peuvent être utilisés indépendamment ou en combinaison pour prendre en charge un large éventail de modèles de sécurité et de technologies de chiffrement.

WS-Security fournit un mécanisme à usage général pour associer des jetons de sécurité à des messages. Aucun type spécifique de jeton de sécurité n’est requis par WS-Security. Il est conçu pour être extensible (par exemple, prendre en charge plusieurs formats de jeton de sécurité). Par exemple, un demandeur peut fournir une preuve d’identité et une preuve qu’il dispose d’une certification commerciale particulière.

L’intégrité des messages est assurée en tirant parti de la signature XML conjointement avec des jetons de sécurité (qui peuvent contenir ou impliquer des données clés) pour garantir que les messages sont transmis sans modification. Les mécanismes d’intégrité sont conçus pour prendre en charge plusieurs signatures, potentiellement par plusieurs acteurs, et pour être extensibles pour prendre en charge des formats de signature supplémentaires. Les signatures peuvent référencer (c’est-à-dire pointer vers) un jeton de sécurité.

De même, la confidentialité des messages est assurée en tirant parti du chiffrement XML conjointement avec des jetons de sécurité pour préserver la confidentialité de certaines parties des messages SOAP. Les mécanismes de chiffrement sont conçus pour prendre en charge des technologies, des processus et des opérations de chiffrement supplémentaires par plusieurs acteurs. Le chiffrement peut également référencer un jeton de sécurité.

Enfin, WS-Security décrit un mécanisme d’encodage de jetons de sécurité binaires. Plus précisément, la spécification décrit comment encoder des certificats X.509 et des tickets Kerberos, ainsi que comment inclure des clés chiffrées opaques. Il inclut également des mécanismes d’extensibilité qui peuvent être utilisés pour décrire plus en détail les caractéristiques des jetons de sécurité inclus dans un message.

WS-Policy

WS-Policy décrit comment les expéditeurs et les récepteurs peuvent spécifier leurs exigences et leurs capacités.

WS-Policy seront entièrement extensibles et n’imposeront pas de limites aux types d’exigences et de fonctionnalités qui peuvent être décrits; Toutefois, la spécification identifiera probablement plusieurs attributs de service de base, notamment les attributs de confidentialité, les formats d’encodage, les exigences de jeton de sécurité et les algorithmes pris en charge.

Cette spécification définit un format de stratégie SOAP générique, qui peut prendre en charge plus que les stratégies de sécurité. Cette spécification définit également un mécanisme pour attacher ou associer des stratégies de service à des messages SOAP.

WS-Trust

WS-Trust décrit le modèle permettant d’établir des relations d’approbation directes et réparties (y compris les tiers et les intermédiaires).

Cette spécification décrit comment les relations d’approbation directe existantes peuvent être utilisées comme base pour le répartiteur de l’approbation par le biais de la création de services d’émission de jetons de sécurité. Ces services d’émission de jetons de sécurité s’appuient sur WS-Security pour transférer les jetons de sécurité requis d’une manière qui garantit l’intégrité et la confidentialité de ces jetons.

Cette spécification décrit ensuite comment plusieurs mécanismes d’approbation existants peuvent être utilisés conjointement avec ce modèle d’approbation.

Enfin, le modèle d’approbation autorise explicitement la délégation et l’emprunt d’identité par les principaux, mais ne l’impose pas. Notez que la délégation est cohérente avec l’emprunt d’identité, mais fournit des niveaux de traçabilité supplémentaires.

WS-Privacy

Les organisations qui créent, gèrent et utilisent des services Web doivent souvent indiquer leurs stratégies de confidentialité et exiger que les demandes entrantes fassent des revendications sur l’adhésion des expéditeurs à ces stratégies.

En utilisant une combinaison de WS-Policy, WS-Security et WS-Trust, les organisations peuvent déclarer et indiquer la conformité aux stratégies de confidentialité énoncées. Cette spécification décrit un modèle pour la façon dont un langage de confidentialité peut être incorporé dans WS-Policy descriptions et comment WS-Security peut être utilisé pour associer des revendications de confidentialité à un message. Enfin, cette spécification décrit comment WS-Trust mécanismes peuvent être utilisés pour évaluer ces revendications de confidentialité pour les préférences des utilisateurs et les revendications de pratiques organisationnelles.

WS-SecureConversation

WS-SecureConversation décrit comment un service Web peut authentifier les messages du demandeur, comment les demandeurs peuvent authentifier les services et comment établir des contextes de sécurité mutuellement authentifiés.

Cette spécification décrit comment établir des clés de session, des clés dérivées et des clés par message.

Enfin, cette spécification décrit comment un service peut échanger en toute sécurité le contexte (collections de revendications sur les attributs de sécurité et les données associées). Pour ce faire, la spécification décrit et s’appuie sur les concepts d’émission de jetons de sécurité et de mécanismes d’échange définis dans WS-Security et WS-Trust. À l’aide de ces mécanismes, un service peut, par exemple, prendre en charge les jetons de sécurité à l’aide d’une technologie de clé symétrique faible et émettre des jetons de sécurité plus forts à l’aide de clés non partagées (asymétriques).

WS-SecureConversation est conçu pour fonctionner au niveau de la couche de messages SOAP afin que les messages puissent traverser divers transports et intermédiaires. Cela n’empêche pas son utilisation dans d’autres frameworks de messagerie. Afin d’accroître davantage la sécurité des systèmes, la sécurité au niveau du transport peut être utilisée conjointement avec WS-Security et WS-SecureConversation entre les liaisons sélectionnées.

Un certificat de fournisseur d'identité WS-Federation

Cette spécification définit comment construire des scénarios de confiance fédérée à l’aide des spécifications WS-Security, WS-Policy, WS-Trust et WS-SecureConversation. Par exemple, il décrit comment fédérer des infrastructures Kerberos et PKI (comme décrit dans les scénarios ci-dessous).

En outre, une stratégie d’approbation est introduite pour indiquer, limiter et identifier le type d’approbation qui est réparti.

Cette spécification définit également les mécanismes de gestion des relations d’approbation.

WS-Authorization

Cette spécification décrit la façon dont les stratégies d’accès d’un service web sont spécifiées et gérées. En particulier, il décrit comment les revendications peuvent être spécifiées dans les jetons de sécurité et comment ces revendications seront interprétées au niveau du point de terminaison.

Cette spécification sera conçue pour être flexible et extensible en ce qui concerne à la fois le format d’autorisation et le langage d’autorisation. Cela permet le plus large éventail de scénarios et garantit la viabilité à long terme de l’infrastructure de sécurité.

3 Relation entre la sécurité des services web et les modèles de sécurité d’aujourd’hui

Ce modèle de sécurité des services Web est compatible avec les modèles de sécurité existants pour l’authentification, l’intégrité des données et la confidentialité des données en usage courant aujourd’hui. Par conséquent, il est possible d’intégrer des solutions basées sur des services Web à d’autres modèles de sécurité existants :

  • Sécurité du transport : les technologies existantes telles que les sockets sécurisés (SSL/TLS) peuvent fournir une intégrité et une confidentialité point à point simples pour un message. Le modèle de sécurité des services web prend en charge l’utilisation de ces mécanismes de transport sécurisés existants conjointement avec WS-Security (et d’autres spécifications) pour fournir une intégrité de bout en bout et de manière confidentielle, en particulier sur plusieurs transports, intermédiaires et protocoles de transmission.
  • PKI : à un niveau élevé, le modèle PKI implique des autorités de certification qui émettent des certificats avec des clés asymétriques publiques et des autorités qui affirment des propriétés autres que la propriété de clé (par exemple, les autorités d’attribut). Les propriétaires de ces certificats peuvent utiliser les clés associées pour exprimer diverses revendications, y compris l’identité. Le modèle de sécurité des services web prend en charge les services de jeton de sécurité qui émettent des jetons de sécurité à l’aide de clés asymétriques publiques. PKI est utilisé ici dans le sens le plus large et ne suppose aucune hiérarchie ou modèle particulier.
  • Kerberos : le modèle Kerberos s’appuie sur la communication avec le centre de distribution de clés (KDC) pour créer une relation de confiance entre les parties en émettant des clés symétriques chiffrées pour les deux parties et en les « introduisant » mutuellement. Le modèle de services web, encore une fois, s’appuie sur le modèle principal avec les services de jetons de sécurité qui répartit l’approbation en émettant des jetons de sécurité avec des clés symétriques chiffrées et des testaments chiffrés.

Notez que si les modèles sont compatibles, pour garantir l’interopérabilité, des adaptateurs et/ou des algorithmes communs pour les signatures et le chiffrement devront être convenus ou développés.

Les modèles existants pour la fédération, l’autorisation (y compris la délégation), la confidentialité et la confiance sont moins courants et plus ad hoc. Les spécifications permettant de traiter ces propriétés de sécurité sont identifiées dans les phases ultérieures de la stratégie.

Souvent, les modèles d’approbation existants sont basés sur des contrats d’entreprise. Le service Web UDDI en est un exemple. Dans UDDI, plusieurs participants fournissent un registre universel des entreprises par le biais d’un accord pour prendre en charge un ensemble d’API. Au lieu de définir un modèle unique pour la « confiance » par le biais de l’exigence d’un mécanisme d’authentification spécifique, le « modèle d’approbation » dans UDDI donne la responsabilité de l’authentification au nœud, qui est le dépositaire des informations. Autrement dit, chaque implémentation du service Web UDDI a son propre mécanisme d’authentification et applique sa propre stratégie de contrôle d’accès. La « confiance » est entre les opérateurs et entre le demandeur et l’opérateur qui est le dépositaire de ses informations.

4 scénarios

Nous présentons ci-dessous un certain nombre de scénarios qui illustrent la façon dont nous envisageons les spécifications de sécurité du service Web proposées en cours d’utilisation. Ces scénarios sont intentionnellement axés sur les détails techniques pour illustrer les fonctionnalités de la stratégie de sécurité globale. Une documentation complémentaire fournit des scénarios d’utilisation métier détaillés.

Les exemples d’entreprises, d’organisations, de produits, de noms de domaine, d’adresses e-mail, de logos, de personnes, de lieux et d’événements représentés ici sont fictifs. Aucune association avec une entreprise réelle, organization, produit, nom de domaine, adresse e-mail, logo, personne, lieux ou événements n’est prévue ou ne doit être déduite.

La liste ci-dessous présente brièvement certains scénarios qui peuvent être pris en charge par les spécifications initiales proposées et les livrables associés :

  • Confiance directe à l’aide du nom d’utilisateur/du mot de passe et de la sécurité Transport-Level : ce scénario illustre l’authentification à l’aide d’un nom d’utilisateur et d’un mot de passe avec sécurité de transport.
  • Approbation directe à l’aide de jetons de sécurité : ce scénario illustre la confiance directe à l’aide de la certification X.509 et des tickets de service Kerberos (ST).
  • Acquisition de jetons de sécurité : ce scénario illustre l’authentification à l’aide d’un jeton de sécurité stocké indépendamment du message.
  • Traitement du pare-feu : ce scénario illustre comment les pare-feu peuvent tirer parti de ce modèle de sécurité pour un plus grand degré de contrôle.
  • Jeton de sécurité émis : ce scénario illustre l’authentification de base.
  • Application d’une stratégie d’entreprise : ce scénario montre comment utiliser l’émission de jetons de sécurité pour la codification des processus métier.
  • Confidentialité : ce scénario illustre la façon dont les clients et les services peuvent communiquer leurs politiques de confidentialité.
  • Clients web : ce scénario illustre l’utilisation d’un navigateur Web en tant que client.
  • Clients mobiles : ce scénario illustre comment les clients mobiles peuvent interagir en toute sécurité avec les services Web.

Le deuxième ensemble de scénarios est plus sophistiqué. Ces scénarios PEUVENT être basés sur les livrables actuels, mais ont besoin de spécifications de suivi (telles que WS-SecureConversation) pour rendre l’interopérabilité transparente.

  • Activation de la fédération : cette section décrit plusieurs scénarios impliquant une approbation fédérée.
  • Service de validation : décrit comment utiliser un service qui valide la sécurité d’un message (par exemple, la signature).
  • Prise en charge de la délégation : cela montre comment utiliser des jetons de sécurité pour la délégation.
  • Access Control : cela montre comment la sécurité des services Web prend en charge la sécurité traditionnelle basée sur la liste de contrôle d’accès.
  • Audit : cela illustre l’utilisation de l’audit pour suivre les activités et les incidents liés à la sécurité.

Notez que dans les descriptions ci-dessous, l’utilisation du terme demandeur est utilisée pour décrire la grande variété d’utilisateurs potentiels d’un service Web et n’est pas destinée à limiter les caractéristiques du demandeur. Les demandeurs peuvent inclure des entités commerciales qui interagissent avec un service au sein d’un environnement B2B ou des personnes qui accèdent aux services à partir d’un navigateur ou d’un appareil mobile.

Confiance directe à l’aide du nom d’utilisateur/mot de passe et de la sécurité Transport-Level

Voici un exemple très simple montrant comment la sécurité des services web peut être utilisée avec les mécanismes de sécurité de transport existants :

Le demandeur ouvre une connexion au service Web à l’aide d’un transport sécurisé (par exemple, SSL/TLS). Il envoie sa demande et inclut un jeton de sécurité qui contient son nom d’utilisateur et son mot de passe. Le service authentifie les informations, traite la demande et retourne le résultat.

Dans ce scénario, la confidentialité et l’intégrité des messages sont gérées à l’aide des mécanismes de sécurité de transport existants.

Ce scénario suppose que les deux parties ont déjà utilisé un mécanisme pour établir un secret partagé: le mot de passe du demandeur. Aucune hypothèse n’est faite au sujet de la relation organisationnelle entre ces parties.

Approbation directe à l’aide de jetons de sécurité

Ce scénario illustre l’utilisation d’un jeton de sécurité qui est directement approuvé par un service Web. Ici, l’approbation directe signifie que le jeton de sécurité du demandeur (ou son autorité de signature) est connu et approuvé par le service Web. Ce scénario suppose que les deux parties ont utilisé un mécanisme pour établir une relation d’approbation pour l’utilisation du jeton de sécurité. Cette approbation peut être établie manuellement, en configurant l’application ou en utilisant un transport sécurisé pour échanger des clés. Par transport sécurisé de clés, nous voulons dire qu’un transport tel que SSL (ou un autre mécanisme ou processus) peut être utilisé comme un moyen pour une partie de confiance d’affirmer la validité d’une clé ou d’un jeton de sécurité à une partie destinataire. Aucune hypothèse n’est faite concernant la relation organisationnelle entre les parties.

Le demandeur envoie un message à un service et inclut un jeton de sécurité signé et fournit une preuve de possession du jeton de sécurité à l’aide, par exemple, d’une signature. Le service vérifie la preuve et évalue le jeton de sécurité. La signature sur le jeton de sécurité est valide et est approuvée directement par le service. Le service traite la demande et retourne un résultat.

La confiance directe suppose que les politiques de confidentialité sont bien comprises par les parties concernées.

Acquisition de jetons de sécurité

Dans certains cas, le jeton de sécurité utilisé n’est pas passé dans le cadre du message. Au lieu de cela, une référence de jeton de sécurité est fournie qui peut être utilisée pour localiser et acquérir le jeton.

Le demandeur émet une demande au service et inclut une référence au jeton de sécurité et fournit une preuve de possession. Le service Web utilise les informations fournies pour obtenir le jeton de sécurité auprès du service de magasin de jetons et valider la preuve. Le service web approuve (notez que l’approbation a été établie en dehors de la sémantique du message) le jeton de sécurité, de sorte que la demande est traitée et la réponse est retournée.

Traitement du pare-feu

Les pare-feu restent un composant essentiel de l’architecture de sécurité des services Web. Ils doivent pouvoir continuer à appliquer des règles de traitement des limites.

Comme indiqué ci-dessous, le pare-feu examine les messages SOAP entrants et autorise uniquement ceux des demandeurs « autorisés » à pénétrer dans le pare-feu.

Dans ce scénario, deux demandeurs envoient des messages à un service web à l’intérieur d’un pare-feu. Le pare-feu examine les messages pour déterminer si le demandeur est « autorisé » à envoyer des messages au service Web spécifié à l’intérieur du pare-feu.

Dans ce scénario, le pare-feu prend cette décision en examinant le jeton de sécurité utilisé pour signer le message. Si la signature est valide et que l’autorité de signature du jeton de sécurité est approuvée pour autoriser les messages dans le pare-feu, et si le jeton indique qu’il autorise les messages dans le pare-feu, le message est autorisé ; sinon, il est rejeté. Dans certains cas, une signature peut spécifiquement référencer le pare-feu en tant qu’acteur SOAP.

Dans d’autres scénarios, le pare-feu peut également agir en tant qu’autorité émettrice de jetons de sécurité et autoriser uniquement les messages qui incluent la preuve de possession d’un jeton de sécurité émis par le pare-feu.

Jeton de sécurité émis

Voici un exemple montrant comment la sécurité des services web prend en charge l’authentification simple par une partie de confiance :

Dans les deux premières étapes, le demandeur communique avec une autorité de certification pour obtenir un jeton de sécurité, en particulier une déclaration signée d’assertions attestant de l’identité du demandeur.

Le demandeur a obtenu un jeton de sécurité, car le service Web a une stratégie exigeant qu’un jeton de sécurité du type approprié soit nécessaire (dans ce cas, une preuve d’identité).

Le demandeur envoie ensuite un message, avec le jeton de sécurité et une preuve de possession joints au message (authentificateur ou défi signé), au service Web et reçoit une réponse.

Notez que dans la description ci-dessus, le fonctionnement du service de certification d’identité n’a pas été décrit en détail. Pour obtenir un jeton de sécurité d’identité, les demandeurs peuvent utiliser des protocoles de sécurité existants ou tirer parti des spécifications de sécurité des services Web.

Si nous partons du principe que le demandeur utilise les spécifications de sécurité des services Web, le système fonctionne comme suit : le service d’identité décrit ses exigences dans une stratégie et le demandeur peut ensuite demander un jeton de sécurité ainsi que sa preuve d’identité.

Notez que le service d’identité n’est qu’un service de jeton de sécurité. De plus, la symétrie des services web permet à n’importe quel service Web d’encapsuler également un service de jeton de sécurité.

Enfin, notez que les services web peuvent obtenir des jetons de sécurité pour le compte du demandeur (à partir d’un service de jeton de sécurité) et les renvoyer au demandeur pour les utiliser sur les messages suivants.

Application d’une stratégie métier

Dans de nombreux processus métier, il existe des stratégies spécifiques qui doivent être appliquées. Par exemple, un service peut exiger que les consommateurs disposent d’une évaluation ou d’une position auprès d’une société d’audit spécifique. Avec les services web, un grand nombre de ces stratégies peuvent être codifiées et validées automatiquement, ce qui simplifie le processus global.

Prenons l’exemple suivant :

Nicholas' Concession dispose d’un service Web qu’elle utilise pour interagir avec ses fournisseurs de pièces. Cependant, ils veulent uniquement traiter avec des fournisseurs dont les pièces sont certifiées par le fabricant.

Une société de pièces, Joshua’s Parts, s’adresse au fabricant et présente (et prouve) son jeton de sécurité d’identité (par exemple, le service de jeton de sécurité illustré) et demande un jeton de sécurité au fabricant indiquant qu’il est un revendeur de pièces certifié (en supposant qu’il est certifié et en règle). Joshua’s Parts a ensuite pu contacter le concessionnaire Nicholas et fournir (et prouver) les deux jetons de sécurité.

Si le concessionnaire Nicholas a codifié sa politique commerciale dans la politique de service, le fardeau de la conformité de la stratégie pourrait être chargé à l’avance pour l’entreprise de pièces (par exemple, Joshua’s Parts).

La politique de service peut également spécifier des contraintes sur les informations que le fabricant serait autorisé à stocker pour garantir la conformité à la politique de confidentialité.

Confidentialité

La protection des renseignements personnels comprend un large éventail de préoccupations et devra être prise en compte dans chacune des spécifications qui découlent de cette stratégie.

Les questions de confidentialité de base seront traitées en fournissant des déclarations de confidentialité dans la politique de service. Des scénarios plus sophistiqués, impliquant la délégation et l’autorisation, seront couverts dans les spécifications spécifiques à ces scénarios.

Par exemple, une personne indique un ensemble de « préférences en matière de confidentialité » qui décrivent ce que l’individu fait ou ne veut pas autoriser les applications agissant au nom des individus à faire avec les renseignements personnels. Une application de calendrier, qui travaille pour le compte des individus, peut désormais accéder à un service de calendrier qui utilise un ensemble de « règles de pratique en matière de protection des renseignements personnels », afin de prendre des déclarations et des décisions concernant l’utilisation et la divulgation de renseignements personnels. Le service de calendrier prend la décision en combinant les règles de pratique en matière de protection des renseignements personnels avec les préférences en matière de confidentialité pour déterminer si une utilisation ou une divulgation proposée est autorisée.

Web Clients

Prenons un exemple où nous avons un client Web qui communique avec une application web de niveau intermédiaire, qui, à son tour, communique (de manière sécurisée) avec un service web dans un autre domaine. L’application web de niveau intermédiaire, qui prend en charge les services web, souhaite obtenir un jeton de sécurité pour le client Web.

En outre, ce scénario suppose que le jeton de sécurité permet à l’application de niveau intermédiaire d’agir au nom du client lorsqu’elle communique avec le service.

Pour activer ce scénario, le navigateur du client Web accède à l’application de niveau intermédiaire et est redirigé vers un service d’identité associé. Une fois authentifiée (par exemple à l’aide d’un formulaire HTML et https), la demande est redirigée vers l’application de niveau intermédiaire. Le service d’identité fournit un jeton de sécurité (affirmant l’identité et les délégations) au serveur Web d’application de couche intermédiaire d’origine (par exemple, à l’aide d’une chaîne de requête envoyée via HTTPS). Le serveur web peut désormais utiliser ces jetons de sécurité et émettre des demandes de sa propre identité au service Web. Le service Web traite les requêtes et retourne les résultats au serveur Web, où les résultats sont mis en forme et renvoyés au navigateur.

Clients mobiles

Les spécifications décrites dans ce document ci-dessus offrent une grande flexibilité pour relever les défis de conception propres à la sécurité mobile.  La flexibilité de l’approche des services web permet la prise en charge de plusieurs technologies de chiffrement offrant une protection de chiffrement forte et performante sur les appareils avec des capacités de calcul et de stockage limitées.  De même, il permet aux opérateurs réseau de fournir des proxys de sécurité, tels que des passerelles réseau, pour agir pour le compte des clients mobiles. 

Voici un exemple de combinaison de ces deux idées.  Lorsqu’un opérateur réseau prend en charge les clients mobiles (à l’aide de ces spécifications de sécurité du service Web), il peut configurer ces clients pour envoyer des demandes via la passerelle de l’opérateur réseau.  Dans ce scénario, la passerelle est un intermédiaire SOAP qui participe activement au flux de messages global ; plus précisément, l’opérateur réseau fournit un algorithme de chiffrement à valeur ajoutée conçu pour les appareils mobiles.  La passerelle peut augmenter ou modifier les jetons de sécurité et la qualité de la protection du message.  Notez que la flexibilité inhérente à ce modèle de sécurité des services Web permet cette solution même lorsque l’appareil est en itinérance sur un réseau étranger. 

Ceci est illustré dans l’exemple ci-dessous :

Activation de la fédération

Le modèle de sécurité des services web est conçu pour prendre en charge la fédération. Voici un exemple simple de fédération d’identité :

Alice chez Adventure456 souhaite utiliser le service Web monétaire sur Business456. Le service Devise traite uniquement les demandes avec un jeton de sécurité émis par Business456. Alice a uniquement un jeton de sécurité avec des revendications d’identité (c’est-à-dire un jeton de sécurité d’identité) émis par Adventure456.

Dans ce scénario, Alice ne pourra accéder au service Monétaire que si Business456 accepte la fédération de sécurité avec Adventure456.

Les sous-sections suivantes décrivent plusieurs approches de la fédération de sécurité.

Fédération à l’aide de l’échange de jetons de sécurité

Dans cette approche, la stratégie du service Monétaire indique qu’il accepte uniquement les jetons de sécurité émis par Business456. Étant donné que la stratégie indique où obtenir le jeton de sécurité requis, Alice présente (et prouve) son jeton de sécurité Adventure456 au service de jeton de sécurité Business456 et reçoit un jeton de sécurité Business456. Elle présente ensuite (et prouve) ce jeton de sécurité dans les requêtes adressées au service Currency. Ceci est illustré dans le diagramme ci-dessous :

Dans cette approche, le service de jeton de sécurité Business456 a été configuré pour accepter les jetons de sécurité avec des revendications d’identité émises par Adventure456

Il convient de noter que cet exemple est très similaire à l’exemple dans le scénario Application de la stratégie d’entreprise. Cela montre la flexibilité du modèle de sécurité du service web.

Fédération à l’aide du chaînage d’approbations

Dans cette approche, le service Devise accepte une demande avec n’importe quel jeton de sécurité, mais il ne traite pas la demande, sauf s’il peut obtenir un jeton de sécurité Business456 basé sur le jeton de sécurité fourni (et la preuve).

Pour ce faire, le service Devise transfère la demande d’origine au service de jeton de sécurité Business456 qui évalue le jeton de sécurité initial. S’il est valide, il approuve la demande et peut inclure un jeton de sécurité Business456 qu’Alice pourra utiliser sur les demandes suivantes. Cela est illustré dans la figure ci-dessous.

Dans cette approche, le service de jeton de sécurité Business456 a été configuré pour accepter les jetons de sécurité avec des revendications d’identité émises par Adventure456

Fédération à l’aide d’un échange de jetons de sécurité (PKIKerberos)

Dans cette approche, Adventure456 a émis à Alice un jeton de sécurité à clé publique et la stratégie du service Currency indique qu’il accepte uniquement les jetons de sécurité Kerberos de son KDC.

À l’orientation de la stratégie du service Monétaire, Alice présente (et prouve) son jeton de sécurité à clé publique au service de jeton de sécurité de Business456. Le service de jeton de sécurité encapsule le KDC de Business456. Par conséquent, il est en mesure de valider le jeton de sécurité de clé publique d’Alice et émet un jeton de sécurité Kerberos pour le service Currency. Cela est illustré dans la figure ci-dessous :

Dans cette approche, le service de jeton de sécurité Business456 a été configuré pour accepter les jetons de sécurité à clé publique avec des revendications d’identité émises par Adventure456.

Fédération à l’aide de l’échange de jetons de sécurité (Service de jeton KerberosSecurity)

Dans cette approche, Adventure456 a émis un jeton de sécurité Kerberos et la stratégie du service Currency indique qu’il accepte uniquement les jetons de sécurité émis par son propre service de jeton de sécurité.

Ici, nous partons du principe que les administrateurs d’Adventure456 et Business456 ont échangé des certificats de clé publique afin de fédérer la sécurité. Nous partons également du principe qu’Alice prend uniquement en charge la technologie de clé symétrique.

En fonction de la stratégie de service Currency Web, Alice doit acquérir un jeton de sécurité qui peut être utilisé pour accéder au service de jeton de sécurité sur Business456. Étant donné qu’Alice utilise des jetons de sécurité de clé symétrique, Alice contacte d’abord son service de jeton de sécurité pour acquérir un jeton de sécurité destiné au service de jeton de sécurité Business456. Notez que ce jeton de sécurité contiendra une clé symétrique, Sab, encodée avec la clé publique du service de jeton de sécurité Business456.

À l’aide du jeton de sécurité destiné au service de jeton de sécurité Business456, Alice demande un jeton de sécurité pour le service Currency. Le service de jeton de sécurité Business456 fournit à Alice une clé symétrique, Sac et un jeton de sécurité pour le service Currency.

À l’aide du jeton de sécurité destiné au service Currency et de la clé symétrique associée, Alice envoie des requêtes au service Currency.

Fédération à l’aide d’Un échange d’informations d’identification (KerberosKerberos)

Dans cette approche, Adventure456 a émis un jeton de sécurité Kerberos et la stratégie du service Currency indique qu’il accepte uniquement les jetons de sécurité Kerberos émis par son propre service de jeton de sécurité qui encapsule son KDC.

Ici, nous partons du principe que les administrateurs d’Adventure456 et Business456 ne veulent pas établir une confiance transitive inter-royaume, mais sont prêts à échanger des certificats de clé publique afin de fédérer la sécurité. En outre, nous partons du principe qu’Alice et le service Currency prennent uniquement en charge la technologie de clé symétrique.

Comme dans l’exemple précédent, les services de jeton de sécurité ont la possibilité de fournir des jetons de sécurité de clé symétrique aux services au sein de leur domaine d’approbation. Par conséquent, l’approche décrite ci-dessus fonctionne dans ce scénario.

Validation Service

Ce modèle de sécurité des services web prend également en charge les scénarios dans lesquels le demandeur externalise le traitement du message et de la validation des jetons de sécurité. Il convient de noter que l’utilisation incorrecte d’un tel service peut entraîner des problèmes de scalabilité. Autrement dit, en fonction de l’implémentation, il peut être moins coûteux ou plus coûteux pour le service d’effectuer le service de validation. Le modèle de sécurité des services Web prend en charge l’une ou l’autre approche, ce qui active ce scénario.

Dans ce scénario, nous avons séparé le service de validation du service de jeton de sécurité. Dans d’autres scénarios, ils peuvent être combinés ou avoir une relation d’approbation directe (ne nécessitant donc pas WS-Federation).

Dans ce scénario, le demandeur obtient un jeton de sécurité auprès du service de jeton de sécurité. Il envoie ensuite un message au service Web et inclut une preuve de possession (par exemple, une signature). Le service Web envoie le bloc de signature, le jeton de sécurité et son calcul de la synthèse qui a été signée au service de validation. Le service de validation, approuvé par le service web, émet ensuite une décision valide/non valide.

Il convient de noter que le service de validation peut indiquer sa décision en émettant un jeton de sécurité au nom du demandeur qui affirme les revendications appropriées.

Prise en charge de la délégation

La sécurité des services web prend en charge la délégation. Voici un scénario de délégation sophistiqué conçu pour montrer la flexibilité de l’approche : Alice utilise calendar456 pour gérer son planning. Elle veut permettre à Bob d’établir une réunion avec elle le mardi. Toutefois, Bob n’effectue pas la planification directement. Au lieu de cela, Bob utilise le service schedule456 pour configurer des réunions qui doivent être placées sur le calendrier d’Alice.

Alice ne sait pas comment Bob va planifier la réunion, mais elle veut limiter l’ensemble des services qui peuvent voir son calendrier

Alice fournit à Bob un jeton de sécurité qui lui permet de planifier des réunions sur son calendrier. Ce jeton de sécurité contient des revendications qui limitent la capacité de Bob à planifier des réunions au mardi. En outre, ce jeton de sécurité permet à Bob d’émettre des jetons de sécurité suivants tant que les sujets peuvent prouver qu’ils disposent d’une certification de confidentialité de TrustUs456, un service tiers.

Étant donné que le service Schedule456 a été audité par TrustUs456, ils disposent d’un jeton de sécurité qui affirme leur certification de confidentialité.

Lorsque le service de planification accède au calendrier d’Alice dans Calendar456, il peut prouver sa possession de sa certification de confidentialité et sa revendication d’accès et de planification d’une réunion en fonction des jetons de sécurité d’Alice, par le biais de Bob, à elle-même.

Contrôle d’accès

Tout en travaillant ensemble, Alice et Bob constatent qu’ils planifient fréquemment des réunions entre eux et développent un niveau de confiance. Par conséquent, Alice veut permettre à Bob de planifier des réunions sans avoir à lui déléguer à chaque fois. Elle pourrait augmenter l’expiration du jeton de sécurité de délégation, mais elle devra les réécrire, ce qui est problématique si elle veut annuler la capacité de Bob à planifier des réunions.

Alice communique avec son service de calendrier (s’authentifie) et obtient la liste d’autorisations. Elle met à jour la liste d’autorisations pour permettre à Bob de voir ses données de disponibilité et de planifier des réunions et de les soumettre au service. Maintenant, quand Bob accède à son service de calendrier pour ces opérations, il n’a pas besoin d’un jeton de sécurité de délégation d’Alice.

Audit

Dans le scénario de délégation ci-dessus, il est possible qu’un antagoniste tente de planifier une réunion sans jeton de sécurité de délégation ou avec un jeton de sécurité expiré. Dans ce cas, la demande échoue, car l’antagoniste ne peut pas prouver les revendications requises.

Pour suivre ce type d’activité, le service peut fournir des fonctionnalités d’audit. Autrement dit, lorsqu’un événement lié à la sécurité tel qu’une authentification, une revendication non prouvée ou une signature incorrecte se produit, il est journalisé. Un administrateur peut accéder en toute sécurité au journal pour passer en revue les événements liés à la sécurité et gérer le journal.

Par exemple, les antagonistes peuvent essayer d’imiter Bob. À l’aide d’un outil de supervision/gestion, l’administrateur de la sécurité, Carol, passe en revue le journal d’audit et constate que le calendrier d’Alice a rencontré un certain nombre d’échecs de sécurité. En examinant les données, elle constate que parfois la demande de Bob échoue parce que sa signature ne correspond pas au message ou que les messages sont anciens (rejoués). Par conséquent, Carol collecte les enregistrements d’audit à utiliser pour essayer de trouver les antagonistes.

5 Récapitulatif

À mesure que les services web sont appliqués de manière plus générale, que les topologies d’application continuent d’évoluer pour prendre en charge les intermédiaires tels que les pare-feu, les équilibreurs de charge et les hubs de messagerie, et que la connaissance des menaces auxquelles les organisations sont confrontées devient de plus en plus claire, le besoin de spécifications de sécurité supplémentaires pour les services Web devient évident.  Dans ce document, nous proposons un modèle de sécurité des services Web intégré et un ensemble de spécifications pour la réalisation de ce modèle. Ces nouvelles spécifications, en étendant et en tirant parti (plutôt que de remplacer) de la technologie et des ressources de sécurité existantes, permettront aux clients et aux organisations de développer plus rapidement des services Web sécurisés et interopérables.

IBM et Microsoft estiment qu’il s’agit de la première étape de 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. 

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; Joel Farrell, IBM; Praerit Garg, Microsoft; Maryann Hondo, IBM; Chris Kaler, Microsoft; Butler Lampson, Microsoft; Kelvin Lawrence, IBM; Andrew Layman, Microsoft; Paul Leach, Microsoft; John Manferdelli, Microsoft; Hiroshi Maruyama, IBM; Anthony Nadalin, IBM; Nataraj Nagaratnam, IBM; Rick Rashid, Microsoft; John Shewchuk, Microsoft; Dan Simon, Microsoft; Ajamu Wesley, IBM

Références