Sécurisation de services

  • Article

La sécurité d’un service WCF (Windows Communication Foundation) passe par deux spécifications principales : la sécurité de transfert et l’autorisation. (Une troisième spécification, l’audit des événements de sécurité, est décrite dans Audit.) En résumé, la sécurité de transfert regroupe l’authentification (vérification de l’identité du service et du client), la confidentialité (chiffrement des messages) et l’intégrité (signature numérique afin de détecter la falsification). L'autorisation est le contrôle d'accès aux ressources, par exemple en autorisant uniquement les utilisateurs privilégiés à lire un fichier. Ces deux spécifications principales peuvent être facilement implémentées à l’aide des fonctionnalités de WCF.

À l’exception de la classe BasicHttpBinding (ou de l’élément <basicHttpBinding> de la configuration), la sécurité de transfert est activée par défaut pour toutes les liaisons prédéfinies. Les rubriques de cette section présentent deux scénarios de base : implémentation de la sécurité de transfert et de l'autorisation sur un service intranet hébergé sur IIS (Internet Information Services) et implémentation de la sécurité de transfert et de l'autorisation sur un service hébergé sur IIS.

Concepts de base de la sécurité

La sécurité repose sur des informations d'identification. Les informations d'identification prouvent qu'une entité est bien celle qu'elle prétend être. (Une entité peut être une personne, un processus logiciel, une entreprise ou tout ce qui peut être autorisé.) Par exemple, un client d’un service fait une revendication d’identité, et les informations d’identification prouvent cette revendication d’une certaine manière. Dans un scénario typique, un échange d'informations d'identification se produit. Tout d'abord, un service fait une revendication de son identité et la prouve au client avec des informations d'identification. À son tour, le client fait une revendication d'identité et présente des informations d'identification au service. Si les deux partis approuvent les informations d'identification de l'autre parti, un nouveau contexte de sécurité peut être établi dans lequel tous les messages sont échangés en toute confidentialité et sont signés afin de protéger leur intégrité. Une fois que la service a établi l'identité du client, il peut mettre en correspondre les revendications des informations d'identification à un rôle ou une appartenance à un groupe. Dans les deux cas, à l'aide du rôle ou du groupe auquel le client appartient, le service autorise le client à exécuter un jeu limité d'opérations qui dépend des privilèges du rôle ou du groupe.

Mécanismes de la sécurité Windows

Si l'ordinateur client et l'ordinateur de service se trouvent tous deux dans un domaine Windows qui requiert que tous deux se connectent au réseau, les informations d'identification sont fournies par l'infrastructure Windows. Dans ce cas, les informations d'identification sont établies lorsqu'un utilisateur se connecte au réseau. Chaque utilisateur et chaque ordinateur du réseau doit être validé comme appartenant au jeu approuvé d'utilisateurs et d'ordinateurs. Sur un système Windows, chacun de ces utilisateurs et ordinateurs est également appelé principal de sécurité.

Sur un domaine Windows assorti d'un contrôleur Kerberos , le contrôleur Kerberos utilise un schéma reposant sur l'octroi de tickets à chaque principal de sécurité. Les tickets octroyés par le contrôleur sont approuvés par d'autres octroyeurs de tickets du système. Dès lors qu'une entité essaie d'exécuter une opération ou d'accéder à une ressource (comme un fichier ou un répertoire sur un ordinateur), la validité du ticket est vérifiée et, si elle est établie, un autre ticket est fourni à la principal de sécurité pour cette opération. Cette méthode d'octroi de tickets est plus efficace que l'autre solution qui consiste à essayer de valider l'entité principale pour chaque opération.

Un mécanisme plus ancien et moins sécurisé est utilisé sur les domaines Windows ; il s'agit de NT LAN Manager (NTLM). Lorsque Kerberos ne peut pas être utilisé (généralement à l'extérieur d'un domaine Windows, comme dans un groupe de travail), NTLM peut être utilisé à la place. NTLM est également disponible comme option de sécurité d'IIS.

Sur un système Windows, l'autorisation consiste à assigner chaque ordinateur et utilisateur à un jeu de rôles et de groupes. Par exemple, chaque ordinateur Windows doit être configuré et contrôlé par une personne (ou un groupe de personnes) ayant le rôle d' administrateur. Il existe également un autre rôle, celui d' utilisateur, qui dispose d'un jeu beaucoup plus limité d'autorisations. Outre le rôle, les utilisateurs sont assignés à des groupes. Un groupe permet à plusieurs utilisateurs de travailler avec le même rôle. Dans la pratique, un ordinateur Windows est par conséquent administré en assignant des utilisateurs à des groupes. Par exemple, plusieurs utilisateurs peuvent être assignés au groupe d'utilisateurs d'un ordinateur et un jeu beaucoup plus limité d'utilisateurs peut être assigné au groupe des administrateurs. Sur un ordinateur local, un administrateur peut également créer des groupes et assigner d'autres utilisateurs (voire d'autres groupes) à ces groupes.

Sur un ordinateur qui exécute Windows, chaque dossier d'un répertoire peut être protégé. Autrement dit, vous pouvez sélectionner un dossier et contrôler qui peut accéder aux fichiers et si ces utilisateurs peuvent ou non copier, modifier ou supprimer un fichier, ou encore ajouter des fichiers au dossier. Il s'agit du contrôle d'accès. Le mécanisme associé est appelé la liste de contrôle d'accès (ACL, Access Control List). Lors de la création de l'ACL, vous pouvez assigner des privilèges d'accès à tout groupe, de même qu'aux membres individuels d'un domaine.

L’infrastructure WCF est conçue pour utiliser ces mécanismes de sécurité Windows. Par conséquent, si vous créez un service déployé sur un intranet dont les clients sont limités aux membres du domaine Windows, la sécurité est facilement implémentée. Seuls les utilisateurs valides peuvent se connecter au domaine. Une fois les utilisateurs connectés, le contrôleur Kerberos permet à chaque utilisateur d'établir des contextes de sécurité avec tout autre ordinateur ou application. Sur un ordinateur local, des groupes peuvent facilement être créés, et lors de la protection de dossiers spécifiques, ces groupes peuvent être utilisés pour assigner des privilèges d'accès sur l'ordinateur.

Implémentation de la sécurité Windows sur des services intranet

Pour sécuriser une application qui s'exécute exclusivement sur un domaine Windows, vous pouvez utiliser les paramètres de sécurité par défaut de la liaison WSHttpBinding ou NetTcpBinding . Par défaut, tout utilisateur se trouvant sur ce même domaine Windows peut accéder aux services WCF. Ces utilisateurs s'étant connectés au réseau, ils sont approuvés. Les messages entre un service et un client sont chiffrés à des fins de confidentialité et archivés à des fins d'intégrité. Pour plus d’informations sur la création d’un service qui utilise la sécurité Windows, consultez Procédure pour sécuriser un service avec des informations d’identification Windows.

Autorisation à l'aide de la classe PrincipalPermissionAttribute

Si vous devez limiter l'accès aux ressources d'un ordinateur, le moyen le plus simple est d'utiliser la classe PrincipalPermissionAttribute . Cet attribut vous permet de limiter l'invocation des opérations de service en exigeant que l'utilisateur appartienne à un groupe ou un rôle Windows spécifique ou qu'il soit un utilisateur spécifique. Pour plus d’informations, consultez Guide pratique pour restreindre l’accès avec la classe PrincipalPermissionAttribute.

Emprunt d'identité

L'emprunt d'identité est un autre mécanisme que vous pouvez utiliser pour contrôler l'accès aux ressources. Par défaut, un service hébergé par IIS s'exécutera sous l'identité du compte ASPNET. Le compte ASPNET peut accéder uniquement aux ressources pour lesquelles il possède une autorisation. Toutefois, il est possible de définir l'ACL pour un dossier de manière à exclure le compte de service ASPNET tout en autorisant certaines autres identités à accéder au dossier. Reste ensuite à savoir comment autoriser ces utilisateurs à accéder au dossier si le compte ASPNET n'y est pas autorisé. La solution consiste à utiliser l'emprunt d'identité. Le service est alors autorisé à utiliser les informations d'identification du client pour accéder à une ressource particulière. L'accès à une base de données SQL Server à laquelle seuls certains utilisateurs sont autorisés à accéder est un autre exemple. Pour plus d’informations sur l’utilisation de l’emprunt d’identité, consultez Guide pratique pour emprunter l’identité d’un client sur un service et Délégation et emprunt d’identité.

Sécurité sur Internet

La sécurité sur Internet revêt les mêmes spécifications que la sécurité sur un intranet. Un service doit présenter ses informations d'identification pour prouver son authenticité, et les clients doivent prouver leur identité au service. Une fois l'identité d'un client prouvée, le service peut contrôler le niveau d'accès du client aux ressources. Toutefois, en raison de la nature hétérogène d'Internet, les informations d'identification présentées diffèrent de celles utilisées sur un domaine Windows. Alors qu'un contrôleur Kerberos gère l'authentification des utilisateurs sur un domaine avec des tickets pour les informations d'identification, sur Internet, les services et les clients peuvent utiliser de nombreuses méthodes pour présenter les informations d'identification. Toutefois, l’objectif de cette rubrique est de présenter une approche commune pour vous permettre de créer un service WCF accessible sur Internet.

Utilisation d'IIS et d'ASP.NET

Les spécifications de la sécurité Internet, tout comme les mécanismes de résolution de ces problèmes, ne sont pas nouveaux. IIS est le serveur web de Microsoft pour Internet. Il propose de nombreuses fonctionnalités de sécurité permettant de traiter de ces problèmes. Par ailleurs, ASP.NET inclut des fonctionnalités de sécurité que les services WCF peuvent utiliser. Pour tirer parti de ces fonctionnalités de sécurité, vous devez héberger un service WCF sur IIS.

Utilisation de fournisseurs d'appartenances et de rôles ASP.NET

ASP.NET inclut un fournisseur d'appartenances et de rôles. Ce fournisseur est une base de données de paires nom d'utilisateur/mot de passe utilisées pour l'authentification des appelants, qui vous permet également de spécifier les privilèges d'accès de chaque appelant. Avec WCF, vous pouvez facilement utiliser un fournisseur d’appartenances et de rôles préexistant à travers la configuration. Pour obtenir un exemple d'application démontrant ces propos, consultez l'exemple Membership and Role Provider .

Informations d'identification utilisées par IIS

À la différence d'un domaine Windows assorti d'un contrôleur Kerberos, Internet est un environnement qui ne dispose d'aucun contrôleur pour gérer les millions d'utilisateurs qui se connectent à tout moment. Au lieu de cela, les informations d'identification sur Internet ont très souvent la forme de certificats X.509 (également appelés certificats Secure Sockets Layer ou SSL). Ces certificats sont généralement émis par une autorité de certification, qui peut être une société tierce qui se porte garant de l'authenticité du certificat et de la personne pour laquelle il a été émis. Pour exposer votre service sur Internet, vous devez également fournir un tel certificat approuvé pour authentifier votre service.

Là se pose la question suivante : comment obtenir un tel certificat ? Une approche consiste à s'adresser à une autorité de certification tierce, telle qu'Authenticode ou VeriSign, lorsque vous êtes prêt à déployer votre service et à acheter un certificat pour votre service. Toutefois, si votre service WCF est en cours de développement et que vous n’êtes pas encore prêt à acheter un certificat, il existe des outils et des techniques pour créer des certificats X.509 que vous pouvez utiliser pour simuler un déploiement en production. Pour plus d’informations, consultez Utilisation des certificats.

Modes de sécurité

La programmation de la sécurité WCF implique quelques points de décision essentiels. L'un des plus basiques est le choix du mode de sécurité. Les deux principaux modes de sécurité sont le mode de transport et le mode de message.

Un troisième mode, qui combine la sémantique des deux principaux modes, est le mode de transport avec informations d'identification de message.

Le mode de sécurité détermine de quelle manière les messages sont sécurisés. Chaque mode présente des avantages et des inconvénients, comme expliqué ci-après. Pour plus d’informations sur la définition du mode de sécurité, consultez Guide pratique pour définir le mode de sécurité.

mode de transport

Il existe plusieurs couches entre le réseau et l'application. L’une d’elles est la couche de transport*,* qui gère le transfert de messages entre des points de terminaison. Pour ce qui nous concerne, il suffit que vous compreniez que WCF utilise plusieurs protocoles de transport, chacun pouvant sécuriser le transfert de messages. (Pour plus d’informations sur les transports, consultez Transports.)

Le protocole HTTP est très largement utilisé. Il en existe un autre, le protocole TCP. Chacun de ces protocoles peut sécuriser le transfert de messages par un ou plusieurs mécanismes propres au protocole. Par exemple, le protocole HTTP est sécurisé à l’aide du protocole SSL sur HTTP, généralement abrégé en « HTTPS ». Ainsi, lorsque vous sélectionnez le mode de transport pour la sécurité, vous choisissez d’utiliser le mécanisme comme indiqué par le protocole. Par exemple, si vous sélectionnez la classe WSHttpBinding et lui assignez le mode de sécurité Transport, vous sélectionnez SSL sur HTTP (HTTPS) comme mécanisme de sécurité. Le mode de transport présente l'avantage d'être plus efficace que le mode de message car la sécurité est intégrée à un niveau comparativement bas. Si le mode de transport est utilisé, le mécanisme de sécurité doit être implémenté conformément à la spécification du transport. Les messages peuvent donc transiter en toute sécurité en allant uniquement d'un point à un autre sur le transport.

mode de message

Par opposition, le mode de message assure la sécurité en incluant les données de sécurité dans chaque message. Avec l'utilisation des en-têtes de sécurité XML et SOAP, les informations d'identification et autres données nécessaires pour assurer l'intégrité et la confidentialité du message sont incluses dans chaque message. Chaque message inclut des données de sécurité, ce qui a un impact sur les performances dans la mesure où chaque message doit être traité individuellement. (En mode de transport, une fois la couche de transport sécurisée, tous les messages circulent librement.) Toutefois, la sécurité des messages présente un avantage par rapport à la sécurité du transport : elle est plus flexible. En effet, les spécifications de sécurité ne sont pas déterminées par le transport. Vous pouvez utiliser tout type d'informations d'identification du client pour sécuriser le message. (En mode de transport, le protocole de transport détermine le type d'informations d'identification du client que vous pouvez utiliser.)

Transport avec informations d'identification de message

Le troisième mode combine le meilleur de la sécurité de transport et de la sécurité de message. Dans ce mode, la sécurité de transport est utilisée pour garantir efficacement la confidentialité et l'intégrité de chaque message. En même temps, chaque message inclut ses propres informations d'identification, ce qui permet au message d'être authentifié. Avec l'authentification, l'autorisation peut également être implémentée. En authentifiant un expéditeur, l'accès aux ressources peut être accordé (ou refusé) en fonction de l'identité de l'expéditeur.

Spécification du type d'informations d'identification du client et de la valeur des informations d'identification

Après avoir sélectionné un mode de sécurité, vous voudrez sans doute spécifier un type d'informations d'identification du client. Le type d'informations d'identification du client spécifie quel type un client doit utiliser pour s'authentifier auprès du serveur.

Un type d'informations d'identification du client n'est pas requis dans tous les scénarios. Avec SSL sur HTTP (HTTPS), un service s'authentifie auprès du client. Dans le cadre de cette authentification, le certificat du service est envoyé au client dans un processus appelé négociation. Le transport sécurisé par SSL garantit que tous les messages sont confidentiels.

Si vous créez un service qui requiert l'authentification du client, le type d'informations d'identification du client que vous choisirez dépend du transport et du mode sélectionnés. Par exemple, l'utilisation du transport HTTP et la sélection du mode de transport vous laissent différents choix, comme Basic ou Digest. (Pour plus d’informations sur ces types d’informations d’identification, consultez Présentation de l’authentification HTTP.)

Si vous créez un service sur un domaine Windows qui sera uniquement disponible pour d'autres utilisateurs du réseau, le plus facile à utiliser est le type d'informations d'identification du client Windows. Toutefois, vous pouvez également avoir besoin de fournir un service avec un certificat. Pour cela, consultez How to: Specify Client Credential Values.

Valeurs d'informations d'identification

Une valeur d'informations d'identification représente les informations d'identification utilisées par le service. Après avoir spécifié un type d'informations d'identification, vous pouvez également avoir besoin de configurer votre service avec les informations d'identification réelles. Si vous avez sélectionné Windows (et si le service s'exécutera sur un domaine Windows), vous ne spécifiez pas de valeur d'informations d'identification réelle.

Identité

Dans WCF, le terme identité a des significations différentes pour le serveur et pour le client. Brièvement, lors de l'exécution d'un service, une identité est assignée au contexte de sécurité après l'authentification. Pour afficher l'identité réelle, vérifiez les propriétés WindowsIdentity et PrimaryIdentity de la classe ServiceSecurityContext . Pour plus d’informations, consultez Guide pratique pour examiner le contexte de sécurité.

Par opposition, sur le client, l'identité est utilisée pour valider le service. Au moment du design, un développeur client peut affecter à l’élément <identity> une valeur délivrée par le service. Au moment de l'exécution, le client vérifie la valeur de l'élément par rapport à l'identité réelle du service. Si la vérification échoue, le client termine la communication. La valeur peut être un nom d'utilisateur principal (UPN, User Principal Name) si le service s'exécute sous l'identité d'un utilisateur particulier ou un nom de principal du service (SPN, Service Principal Name) si le service s'exécute sous un compte d'ordinateur. Pour plus d’informations, consultez Identité du service et authentification. Les informations d'identification peuvent également être un certificat ou un champ d'un certificat qui identifie le certificat.

Niveaux de protection

La propriété ProtectionLevel est présente sur plusieurs classes d'attributs (telles que les classes ServiceContractAttribute et OperationContractAttribute ). Le niveau de protection est une valeur qui spécifie si les messages (ou parties de messages) qui prennent en charge un service sont signés, signés et chiffrés, ou envoyés sans signature ou chiffrement. Pour plus d’informations sur la propriété, consultez Fonctionnement des niveaux de protection, et pour obtenir des exemples de programmation, consultez Guide pratique pour définir la propriété ProtectionLevel. Pour plus d’informations sur la conception d’un contrat de service avec ProtectionLevel en contexte, consultez Conception de contrats de service.

Voir aussi