Architecture de sécurité

Article
02/27/2011

Cette section décrit les différents points d'extensibilité qui peuvent être utilisés pour modifier ou étendre les fonctionnalités du composant de sécurité Windows Communication Foundation (WCF). Pour comprendre ces points d'extensibilité, il est nécessaire de comprendre l'architecture de la sécurité WCF globale. Cette rubrique décrit l'architecture de sécurité WCF par rapport à ses composants et à leurs relations, et comment les points d'extensibilité décrits ultérieurement dans cette section s'intègrent dans le modèle d'architecture global.

Portée du composant de sécurité WCF

La sécurité WCF couvre plusieurs composants de l'architecture WCF. L'objectif principal de la sécurité dans WCF est d'assurer l'intégrité, la confidentialité, l'authentification, l'autorisation et l'audit des applications basées sur l'infrastructure WCF. L'architecture WCF répartit ces fonctions en trois catégories, comme suit :

Sécurité de transfert - chargée d'assurer la confidentialité des messages, l'intégrité des données et l'authentification des correspondants.
Autorisation - chargée de fournir une infrastructure permettant de prendre les décisions d'autorisation.
Audit - chargée d'enregistrer les événements relatifs à la sécurité dans le journal d'audit.

Modes de sécurité et portée de ce document

La sécurité de transfert peut être exécutée à l'aide de l'un des modes de sécurité suivants :

Transport Les trois fonctions de sécurité des communications sont fournies par le transport utilisé pour transmettre des messages entre le client et le service.
Message La sécurité de transfert est fournie uniquement au niveau du message SOAP, ce qui signifie que la sécurité est appliquée directement au message SOAP au niveau XML.
Transport avec informations d'identification de message La sécurité de transfert est effectuée sur les couches transport et message. La couche de transport assure la confidentialité des communications, l'intégrité des données et l'authentification du service. Le message assure l'authentification du client.

Les sections suivantes de ce document se concentrent sur le mode de sécurité Message, même si certaines des informations données s'appliquent également au mode Transport avec informations d'identification de message. Plus précisément, la partie de ce document qui s'applique à l'authentification du client s'applique également au mode Transport avec informations d'identification de message car ce mode utilise la couche de message pour effectuer l'authentification du client de la même manière que le mode Message.

Les informations relatives aux composants d'autorisation et d'audit s'appliquent de la même manière à l'ensemble des trois modes de sécurité. Par conséquent, toutes les informations relatives aux composants décrits dans ce document s'appliquent à tous les modes de sécurité pris en charge.

Concepts du mode de sécurité Message

Modèle WS-Security

Le mode de sécurité Message s'appuie sur la spécification WS-Security. La spécification WS-Security définit une infrastructure qui permet d'appliquer la sécurité aux messages SOAP. Elle spécifie un modèle de sécurité de message utilisant des jetons de sécurité combinés au chiffrement et aux signatures numériques afin de protéger et d'authentifier les messages SOAP. Pour la spécification, consultez Sécurité des services Web (WS-Security).

Terminologie

Un jeton de sécurité déclare des revendications et permet de déclarer la liaison entre les clés ou secrets d'authentification et les identités de sécurité.

Une revendication est une déclaration émise par une entité concernant une entité (par exemple, un nom, une identité, un groupe, une clé ou un privilège). L'entité qui émet la revendication est désignée par le terme émetteur de revendication ; l'entité à propos de laquelle la revendication est émise est désignée par le terme sujet de revendication.

Un émetteur de revendication peut se porter garant de ou approuver les revendications dans un jeton de sécurité en utilisant sa clé pour le signer ou le chiffrer. Cela active l'authentification des revendications dans le jeton de sécurité.

Les signatures de message permettent de vérifier l'origine et l'intégrité des messages. Elles permettent également aux producteurs de message de démontrer qu'ils connaissent la clé, en général d'un tiers, utilisée pour confirmer les revendications dans un jeton de sécurité et lier ainsi leur identité (et les autres revendications représentées par le jeton de sécurité) aux messages qu'ils créent.

Jetons de sécurité

WS-Security définit plusieurs types de jetons de sécurité et fournit un modèle extensible qui permet de définir indépendamment d'autres types de jetons de sécurité. Chaque définition de type de jeton contient une sérialisation XML du jeton. Cela permet d'ajouter directement la représentation de jeton au message.

WS-Security inclut notamment les types de jetons de sécurité suivants :

Jeton de nom d'utilisateur.
Jeton de certificat X.509.
Jeton Kerberos.
Jeton SAML.

Il existe quatre façons d'utiliser les jetons et les jetons joints à un message donné appartiennent exactement à l'une des trois catégories suivantes :

SignedSupporting
SignedEndorsing
SignedEncrypted
EncryptedEndorsing

Dans .NET Framework 3.0, un message client peut contenir un seul jeton de tout type donné, mais peut contenir des jetons de types différents.

Dans .NET Framework 3.5, les messages client peuvent contenir plusieurs jetons d'un type donné ainsi que des jetons de types différents.

Cette fonction permet plusieurs scénarios, dont le scénario suivant :

Envoi de revendication incrémentielle. Toutes les opérations sur un service peuvent nécessiter la présence d'un jeu de revendications, mais certaines opérations peuvent exiger des revendications supplémentaires. Plutôt que d'utiliser des jetons émis distincts pour chaque opération, le client peut obtenir un jeton émis avec le jeu initial des revendications et utiliser un autre jeton émis avec le reste des revendications nécessaires pour l'opération appelée.
Authentification multifacteur. Lorsque le client doit rassembler des jetons émis à partir d'émetteurs multiples ou avec différents jeux de revendications avant d'être autorisé à effectuer une opération. WCF traite le jeton émis comme un type de jeton. Ce scénario exige de pouvoir disposer de deux jetons émis de prise en charge dans le message.

Notez que vous ne pouvez pas configurer un service ainsi : un service peut contenir un seul jeton de prise en charge.

Pour plus d'informations, consultez Comment : utiliser plusieurs jetons de sécurité du même type.

Implémentation WS-Security

WS-Security établissant une base pour la sécurité de message, l'implémentation WCF de WS-Security est un élément essentiel de l'ensemble du mode de sécurité Message. Pour étendre les fonctionnalités du mode de sécurité Message, il est nécessaire de comprendre comment l'implémentation WS-Security fonctionne.

L'implémentation WS-Security dans WCF gère les éléments suivants :

Sérialisation de jetons de sécurité vers et à partir de messages SOAP.
Authentification de jetons de sécurité.
Application et vérification de signatures de message.
Chiffrement et déchiffrement de messages SOAP.

Les points d'extensibilité WCF permettent la personnalisation des deux premiers éléments. Il est possible de modifier la sérialisation de jetons de sécurité existants ou la façon dont la sécurité WCF authentifie ces jetons. Il est également possible d'introduire des types de jetons de sécurité totalement nouveaux dans la sécurité WCF, y compris les fonctionnalités de sérialisation et d'authentification.

Les rubriques suivantes de cette section expliquent de quelle façon les points d'extensibilité de l'implémentation WS-Security permettent de personnaliser les fonctionnalités des jetons de sécurité.

Autorisation

Les jetons de sécurité sont désérialisés du message entrant et sont authentifiés. Le processus d'authentification génère un jeu d'objets de stratégie d'autorisation. Chaque objet représente une partie des données du jeton de sécurité. Ces données sont utilisées lors de l'étape d'autorisation.

La stratégie d'autorisation crée un ensemble de revendications représenté par un jeton de sécurité. Cet ensemble de revendications est ensuite fourni pour les décisions d'autorisation à ServiceAuthorizationManager et à la logique à l'intérieur de la propriété AuthorizationContext.

Identité

Outre les revendications, WCF crée une implémentation de l'interface IIdentity pour représenter l'appelant auprès de l'infrastructure existante (créée par le modèle de sécurité .NET Framework). Cette instance IIdentity représente soit l'identité Windows de l'appelant si le jeton de sécurité est mappé à un compte Windows, soit une identité principale qui contient le nom de l'appelant. Ces identités sont également accessibles à l'aide de ServiceSecurityContext. (Pour plus d'informations, consultez Comment : examiner le contexte de sécurité.) Il est possible de personnaliser la façon dont les identités sont créées dans WCF en utilisant l'une des méthodes suivantes :

Implémentation d'une extension personnalisée de la classe SecurityTokenAuthenticator.
Intégration avec ASP.NET en étendant la classe MembershipProvider ou en créant une implémentation IAuthorizationPolicy personnalisée et en la branchant dans ServiceAuthorizationManager.
Création d'un IAuthorizationPolicy personnalisé.

Le fournisseur d'appartenances personnalisé fonctionne uniquement si l'authentification par nom d'utilisateur/mot de passe est utilisée pour authentifier l'appelant. L'objet MembershipProvider valide la paire nom d'utilisateur/mot de passe. Si elle est valide, WCF crée une identité principale qui représente l'appelant authentifié après la validation MembershipProvider.

Pour faciliter l'intégration avec l'infrastructure de sécurité .NET Framework existante, WCF affecte par défaut une instance IPrincipal représentant l'appelant à la propriété CurrentPrincipal. L'instance IPrincipal est créée en fonction des informations contenues dans le IIdentitygénéré.

IIdentity peut être augmenté davantage par intégration avec le RoleProvider ASP.NET. RoleProvider ajoute le jeu des rôles auxquels l'appelant appartient. La logique d'autorisation utilise ces informations pour prendre la décision d'accès.

Pour plus d'informations sur le sujet suivant l'identité, consultez Identité du service et authentification.

Envoi de messages sécurisés

L'illustration suivante indique comment un message est sécurisé du côté client lors de l'utilisation du mode de sécurité Message. Elle présente les composants impliqués et les relations qu'ils entretiennent les uns avec les autres.

Le code d'application exécute et génère un message.
Dans l'étape de fourniture des jetons, les informations d'identification du client (telles que les certificats X.509) sont jointes. Dans un scénario fédéré, un émetteur de jeton est contacté pour fournir les informations d'identification.
Les informations d'identification sont utilisées pour créer le jeton de sécurité.
Dans l'étape d'authentification des jetons, les jetons sont vérifiés.
Enfin, les jetons de sécurité sont sérialisés et envoyés.

Envoi d'un message sécurisé

Réception de messages sécurisés

L'illustration suivante montre les processus qui se produisent lorsqu'un message sécurisé est extrait du câble et est vérifié du côté réception.

Les jetons de sécurité sont désérialisés et traités dans l'étape d'authentification. Le cas échéant, un fournisseur d'appartenances ASP.NET peut être utilisé à ce stade pour fournir des noms d'utilisateur et des mots de passe.
Une fois l'authentification terminée, les stratégies d'autorisation sont extraites.
Dans l'étape d'évaluation des stratégies d'autorisation, les stratégies d'autorisation sont évaluées et des revendications peuvent être ajoutées à un contexte d'évaluation. Les stratégies d'autorisation externes sont également utilisées à ce stade. Cette étape, ainsi que l'étape suivante, est effectuée par les méthodes de ServiceAuthorizationManager.
Dans l'étape d'autorisation du service, les autorisations correctes sont données en fonction des revendications ajoutées par les stratégies d'autorisation. Cette étape est effectuée par la méthode du ServiceAuthorizationManager.
Une fois l'autorisation terminée, l'emprunt d'identité d'appelant se produit si l'appelant l'a autorisé et que la méthode de service le requiert, ou si la propriété ImpersonateCallerForAllOperations est définie sur le comportement d'autorisation de service. Pour plus d'informations, consultez Délégation et emprunt d'identité avec WCF.
WCF génère à ce stade un PrincipalPermission à l'aide des informations d'identification. Si nécessaire, un fournisseur de rôles ASP.NET peut être utilisé à ce stade.
Le code d'application s'exécute.

Réception d'un message sécurisé

Vue d'ensemble des points d'extensibilité de sécurité

L'illustration suivante présente les points d'extensibilité fournis par les composants de sécurité WCF. Elle est divisée en quatre catégories différentes selon le moment auquel le point d'extensibilité est atteint lors du traitement du message. Ces catégories mappent vers les étapes du traitement de sécurité des messages, tel que décrit dans les deux sections précédentes. La figure indique également que les technologies d'infrastructure existantes peuvent être intégrées avec la sécurité WCF.

Points d'extensibilité de la sécurité WCF

Voir aussi

Partager via