Partager via

Sécurisation des services

La sécurité d’un service Windows Communication Foundation (WCF) se compose de deux exigences principales : la sécurité et l’autorisation de transfert. (Une troisième exigence, l’audit des événements de sécurité, est décrit dans Audit.) En bref, la sécurité des transferts inclut l’authentification (vérification de l’identité du service et du client), la confidentialité (chiffrement des messages) et l’intégrité (signature numérique pour détecter la falsification). L’autorisation est le contrôle de l’accès aux ressources, par exemple, permettant uniquement aux utilisateurs privilégiés de lire un fichier. À l’aide des fonctionnalités de WCF, les deux exigences principales sont facilement implémentées.

À l’exception de la BasicHttpBinding classe (ou de l’élément basicHttpBinding< dans 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 couvrent deux scénarios de base : implémentation de la sécurité et de l’autorisation de transfert sur un service intranet hébergé sur Internet Information Services (IIS) et implémentation de la sécurité et de l’autorisation de transfert sur un service hébergé sur IIS.

Principes de base de la sécurité

La sécurité s’appuie sur les informations d’identification. Un justificatif atteste qu’une entité est 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 revendicationd’identité et les informations d’identification prouvent cette revendication d’une certaine manière. Dans un scénario classique, un échange d’informations d’identification se produit. Tout d’abord, un service fait une revendication de son identité et le prouve au client avec des informations d’identification. À l’inverse, le client fait une revendication d’identité et présente des informations d’identification au service. Si les deux parties approuvent les informations d’identification de l’autre, un contexte sécurisé peut être établi dans lequel tous les messages sont échangés en confidentialité et tous les messages sont signés pour protéger leur intégrité. Une fois que le service a établi l’identité du client, il peut ensuite faire correspondre les revendications dans les informations d’identification à un rôle ou à l’appartenance à un groupe. Dans les deux cas, en utilisant le rôle ou le groupe auquel appartient le client, le service autorise le client à effectuer un ensemble limité d’opérations en fonction du rôle ou des privilèges de groupe.

Mécanismes de sécurité Windows

Si le client et l’ordinateur de service se trouvent tous les deux sur un domaine Windows qui nécessite que les 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 de l’ordinateur se connecte au réseau. Chaque utilisateur et chaque ordinateur du réseau doivent être validés comme appartenant à l’ensemble approuvé d’utilisateurs et d’ordinateurs. Sur un système Windows, chaque utilisateur et ordinateur de ce type est également appelé principal de sécurité.

Sur un domaine Windows soutenu par un contrôleur Kerberos , le contrôleur Kerberos utilise un schéma basé sur l’octroi de tickets à chaque principal de sécurité. Les tickets accordés par le contrôleur sont approuvés par d’autres bénéficiaires de tickets dans le système. Chaque fois qu’une entité tente d’effectuer une opération ou d’accéder à une ressource (par exemple, un fichier ou un répertoire sur un ordinateur), le ticket est examiné pour sa validité et, s’il réussit, le principal reçoit un autre ticket pour l’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é utilisé sur les domaines Windows est NT LAN Manager (NTLM). Dans les cas où Kerberos ne peut pas être utilisé (généralement en dehors d’un domaine Windows, par exemple dans un groupe de travail), NTLM peut être utilisé comme alternative. NTLM est également disponible en tant qu’option de sécurité pour IIS.

Sur un système Windows, l’autorisation fonctionne en affectant chaque ordinateur et chaque utilisateur à un ensemble 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) dans le rôle de l’administrateur. Un autre rôle est celui de l’utilisateur, qui a un ensemble beaucoup plus limité d’autorisations. En plus du rôle, les utilisateurs sont affectés à des groupes. Un groupe permet à plusieurs utilisateurs d’effectuer le même rôle. Dans la pratique, par conséquent, un ordinateur Windows est administré en affectant des utilisateurs à des groupes. Par exemple, plusieurs utilisateurs peuvent être affectés au groupe d’utilisateurs d’un ordinateur, et un ensemble beaucoup plus restreint d’utilisateurs peut être affecté au groupe d’administrateurs. Sur un ordinateur local, un administrateur peut également créer de nouveaux groupes et affecter d’autres utilisateurs (ou même d’autres groupes) au groupe.

Sur un ordinateur exécutant 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 savoir s’ils peuvent copier ou non le fichier, ou (dans le cas le plus privilégié) modifier un fichier, supprimer un fichier ou ajouter des fichiers au dossier. Il s’agit du contrôle d’accès, et le mécanisme pour lequel il est appelé liste de contrôle d’accès (ACL). Lors de la création de la liste de contrôle d’accès, vous pouvez attribuer des privilèges d’accès à n’importe quel groupe ou groupe, ainsi qu’à des 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 et 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 sécurisés avec n’importe quel autre ordinateur ou application. Sur une machine locale, les groupes peuvent être facilement créés et, lors de la protection de dossiers spécifiques, ces groupes peuvent être utilisés pour attribuer des privilèges d’accès sur l’ordinateur.

Implémentation de la sécurité Windows sur les 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 de la liaison NetTcpBinding. Par défaut, toute personne sur le même domaine Windows peut accéder aux services WCF. Étant donné que ces utilisateurs se sont connectés au réseau, ils sont approuvés. Les messages entre un service et un client sont chiffrés pour la confidentialité et signés pour l’intégrité. Pour plus d’informations sur la création d’un service qui utilise la sécurité Windows, consultez Guide pratique pour sécuriser un service avec les informations d’identification Windows.

Autorisation à l’aide de la classe PrincipalPermissionAttribute

Si vous devez restreindre l’accès aux ressources sur un ordinateur, le moyen le plus simple consiste à utiliser la PrincipalPermissionAttribute classe. Cet attribut vous permet de restreindre l’appel des opérations de service en exigeant que l’utilisateur soit dans un groupe ou un rôle Windows spécifié, ou pour être un utilisateur spécifique. Pour plus d’informations, consultez Guide pratique pour restreindre l’accès avec la classe PrincipalPermissionAttribute.

Usurpation 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écute sous l’identité du compte ASPNET. Le compte ASPNET peut accéder uniquement aux ressources pour lesquelles il a l’autorisation. Toutefois, il est possible de définir la liste de contrôle d’accès d’un dossier pour exclure le compte de service ASPNET, mais d’autoriser certains autres identités à accéder au dossier. La question devient ensuite comment autoriser ces utilisateurs à accéder au dossier si le compte ASPNET n’est pas autorisé à le faire. La réponse consiste à utiliser l’emprunt d’identité, dans lequel le service est autorisé à utiliser les informations d’identification du client pour accéder à une ressource particulière. Un autre exemple est l’accès à une base de données SQL Server à laquelle seuls certains utilisateurs disposent d’autorisations. 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 se compose des mêmes exigences 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 l’accès au 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 d’informations d’identification, sur Internet, les services et les clients s’appuient sur l’une des différentes façons de présenter des informations d’identification. Toutefois, l’objectif de cette rubrique est de présenter une approche commune qui vous permet de créer un service WCF accessible sur Internet.

Utilisation d’IIS et de ASP.NET

Les exigences de sécurité Internet et les mécanismes permettant de résoudre ces problèmes ne sont pas nouveaux. IIS est le serveur web de Microsoft pour Internet et dispose de nombreuses fonctionnalités de sécurité qui répondent à ces problèmes ; en outre, 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é, hébergez un service WCF sur IIS.

Utilisation des fournisseurs d’appartenance et de rôle ASP.NET

ASP.NET inclut un fournisseur d’appartenance et de rôle. Le fournisseur est une base de données de paires nom d’utilisateur/mot de passe 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’appartenance et de rôle préexistant par le biais de la configuration. Pour obtenir un exemple d'application illustrant cela, consultez l'exemple Membership and Role Provider.

Informations d’identification utilisées par IIS

Contrairement à un domaine Windows soutenu par un contrôleur Kerberos, Internet est un environnement sans contrôleur unique pour gérer les millions d’utilisateurs qui se connectent à tout moment. Au lieu de cela, les informations d’identification sur Internet se présentent le plus souvent sous la forme de certificats X.509 (également appelés certificats SSL, 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 vérifie l’authenticité du certificat et la personne à laquelle elle a été émise. Pour exposer votre service sur Internet, vous devez également fournir un tel certificat approuvé pour authentifier votre service.

La question se pose à ce stade, comment obtenir un tel certificat ? Une approche consiste à accéder à 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 vous êtes en phase de développement avec WCF et que vous n’êtes pas encore prêt à vous engager à acheter un certificat, des outils et des techniques existent pour créer des certificats X.509 que vous pouvez utiliser pour simuler un déploiement de 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 critiques. L’un des plus fondamentaux est le choix du mode de sécurité. Les deux principaux modes de sécurité sont le mode de transport et le mode message.

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

Le mode de sécurité détermine comment les messages sont sécurisés, et chaque choix présente des avantages et des inconvénients, comme expliqué ci-dessous. 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 les points de terminaison. À cet effet, il n’est nécessaire 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.)

Un protocole couramment utilisé est HTTP ; un autre est TCP. Chacun de ces protocoles peut sécuriser le transfert de messages par un mécanisme (ou des mécanismes) particulier au protocole. Par exemple, le protocole HTTP est sécurisé à l’aide du protocole SSL via HTTP, généralement abrégé en tant que « HTTPS ». Par conséquent, lorsque vous sélectionnez le mode de transport pour la sécurité, vous choisissez d’utiliser le mécanisme tel qu’il est dicté par le protocole. Par exemple, si vous sélectionnez la WSHttpBinding classe et définissez son mode de sécurité sur Transport, vous sélectionnez SSL sur HTTP (HTTPS) comme mécanisme de sécurité. L’avantage du mode de transport est qu’il est plus efficace que le mode message, car la sécurité est intégrée à un niveau relativement bas. Lors de l’utilisation du mode de transport, le mécanisme de sécurité doit être implémenté conformément à la spécification du transport, et par conséquent, les messages peuvent circuler en toute sécurité uniquement de point à point sur le transport.

mode de message

En revanche, le mode message assure la sécurité en incluant les données de sécurité dans le cadre de chaque message. À l’aide d’en-têtes de sécurité XML et SOAP, les informations d’identification et d’autres données nécessaires pour garantir l’intégrité et la confidentialité du message sont incluses dans chaque message. Chaque message inclut des données de sécurité, ce qui entraîne un péage sur les performances, car chaque message doit être traité individuellement. (En mode 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. Autrement dit, les exigences de sécurité ne sont pas déterminées par le transport. Vous pouvez utiliser n’importe quel type d’informations d’identification du client pour sécuriser le message. (En mode 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 du transport et de la sécurité des messages. Dans ce mode, la sécurité du transport est utilisée pour garantir efficacement la confidentialité et l’intégrité de chaque message. En même temps, chaque message inclut ses données d’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 de justificatif du client et de sa valeur

Une fois que vous avez sélectionné un mode de sécurité, vous pouvez également spécifier un type d’informations d’identification client. Le type d’informations d’identification du client spécifie le type qu’un client doit utiliser pour s’authentifier auprès du serveur.

Toutefois, tous les scénarios ne nécessitent pas un type d’informations d’identification client. À l’aide de 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 exige que le client soit authentifié, votre choix d’un type d’informations d’identification client 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 offre plusieurs options, telles que Basique, Digest et d’autres. (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 disponible uniquement pour d’autres utilisateurs du réseau, le plus simple à utiliser est le type d’informations d’identification du client Windows. Toutefois, vous devrez peut-être également fournir un service avec un certificat. Ceci est illustré dans Comment : spécifier des valeurs d’informations d’identification du client.

Valeurs d'informations d'identification

Une valeur d'informations d'identification représente les informations d'identification utilisées par le service. Une fois que vous avez spécifié un type d’informations d’identification, vous devrez peut-être également configurer votre service avec les informations d’identification réelles. Si vous avez sélectionné Windows (et que le service s’exécute 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 le client. En bref, lors de l’exécution d’un service, une identité est affecté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é.

En revanche, du côté du client, l’identité est utilisée pour valider le service. Au moment du design, un développeur client peut définir l’élément <d’identité> sur une valeur obtenue à partir du 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. En cas d’échec de la vérification, le client met fin à la communication. La valeur peut être un nom d’utilisateur principal (UPN) si le service s’exécute sous l’identité d’un utilisateur particulier ou un nom de principal de service (SPN) si le service s’exécute sous un compte d’ordinateur. Pour plus d’informations, consultez Service Identity and Authentication. Les informations d'identification peuvent également être un certificat ou un champ d'un certificat qui identifie le certificat.

Niveaux de protection

La ProtectionLevel propriété se produit sur plusieurs classes d’attributs (telles que les ServiceContractAttribute classes et les OperationContractAttribute classes). 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 signatures ni chiffrement. Pour plus d’informations sur la propriété, consultez Présentation du niveau 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