Exporter (0) Imprimer
Développer tout

Module 10 : Sécurité des services Web

Dernière mise à jour le 31 août 2004
Sur cette page

Dans ce module Dans ce module
Objectifs Objectifs
S'applique à S'applique à
Modèle de sécurité des services Web Modèle de sécurité des services Web
Architecture de la sécurité au niveau de la plate-forme et du transport Architecture de la sécurité au niveau de la plate-forme et du transport
Stratégies d'authentification et d'autorisation Stratégies d'authentification et d'autorisation
Configuration de la sécurité Configuration de la sécurité
Transmission aux services Web des informations d'identification pour l'authentification Transmission aux services Web des informations d'identification pour l'authentification
Transmission de l'appelant initial Transmission de l'appelant initial
Accès aux ressources système Accès aux ressources système
Accès aux ressources réseau Accès aux ressources réseau
Accès aux objets COM Accès aux objets COM
Utilisation de certificats clients avec les services Web Utilisation de certificats clients avec les services Web
Communication sécurisée Communication sécurisée
Résumé Résumé

Dans ce module

L'utilisation de normes ouvertes souples fait des services Web un excellent mécanisme de mise à disposition des fonctions aux clients et d'hébergement de la logique métier de niveau intermédiaire à laquelle accèdent les serveurs Web frontaux. La sécurisation des services Web peut toutefois s'avérer complexe en raison des restrictions associées aux normes et de la nécessité de prendre en charge un grand nombre de types de clients différents.

Ce module explique comment développer et appliquer les techniques d'authentification, d'autorisation et de communication sécurisée pour sécuriser des services Web ASP.NET. Après un aperçu de trois principaux modèles de sécurité des services Web (au niveau du transport/de la plate-forme, de l'application et des messages), ce module décrit les options disponibles et le processus d'implémentation de la sécurité au niveau du transport/de la plate-forme des services Web ASP.NET.

Objectifs

Ce module vous permet d'effectuer les opérations suivantes :

  • sécuriser vos services Web ;

  • implémenter des solutions de sécurité au niveau de la plate-forme/du transport ;

  • comparer la sécurité au niveau de la plate-forme/du transport et la sécurité au niveau des messages ;

  • identifier et utiliser les opérateurs de contrôle d'appels fournis par les services Web ASP.NET ;

  • transmettre les informations d'identification des clients aux services Web nécessitant une authentification ;

  • transmettre l'identité de l'appelant initial d'un service Web aux systèmes en aval ;

  • concevoir une solution d'authentification, d'autorisation et de communication sécurisée pour vos services Web.

S'applique à

Ce module s'applique aux produits et technologies suivants :

  • Windows XP ou Windows 2000 Server (avec le service pack 3) et systèmes d'exploitation ultérieurs

  • Microsoft Internet Information Services (IIS) versions 5.0 et ultérieures

  • Microsoft Active Directory

  • .NET Framework version 1.0 (avec le service pack 2) et versions ultérieures

  • Visual C# .NET

Modèle de sécurité des services Web

La sécurité des services Web peut concerner trois niveaux :

  • Sécurité au niveau de la plate-forme et du transport (point à point)

  • Sécurité au niveau de l'application (personnalisée)

  • Sécurité au niveau des messages (bout en bout)

Chaque méthode présente divers points forts et points faibles, abordés en détail ci-après. Le choix de la méthode dépend en grande partie des caractéristiques de l'architecture et des plates-formes impliquées dans l'échange de messages.

Remarque : notez que ce module traite essentiellement de la sécurité au niveau de la plate-forme et de l'application. La sécurité au niveau des messages est gérée par l'initiative GXA (Global XML Web Services Architecture), et plus particulièrement la spécification WS-Security. Au moment de la rédaction de ce guide, Microsoft a publié en avant-première technologique une version du Kit de développement des services Web (WSDK). Ce kit permet de développer des solutions de sécurité au niveau des messages conformes à la spécification WS-Security. Pour plus d'informations, consultez l'adresse suivante : http://msdn.microsoft.com/webservices/building/wse/.

Sécurité au niveau de la plate-forme et du transport (point à point)

Vous pouvez utiliser le canal de transport placé entre deux points de terminaison (client de service Web et service Web) pour fournir une sécurité point à point. La figure 10.1 ci-après illustre cette situation.

Sécurité au niveau de la plate-forme et du transport

Figure 10.1
Sécurité au niveau de la plate-forme et du transport

Par exemple, lorsque vous utilisez une sécurité au niveau de la plate-forme (impliquant un environnement de système d'exploitation Microsoft® Windows® étroitement intégré) sur des intranets d'entreprise, les opérations réalisées sont les suivantes :

  • Le serveur Web (IIS) fournit différents types d'authentification (authentification de base, authentification Digest, authentification intégrée et authentification par certificats).

  • Le service Web ASP.NET hérite de certaines fonctionnalités d'authentification et d'autorisation ASP.NET.

  • Vous pouvez utiliser SSL et/ou IPSec pour garantir l'intégrité et la confidentialité des messages.

Contexte d'utilisation

Le modèle de sécurité au niveau du transport est un modèle simple, maîtrisé et adapté à un grand nombre de scénarios (principalement des scénarios impliquant des intranets) où les mécanismes de transport et la configuration des points de terminaison peuvent faire l'objet d'un contrôle étroit.

Les problèmes suivants sont associés à la sécurité au niveau du transport :

  • La sécurité devient étroitement intégrée (créant alors une dépendance) à la plate-forme sous-jacente, au mécanisme de transport et au fournisseur de services de sécurité (NTLM, Kerberos, etc.).

  • La sécurité s'applique en mode point à point et ne permet pas l'utilisation de plusieurs tronçons, ni le routage de données via des nœuds d'applications intermédiaires.

Sécurité au niveau de l'application

Avec cette méthode, l'application se charge de la sécurité en faisant appel à des fonctions de sécurité personnalisées. Par exemple :

  • Une application peut utiliser un en-tête SOAP pour transférer les informations d'identification de l'utilisateur afin d'authentifier ce dernier à chaque demande de service Web. Une méthode courante consiste à transmettre un ticket (ou un nom d'utilisateur ou une licence) à l'en-tête SOAP.

  • L'application peut générer son propre objet IPrincipal contenant des rôles. Il peut s'agir d'une classe personnalisée ou de la classe GenericPrincipal fournie par l'environnement .NET Framework.

  • L'application peut, de manière sélective, crypter tous les éléments exigeant un cryptage. Notez cependant que cette opération exige un stockage de clé sécurisé et que les développeurs doivent maîtriser l'utilisation des API cryptographiques appropriées.

    Une autre technique consiste à utiliser le protocole SSL pour garantir la confidentialité et l'intégrité des messages et de l'associer à des en-têtes SOAP personnalisés en vue de l'authentification.

Contexte d'utilisation

Utilisez cette méthode dans les situations suivantes :

  • Vous souhaitez tirer parti d'un schéma de base de données existant composé d'utilisateurs et de rôles et utilisé au sein d'une application existante.

  • Vous souhaitez crypter des parties d'un message, plutôt qu'un flux de données dans son intégralité.

Sécurité au niveau des messages (bout en bout)

Cette méthode, sans doute la plus souple et la plus puissante, est utilisée par l'architecture GXA et plus particulièrement la spécification WS-Security. La figure 10.2 ci-après illustre son fonctionnement.

Sécurité au niveau des messages

Figure 10.2
Sécurité au niveau des messages

Les spécifications WS-Security traduisent les diverses améliorations apportées à la messagerie SOAP (intégrité et confidentialité des messages, et authentification par message).

  • L'authentification est assurée par des jetons de sécurité transmis dans les en-têtes SOAP. La spécification WS-Security n'exige aucun type de jeton particulier. Les jetons de sécurité peuvent inclure des tickets Kerberos, des certificats X.509 ou un jeton binaire personnalisé.

  • Des signatures numériques garantissent une communication sécurisée. Elles préservent l'intégrité des messages et offrent un cryptage XML qui protège leur caractère confidentiel.

Contexte d'utilisation

Vous pouvez utiliser la spécification WS-Security pour développer une structure d'échange de messages sécurisés dans un environnement de services Web hétérogène. Elle convient parfaitement à des environnements hétérogènes et des scénarios où vous ne contrôlez pas directement à la fois la configuration des points de terminaison et celle des nœuds d'applications intermédiaires.

La sécurité au niveau des messages présente les caractéristiques suivantes :

  • Elle peut être indépendante du transport sous-jacent.

  • Elle autorise une architecture de sécurité hétérogène.

  • Elle offre une sécurité de bout en bout et facilite le routage des messages via des nœuds d'applications intermédiaires.

  • Elle prend en charge plusieurs technologies de cryptage.

  • Elle prend en charge la non-répudiation.

Kit de développement des services Web (WSDK)

Le Kit de développement des services Web (WSDK) fournit les API nécessaires à la gestion de la sécurité ainsi que d'autres services, tels que le routage et les références au niveau des messages. Ce kit est conforme aux derniers standards des services Web, notamment la spécification WS-Security, et permet donc l'interopérabilité avec d'autres fournisseurs utilisant les mêmes spécifications.

Informations supplémentaires

  • Pour obtenir des informations récentes sur le kit de développement des services Web et les spécifications WS-Security, consultez la page XML Developer Center sur MSDN à l'adresse suivante : http://msdn.microsoft.com/webservices/.

  • Pour plus d'informations sur GXA, consultez l'article « Understanding GXA » (en anglais) sur MSDN.

  • Pour participer à des discussions sur ce sujet, consultez le groupe de discussion relatif à l'interopérabilité GXA sur MSDN.

Architecture de la sécurité au niveau de la plate-forme et du transport

La figure 10.3 présente l'architecture de la sécurité de la plate-forme des services Web ASP.NET.

Architecture de la sécurité des services Web

Figure 10.3
Architecture de la sécurité des services Web

La figure 10.3 illustre les mécanismes d'authentification et d'autorisation intégrés aux services Web ASP.NET. Lorsqu'un client appelle un service Web, les événements d'authentification et d'autorisation suivants se succèdent :

  1. La demande SOAP est reçue du réseau. Elle peut contenir ou non des informations d'identification de l'authentification, suivant le type d'authentification adopté.

  2. Le cas échéant, IIS authentifie l'appelant via une authentification de base, Digest, intégrée (NTLM ou Kerberos) ou une authentification par certificats. Dans des environnements hétérogènes où l'authentification IIS (Windows) est impossible, IIS est configuré en vue d'une authentification anonyme. Dans ce type de situation, vous pouvez authentifier le client à l'aide d'attributs au niveau des messages, tels que les tickets transmis à l'en-tête SOAP.

  3. Vous pouvez également configurer IIS afin qu'il accepte uniquement des demandes provenant d'ordinateurs clients dotés d'adresses IP spécifiques.

  4. IIS transmet le jeton d'accès Windows de l'appelant authentifié à ASP.NET (il peut s'agir du jeton d'accès de l'utilisateur Internet anonyme si le service Web est configuré pour l'authentification anonyme).

  5. ASP.NET authentifie l'appelant. Si ASP.NET est configuré pour l'authentification Windows, aucune autre authentification n'intervient à ce stade ; IIS authentifie l'appelant.

    Si vous utilisez une méthode d'authentification autre que l'authentification Windows, le mode d'authentification ASP.NET Aucune est utilisé afin d'autoriser l'authentification personnalisée.

    Remarque : l'authentification par formulaires et l'authentification Passport ne sont actuellement pas prises en charge pour les services Web.

  6. ASP.NET autorise l'accès au service Web demandé (fichier .asmx) à l'aide de l'autorisation des URL et l'autorisation de fichiers qui utilisent les autorisations NTFS associées au fichier .asmx pour déterminer si l'accès doit être accordé à l'appelant authentifié.

    Remarque : l'autorisation de fichiers est uniquement prise en charge pour l'authentification Windows.

    Pour garantir un processus d'autorisation précise, vous pouvez également utiliser des rôles .NET (soit de manière déclarative, soit par programmation) pour vous assurer que l'appelant est autorisé à accéder à la méthode Web demandée.

  7. Le code du service Web peut accéder aux ressources locales et/ou distantes à l'aide d'une identité particulière. Par défaut, les services Web ASP.NET ne procèdent à aucun emprunt d'identité et c'est, par conséquent, le compte du processus ASP.NET configuré qui fournit l'identité. D'autres options incluent l'identité de l'appelant initial ou une identité de service configuré.

Opérateurs de contrôle d'appels

Les opérateurs de contrôle d'appels d'un service Web ASP.NET sont les suivants :

  • IIS

    • Si l'authentification IIS anonyme est désactivée, IIS autorise uniquement les demandes émanant d'utilisateurs authentifiés.

    • Restrictions appliquées aux adresses IP
      Vous pouvez configurer IIS pour n'accepter que des demandes provenant d'ordinateurs associés à des adresses IP spécifiques.

  • ASP.NET

    • Module HTTP d'autorisation de fichiers (authentification Windows uniquement)

    • Module HTTP d'autorisation des URL

  • Demandes PrincipalPermission et vérifications explicites de rôles

Informations supplémentaires

  • Pour plus d'informations sur les opérateurs de contrôle d'appels, consultez la rubrique « Opérateurs de contrôle d'appels » de la section « Architecture de la sécurité ASP.NET » du Module 8, « Sécurité ASP.NET ».

  • Pour plus d'informations sur la configuration de la sécurité, consultez la section « Configuration de la sécurité » plus loin dans ce module.

Stratégies d'authentification et d'autorisation

Cette section décrit les options d'autorisation (configurables et par programmation) disponibles pour un ensemble de modèles d'authentification couramment utilisés.

Les modèles d'authentification suivants sont résumés dans cette section :

  • Authentification Windows avec emprunt d'identité

  • Authentification Windows sans emprunt d'identité

  • Authentification Windows à l'aide d'une identité fixe

Authentification Windows avec emprunt d'identité

Les éléments de configuration suivants expliquent comment activer de manière déclarative les fonctionnalités d'authentification et d'emprunt d'identité de Windows (IIS) dans le fichier Web.config ou Machine.config.

Remarque : il est préférable de configurer l'authentification pour chaque service Web à partir du fichier Web.config de chacun des services.

<authentication mode="Windows" />
<identity impersonate="true" />

Dans cette configuration, le code de votre service Web prend l'identité de l'appelant authentifié dans IIS. Pour emprunter l'identité de l'appelant initial, vous devez désactiver l'accès anonyme dans IIS. Ce type d'accès permet au code du service Web d'emprunter l'identité du compte d'utilisateur Internet anonyme (par défaut, IUSR_MACHINE).

Sécurité configurable

Lorsque vous utilisez conjointement l'authentification et l'emprunt d'identité Windows, les options d'autorisation suivantes sont mises à votre disposition :

  • Listes de contrôle d'accès Windows

    • Fichier de service Web (.asmx) . L'autorisation de fichiers effectue des vérifications d'accès pour les ressources ASP.NET requises (notamment le fichier .asmx du service Web) à l'aide du contexte de sécurité de l'appelant initial. L'appelant initial doit disposer au moins d'un accès en lecture au fichier .asmx.

    • Ressources accessibles à votre service Web. Les listes de contrôle d'accès Windows des ressources auxquelles votre service Web a accès (fichiers, dossiers, clés du Registre, objets du service d'annuaire Active Directory®, etc.) doivent inclure une entrée de contrôle d'accès (ACE) autorisant l'accès en lecture à l'appelant initial (puisque le thread du service Web utilisé pour l'accès aux ressources prend l'identité de l'appelant).

  • Autorisation des URL. Vous pouvez configurer ce paramètre dans le fichier Machine.config et/ou Web.config. Dans le cadre d'une authentification Windows, les noms des utilisateurs adoptent la forme NomDomaine\NomUtilisateur et les rôles sont mappés un à un à des groupes Windows.

    <authorization>
      <deny user="NomDomaine\NomUtilisateur" />
      <allow roles="NomDomaine\GroupeWindows" />
    </authorization>
    
Sécurité par programmation

La sécurité par programmation fait appel à des vérifications de sécurité comprises dans le code du service Web. Les options de sécurité par programmation suivantes sont disponibles lors de l'utilisation de l'authentification et de l'emprunt d'identité Windows :

  • Demandes PrincipalPermission

    • Impérative (in-line dans le code d'une méthode)

          PrincipalPermission permCheck = new PrincipalPermission(
                                             null, @"NomDomaine\GroupeWindows");
          permCheck.Demand();
      
    • Déclarative (ces attributs peuvent précéder des méthodes Web ou des classes Web)

      // Exiger que l'appelant soit membre d'un rôle précis (pour
      // l'authentification Windows, identique à un groupe Windows).)
      [PrincipalPermission(SecurityAction.Demand, 
                        Role=@"NomDomaine\GroupeWindows")]
      // Exiger que l'appelant soit un utilisateur précis.
      [PrincipalPermission(SecurityAction.Demand, 
                        Name=@"NomDomaine\NomUtilisateur")]
      
  • Vérifications de rôles explicites. Vous pouvez vérifier les rôles à l'aide de l'interface IPrincipal.

    IPrincipal.IsInRole(@"NomDomaine\GroupeWindows");
    
Contexte d'utilisation

Utilisez l'authentification et l'emprunt d'identité Windows dans les situations suivantes :

  • Vous pouvez identifier les clients du service Web à l'aide de comptes Windows que le serveur peut authentifier.

  • Vous devez transmettre au niveau suivant le contexte de sécurité de l'appelant initial par l'intermédiaire du service Web. Il peut s'agir, par exemple, d'un ensemble de composants desservis utilisant des rôles Microsoft Enterprise Services (COM+) ou d'un niveau de données exigeant une autorisation précise (par utilisateur).

  • Vous devez transmettre le contexte de sécurité de l'appelant initial vers les niveaux en aval pour permettre un audit au niveau du système d'exploitation.

Important : du fait de son impact sur le regroupement de connexions la base de données, le recours à l'emprunt d'identité risque de nuire à l'évolutivité. Vous pouvez adopter une autre méthode et utiliser le modèle de sous-système approuvé à partir duquel le service Web autorise les appelants, puis utilise une identité fixe pour accéder à la base de données. Vous pouvez transmettre l'identité de l'appelant au niveau de l'application en utilisant, par exemple, des paramètres de procédures stockées.

Informations supplémentaires

  • Pour plus d'informations sur l'authentification et l'emprunt d'identité Windows, consultez le Module 8, « Sécurité ASP.NET ».

  • Pour plus d'informations sur l'autorisation des URL, consultez la section « Remarques concernant les autorisations d'URL » du Module 8, « Sécurité ASP.NET ».

Authentification Windows sans emprunt d'identité

Les éléments de configuration qui suivent expliquent comment activer de manière déclarative les fonctions d'authentification Windows (IIS) sans emprunt d'identité dans le fichier Web.config.

<authentication mode="Windows" />
<!-- Le paramètre suivant équivaut à n'avoir aucun élément Identity. -->
<identity impersonate="false" />
Sécurité configurable

Lorsque vous utilisez l'authentification Windows sans emprunt d'identité, les options d'autorisation disponibles sont les suivantes :

  • Listes de contrôle d'accès Windows

    • Fichier de service Web (.asmx). L'autorisation de fichiers effectue des vérifications d'accès pour les ressources ASP.NET requises (notamment le fichier .asmx du service Web) à l'aide de l'appelant initial. L'emprunt d'identité n'est pas requis.

    • Ressources accessibles à votre application. Les listes de contrôle d'accès Windows des ressources auxquelles votre application peut accéder (fichiers, dossiers, clés du Registre, objets Active Directory) doivent inclure une entrée de contrôle d'accès (ACE) autorisant l'accès en lecture au processus d'identité ASP.NET (identité utilisée par défaut par le thread du service Web lors de l'accès aux ressources).

  • Autorisation des URL

    Vous pouvez configurer ce paramètre dans les fichiers Machine.config et Web.config. Avec l'authentification Windows, les noms des utilisateurs adoptent la forme NomDomaine\NomUtilisateur et les rôles sont mappés un à un à des groupes Windows.

    <authorization>
      <deny user="NomDomaine\NomUtilisateur" />
      <allow roles="NomDomaine\GroupeWindows" />
    </authorization>
    
Sécurité par programmation

La sécurité par programmation fait appel à des vérifications de sécurité comprises dans le code du service Web. Les options de sécurité par programmation suivantes sont disponibles lors de l'utilisation de l'authentification Windows sans emprunt d'identité :

  • Demandes PrincipalPermission

    • Impérative

          PrincipalPermission permCheck = new PrincipalPermission(
                                             null, @"NomDomaine\GroupeWindows");
          permCheck.Demand();
      
    • Déclarative

      // Exiger que l'appelant soit membre d'un rôle précis (pour
      // l'authentification Windows, identique à un groupe Windows).)
      [PrincipalPermission(SecurityAction.Demand, 
                        Role=@"NomDomaine\GroupeWindows")]
      // Exiger que l'appelant soit un utilisateur précis.
      [PrincipalPermission(SecurityAction.Demand, 
                        Name=@"NomDomaine\NomUtilisateur")]  
      
  • Vérifications de rôles explicites. Vous pouvez vérifier les rôles à l'aide de l'interface IPrincipal.

    IPrincipal.IsInRole(@"NomDomaine\GroupeWindows");
    
Contexte d'utilisation

Utilisez l'authentification Windows sans emprunt d'identité dans les situations suivantes :

  • Vous pouvez identifier les clients du service Web à l'aide de comptes Windows que le serveur peut authentifier.

  • Vous souhaitez utiliser le modèle de sous-système approuvé, autoriser les clients du service Web, puis utiliser une identité fixe pour accéder aux ressources en aval (des bases de données, par exemple) afin de prendre en charge le regroupement de connexions.

Informations supplémentaires

  • Pour plus d'informations sur l'authentification et l'emprunt d'identité Windows, consultez le Module 8, « Sécurité ASP.NET ».

  • Pour plus d'informations sur l'autorisation des URL, consultez la section « Remarques concernant les autorisations d'URL » du Module 8, « Sécurité ASP.NET ».

Authentification Windows à l'aide d'une identité fixe

L'élément <identity> de Web.config prend en charge des attributs de nom d'utilisateur et de mot de passe facultatifs qui permettent de configurer une identité fixe spécifique que le service Web peut emprunter. Le fragment de fichier de configuration suivant illustre cette situation.

<identity impersonate="true"
          userName="registry:HKLM\SOFTWARE\YourSecureApp\
                    identity\ASPNET_SETREG,userName"
          password="registry:HKLM\SOFTWARE\YourSecureApp\
                    identity\ASPNET_SETREG,password" />

Cet exemple montre l'élément <identity>, dans lequel les informations d'identification sont cryptées dans le Registre à l'aide de l'utilitaire aspnet_setreg.exe. Les valeurs des attributs userName et password en texte brut ont été remplacées par des pointeurs vers la clé de Registre sécurisée et des valeurs nommées contenant les informations d'identification cryptées. Pour plus d'informations sur cet utilitaire et son téléchargement, consultez l' article Q329290, « COMMENT FAIRE : Utilisation de l'utilitaire ASP.NET pour crypter les informations d'authentification et les chaînes de connexion de l'état de session » dans la Base de connaissances Microsoft.

Contexte d'utilisation

L'utilisation d'une identité empruntée fixe est déconseillée lors de l'utilisation de .NET Framework 1.0 sur des serveurs Windows 2000. Il serait en effet nécessaire d'accorder au compte du processus ASP.NET le puissant privilège « Fonctionner en tant que partie intégrante du système d'exploitation ». Le processus ASP.NET a besoin de ce privilège pour effectuer un appel LogonUser à l'aide des informations d'identification fournies.

Remarque : la version 1.1 de .NET Framework apporte des améliorations à ce scénario sur Windows 2000. Le processus IIS se charge notamment de la connexion afin qu'ASP.NET n'exige pas de privilège « Fonctionner en tant que partie intégrante du système d'exploitation ».

Informations supplémentaires

  • Pour plus d'informations sur l'authentification et l'emprunt d'identité Windows, consultez le Module 8, « Sécurité ASP.NET ».

  • Pour plus d'informations sur l'autorisation des URL, consultez la section « Remarques concernant les autorisations d'URL » du Module 8, « Sécurité ASP.NET ».

Configuration de la sécurité

Cette section décrit la procédure de configuration de la sécurité d'un service Web ASP.NET. Cette procédure est résumée dans la figure 10.4.

Configuration de la sécurité des services Web ASP.NET

Figure 10.4
Configuration de la sécurité des services Web ASP.NET

Configuration des paramètres IIS

Pour plus d'informations sur la configuration des paramètres de sécurité IIS, consultez la section « Configuration de la sécurité » du Module 8, « Sécurité ASP.NET ». Ces informations s'appliquent également aux services Web ASP.NET.

Configuration des paramètres ASP.NET

Les paramètres de configuration au niveau de l'application sont gérés à partir des fichiers Web.config résidant dans le répertoire de la racine virtuelle de votre service Web. Configurez les paramètres suivants :

  1. Configuration de l'authentification. Ce paramètre est défini au niveau de chaque service Web (et non dans Machine.config) à partir du fichier Web.config situé dans le répertoire de la racine virtuelle du service Web.

    <authentication mode="Windows|None" />
    

    Remarque : les services Web ne prennent actuellement pas en charge l'authentification par formulaires et l'authentification Passport. Pour des opérations d'authentification personnalisée ou au niveau des messages, utilisez le mode Aucune.

  2. Configuration de l'emprunt d'identité et de l'autorisation. Pour plus d'informations, consultez la section « Configuration de la sécurité » du Module 8, « Sécurité ASP.NET ».

Informations supplémentaires

Pour plus d'informations sur l'autorisation des URL, consultez la section « Remarques concernant les autorisations d'URL » du Module 8, « Sécurité ASP.NET ».

Ressources sécurisées

Pour sécuriser les ressources Web, il est conseillé d'utiliser les mêmes techniques que celles décrites dans le Module 8, « Sécurité ASP.NET ». De plus, lorsque vous travaillez avec des services Web, envisagez toutefois de supprimer les protocoles HTTP-GET et HTTP-POST de Machine.config sur les serveurs de production.

Désactivation des protocoles HTTP-GET et HTTP-POST

Par défaut, les clients peuvent communiquer avec des services Web ASP.NET à l'aide de trois protocoles : HTTP-GET, HTTP-POST et SOAP sur HTTP. Désactivez la prise en charge des protocoles HTTP-GET et HTTP-POST au niveau de l'ordinateur pour les ordinateurs de production ne nécessitant pas leur utilisation. Cette précaution évitera une éventuelle violation de la sécurité pouvant permettre à une page Web malveillante d'accéder à un service Web interne protégé par un pare-feu.

Remarque : la désactivation de ces protocoles implique qu'un nouveau client n'aura pas la possibilité de tester un service Web XML à l'aide du bouton Appeler de la page de test du service Web. Vous devez au lieu de cela créer un programme client test en ajoutant une référence au service Web à l'aide du système de développement Microsoft Visual Studio® .NET. Si vous le souhaitez, vous pouvez laisser ces protocoles activés sur des ordinateurs de développement pour permettre aux développeurs d'utiliser la page de test.

  • Pour désactiver les protocoles HTTP-GET et HTTP-POST sur l'ensemble d'un ordinateur

    1. Modifiez le fichier Machine.config.

    2. Mettez en commentaire les lignes de l'élément <webServices> qui permettent la prise en charge des protocoles HTTP-GET et HTTP-POST. Lorsque vous avez terminé, Machine.config doit se présenter comme suit :

      <webServices>
          <protocols>
            <add name="HttpSoap"/> 
               <!-- <add name="HttpPost"/> --> 
               <!-- <add name="HttpGet"/>  -->
            <add name="Documentation"/> 
          </protocols>
      </webServices>
      
    3. Enregistrez le fichier Machine.config.

Remarque : dans certains cas spéciaux où des clients communiquent avec un service Web à l'aide du protocole HTTP-GET ou HTTP-POST, vous pouvez ajouter la prise en charge de ces protocoles dans le fichier Web.config de l'application en créant un élément <webServices> et en intégrant la prise en charge des protocoles aux éléments <protocol> et <add>, comme décrit précédemment.

Informations supplémentaires

Pour plus d'informations sur la sécurisation des ressources, consultez la rubrique « Ressources sécurisées » de la section « Configuration de la sécurité » du Module 8, « Sécurité ASP.NET ».

Communication sécurisée

Utilisez une combinaison des protocoles SSL et IPSec pour sécuriser des liaisons de communication.

Informations supplémentaires
  • Pour plus d'informations sur l'appel service Web à l'aide du protocole SSL, consultez la section « Procédure : Appeler un service Web avec SSL » dans ce guide.

  • Pour plus d'informations sur l'utilisation du protocole IPSec entre deux ordinateurs, consultez la section « Procédure : Utiliser IPSec pour fournir une communication sécurisée entre deux serveurs » dans ce guide.

Transmission aux services Web des informations d'identification pour l'authentification

Lorsque vous appelez un service Web, vous utilisez un proxy du service Web, c'est-à-dire un objet local qui propose le même jeu de méthodes que le service Web cible.

Vous pouvez générer ce proxy à l'aide de l'utilitaire de ligne de commande Wsdl.exe. Si vous utilisez Microsoft Visual Studio .NET, vous pouvez également générer le proxy en ajoutant une référence Web au projet.

Remarque : si la configuration du service Web pour lequel vous comptez générer un proxy exige des certificats clients, vous devez provisoirement désactiver ce paramètre lorsque vous ajoutez la référence. Sinon, une erreur se produit. Une fois la référence ajoutée, pensez à reconfigurer le service pour activer à nouveau l'utilisation des certificats.

Une autre méthode consiste à conserver un fichier WSDL (Services Web Description Language) hors connexion à la disposition des applications de consommateurs. Pensez également à mettre ce paramètre à jour en cas de modifications de l'interface de votre service Web.

Spécification des informations d'identification des clients pour l'authentification Windows

Si vous utilisez l'authentification Windows, vous devez spécifier les informations d'identification à utiliser pour l'authentification à l'aide de la propriété Credentials du proxy du service Web. Si vous ne définissez pas explicitement cette propriété, l'appel du service Web s'effectue sans informations d'identification. Si l'authentification Windows est requise, le système renvoie le code d'état HTTP 401 (réponse d'accès refusé).

Utilisation de DefaultCredentials

Les informations d'identification des clients ne sont pas implicitement transmises. L'utilisateur du service Web doit définir ces informations ainsi que les données d'authentification détaillées à partir du proxy. Pour transmettre le contexte de sécurité du contexte de sécurité Windows du client (soit à partir d'un jeton d'emprunt d'identité du thread, soit à partir d'un jeton de processus) à un service Web, vous pouvez associer la valeur CredentialCache.DefaultCredentials à la propriété Credentials du proxy du service Web, comme illustré ci-après.

proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;

Tenez compte des points suivants avant d'adopter cette méthode :

  • Les informations d'identification des clients sont transmises uniquement lorsque vous utilisez l'authentification NTLM, Kerberos ou Negotiate.

  • Si une application côté client (par exemple une application Windows Forms) appelle le service Web, les informations d'identification proviennent alors de la session ouverte interactivement par l'utilisateur.

  • Les applications côté serveur, notamment les applications Web ASP.NET, utilisent l'identité du processus, sauf si la fonction d'emprunt d'identité est configurée (c'est l'identité empruntée à l'appelant qui est alors utilisée).

Utilisation d'informations d'identification spécifiques

Pour utiliser un ensemble d'informations d'identification spécifique lorsque vous appelez un service Web, utilisez le code suivant :

CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url), // URL du service Web
           "Negotiate",        // Kerberos ou NTLM
           new NetworkCredential("username", "password", "domainname") );
proxy.Credentials = cache;

Dans l'exemple ci-dessus, le type d'authentification Negotiate requis entraîne une authentification Kerberos ou NTLM.

Demander un type d'authentification spécifique

Vous devez demander un type d'authentification spécifique comme illustré ci-dessus. Évitez le recours direct à la classe NetworkCredential comme l'illustre le fragment de code suivant :

proxy.Credentials = new 
                      NetworkCredential("username", "password", "domainname");

L'utilisation de cette classe est à éviter dans un code de production, car elle ne permet pas de contrôler le mécanisme d'authentification utilisé par le service Web et, par conséquent, le mode d'utilisation des informations d'identification.

Par exemple, vous pouvez attendre une demande d'authentification Kerberos ou NTLM du serveur mais recevoir à la place une demande d'authentification de base. Dans ce cas, le nom d'utilisateur et le mot de passe fournis sont transmis au serveur en texte brut.

Définition de la propriété PreAuthenticate

Attribuez la valeur « true » ou « false » à la propriété PreAuthenticate du proxy. Attribuez la valeur « true » pour fournir des informations d'identification relatives à une authentification spécifique et permettre la transmission d'un en-tête HTTP WWW-authenticate avec la demande Web. Cette précaution évite au serveur Web de refuser l'accès de la demande et de procéder à l'authentification de la tentative de demande suivante.

Remarque : la pré-authentification s'applique uniquement après une première authentification réussie par le service Web. Elle n'a aucune incidence sur la première demande Web.

private void ConfigureProxy( WebClientProtocol proxy, 
                             string domain, string username, 
                             string password )
{
  // Pour améliorer les performances, imposer la pré-authentification.
  proxy.PreAuthenticate = true;
  // Définir les informations d'identification.
  CredentialCache cache = new CredentialCache();
  cache.Add( new Uri(proxy.Url),
             "Negotiate",     
             new NetworkCredential(username, password, domain) );
  proxy.Credentials = cache;
  proxy.ConnectionGroupName = username;
}
Utilisation de la propriété ConnectionGroupName

Notez que le code ci-dessus définit la propriété ConnectionGroupName du proxy du service Web. Ce paramètre est nécessaire uniquement si le contexte de sécurité utilisé pour la connexion au service Web varie d'une demande à l'autre, comme expliqué ci-après.

Si une de vos applications Web ASP.NET se connecte à un service Web et transmet le contexte de sécurité de l'appelant initial (à l'aide de DefaultCredentials ou par la définition d'informations d'identification explicites, comme illustré ci-dessus), vous devez définir la propriété ConnectionGroupName du proxy du service Web au sein de l'application Web. Vous pouvez ainsi empêcher un nouveau client non authentifié de réutiliser une ancienne connexion TCP au service Web authentifiée et associée aux informations d'identification d'un client précédent. La réutilisation d'une connexion peut être justifiée par l'utilisation de HTTP KeepAlives et de la fonction de persistance de l'authentification activée dans IIS pour des raisons de performances.

Associez à la propriété ConnectionGroupName (le nom d'utilisateur de l'appelant, par exemple) un identificateur permettant de distinguer un appelant d'un autre (voir le fragment de code précédent).

Remarque : si le contexte de sécurité de l'appelant initial n'est pas transmis au service Web par l'intermédiaire de l'application Web et qu'à défaut cette dernière se connecte au service Web à l'aide d'une identité fixe (l'identité du processus ASP.NET de l'application Web, par exemple), il n'est pas nécessaire de définir la propriété ConnectionGroupName. Dans ce cas, le contexte de sécurité de la connexion reste le même d'un appelant à l'autre.

Appel de services Web à partir de clients autres que Windows

Plusieurs méthodes d'authentification conviennent dans le cadre de scénarios faisant intervenir plusieurs navigateurs, notamment :

  • Authentification par certificats. Utilisation de certificats X.509 multiplate-formes.

  • Authentification de base. Pour obtenir un exemple d'utilisation de l'authentification de base pour un magasin de données personnalisé (Active Directory non requis), consultez http://www.rassoc.com/gregr/weblog/stories/2002/06/26/webServicesSecurityHttpBasic AuthenticationWithoutActiveDirectory.html.

  • Méthodes GXA appliquées au niveau des messages. Utilisez le Kit de développement des services Web (WSDK) pour implémenter des solutions GXA (WS-Security).

  • Méthodes personnalisées. Par exemple, transmission des informations d'identification dans des en-têtes SOAP.

Authentification du serveur proxy

L'authentification du serveur proxy n'est pas prise en charge dans la boîte de dialogue Ajouter une référence Web de Visual Studio .NET (prise en charge prévue dans la prochaine version du produit). Le système peut donc renvoyer un code d'état HTTP 407 (réponse « Authentification proxy requise ») si vous tentez d'ajouter une référence Web.

Remarque : cette erreur peut ne pas apparaître lorsque vous consultez le fichier .asmx à partir d'un navigateur, car ce dernier procède automatiquement à l'envoi des informations d'identification.

Pour contourner ce problème, vous pouvez exécuter l'utilitaire de ligne de commande Wsdl.exe (plutôt que la boîte de dialogue Ajouter une référence Web), comme illustré ci-après.

wsdl.exe /proxy:http://<YourProxy> /pu:<YourName> /pp:<YourPassword>
/pd:<YourDomain> http://www.YouWebServer.com/YourWebService/YourService.asmx

Si vous avez besoin de définir par programmation les informations d'authentification du serveur proxy, utilisez le code suivant :

YourWebServiceProxy.Proxy.Credentials = CredentialsCache.DefaultCredentials;

Transmission de l'appelant initial

Cette section explique comment transmettre le contexte de sécurité de l'appelant initial par l'intermédiaire d'une application Web ASP.NET et vers un service Web résidant sur un serveur d'applications distant. Cette opération peut s'avérer nécessaire pour valider la prise en charge d'autorisations par utilisateur dans le service Web ou les sous-systèmes suivants en aval (les bases de données dans lesquelles vous souhaitez autoriser des appelants initiaux à accéder aux différents objets, par exemple).

Dans la figure 10.5, le contexte de sécurité de l'appelant initial (Alice) est transmis par l'intermédiaire du serveur Web frontal qui héberge l'application Web ASP.NET, vers l'objet distant hébergé par ASP.NET sur un serveur d'applications distant, puis vers un serveur de base de données principal.

Transmission du contexte de sécurité de l'appelant initial

Figure 10.5
Transmission du contexte de sécurité de l'appelant initial

Pour être en mesure de transmettre des informations d'identification à un service Web, le client du service Web (l'application Web ASP.NET dans ce scénario) doit configurer le proxy du service Web, puis définir explicitement la propriété Credentials du proxy, comme le décrit la section « Transmission aux services Web des informations d'identification pour l'authentification » plus haut dans ce module.

Deux méthodes permettent de transmettre le contexte de sécurité de l'appelant.

  • Transmission des informations d'identification par défaut et utilisation de l'authentification (et délégation) Kerberos). Cette méthode nécessite l'emprunt d'une identité dans l'application Web ASP.NET et la configuration de l'objet proxy distant à l'aide de DefaultCredentials obtenu à partir du contexte de sécurité de l'appelant dont l'identité a été empruntée.

  • Transmission des informations d'identification explicites et utilisation de l'authentification de base ou de l'authentification par formulaires. Cette méthode ne nécessite aucun emprunt d'identité dans l'application Web ASP.NET. Vous devez en revanche configurer par programmation le proxy du service Web à l'aide d'informations d'identification explicites provenant de variables serveur (authentification de base) ou de champs de formulaires HTML (authentification par formulaires) mis à la disposition de l'application Web. Dans le cadre d'une authentification de base ou par formulaires, le nom d'utilisateur et le mot de passe sont fournis au serveur en texte brut.

Informations d'identification par défaut de la délégation Kerberos

Pour utiliser la délégation Kerberos, tous les ordinateurs (serveurs et clients) doivent fonctionner sur Windows 2000 ou une version ultérieure. En outre, les comptes clients à déléguer doivent être stockés dans Active Directory et ne doivent pas être associés à la mention « Le compte est sensible et ne peut pas être délégué ».

Les tableaux suivants décrivent les étapes nécessaires à la configuration du serveur Web et du serveur d'applications.

Configuration du serveur Web

Configuration de IIS

Étape

Informations supplémentaires

Désactivez l'accès anonyme du répertoire de la racine virtuelle de l'application Web.

Activez l'authentification intégrée de Windows de la racine virtuelle de l'application Web.





L'authentification Kerberos est négociée si les clients et le serveur fonctionnent sur Windows 2000 ou une version ultérieure.
Remarque : si vous utilisez Microsoft Internet Explorer 6 sur Windows 2000, l'authentification NTLM est adoptée par défaut à la place de l'authentification Kerberos requise. Pour activer la délégation Kerberos, consultez l'article Q299838, « Impossible de négocier l'authentification Kerberos après la mise à niveau vers Internet Explorer 6 » dans la Base de connaissances Microsoft.

Configuration de ASP.NET

Étape

Informations supplémentaires

Configurez votre application Web ASP.NET afin qu'elle utilise l'authentification Windows.

Modifiez le fichier Web.config qui se trouve dans le répertoire virtuel de votre application Web.
Définissez l'élément <authentication> comme suit :

<authentication mode="Windows" />

Configurez votre application Web ASP.NET pour l'emprunt d'identité.

Modifiez le fichier Web.config qui se trouve dans le répertoire virtuel de votre application Web.
Définissez l'élément <identity> comme suit :

<identity impersonate="true" />
Configuration du proxy du service Web

Étape

Informations supplémentaires

Attribuez la valeur DefaultCredentials à la propriété Credentials du proxy du service Web.

Voir « Utilisation de DefaultCredentials » pour obtenir un exemple de code.

Configuration du serveur d'applications distant

Configuration de IIS

Étape

Informations supplémentaires

Désactivez l'accès anonyme pour le répertoire de la racine virtuelle de votre service Web.

Activez l'authentification intégrée de Windows pour la racine virtuelle de l'application Web.

 

Configuration de ASP.NET (hôte du service Web)

Étape

Informations supplémentaires

Configurez ASP.NET pour utiliser l'authentification Windows.

Modifiez le fichier Web.config qui se trouve dans le répertoire virtuel du service Web.
Définissez l'élément <authentication> comme suit :

<authentication mode="Windows" />

Configurez ASP.NET pour l'emprunt d'identité.

Modifiez le fichier Web.config qui se trouve dans le répertoire virtuel du service Web.
Définissez l'élément <identity> comme suit :

<identity impersonate="true" />

Remarque : cette étape est nécessaire uniquement si vous souhaitez transmettre le contexte de sécurité de l'appelant initial par l'intermédiaire du service Web vers le sous-système en aval suivant (une base de données, par exemple). Une fois l'emprunt d'identité activé, l'accès aux ressources (locales et distantes) utilise le contexte de sécurité de l'appelant initial dont l'identité a été empruntée.
Si vous souhaitez simplement activer des vérifications d'autorisation par utilisateur au sein du service Web, l'emprunt d'identité est inutile.

Informations supplémentaires

Pour plus d'informations sur la configuration de la délégation Kerberos, consultez la section « Procédure : Implémenter une délégation Kerberos pour Windows 2000 » dans ce guide.

Informations d'identification explicites avec l'authentification de base ou l'authentification par formulaires

En lieu et place de délégation Kerberos, vous pouvez utiliser l'authentification de base ou l'authentification par formulaires au niveau de l'application Web pour récupérer les informations d'identification du client, puis l'utilisation de l'authentification de base (ou l'authentification intégrée de Windows) pour le service Web.

Les informations d'identification du client fournies en texte brut sont ainsi mises à la disposition de l'application Web. Elles peuvent être transmises au service Web par l'intermédiaire du proxy de ce dernier. Pour cela, vous devez rédiger du code dans l'application Web pour extraire les informations d'identification du client et configurer le proxy.

Authentification de base

Ce type d'authentification permet de mettre les informations d'identification de l'appelant initial à la disposition de l'application Web dans des variables serveur. Le code présenté ci-dessous explique comment extraire ces informations, puis configurer le proxy du service Web.

// Extraire les informations d'identification du client (disponible avec l'authentification de base).
string pwd = Request.ServerVariables["AUTH_PASSWORD"];
string uid = Request.ServerVariables["AUTH_USER"];
// Associer les informations d'identification avec le proxy du service Web.
// Pour améliorer les performances, imposer la pré-authentification.
proxy.PreAuthenticate = true;
// Définir les informations d'identification.
CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url),
           "Basic",     
           new NetworkCredential(uid, pwd, domain) );
proxy.Credentials = cache;

Authentification par formulaires

Ce type d'authentification permet de mettre les informations d'identification de l'appelant initial à la disposition de l'application Web dans des champs de formulaire (plutôt que des variables serveur). Dans ce cas, utilisez le code suivant :

// Extraire les informations d'identification du client à partir du formulaire de connexion.
string pwd = txtPassword.Text;
string uid = txtUid.Text;
// Associer les informations d'identification avec le proxy du service Web.
// Pour améliorer les performances, imposer la pré-authentification.
proxy.PreAuthenticate = true;
// Définir les informations d'identification.
CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url),
           "Basic",     
           new NetworkCredential(uid, pwd, domain) );
proxy.Credentials = cache;

Les tableaux suivants décrivent la procédure de configuration du serveur Web et du serveur d'applications.

Configuration du serveur Web

Configuration de IIS

Étape

Informations supplémentaires

Pour utiliser l'authentification de base, désactivez l'accès anonyme pour le répertoire de la racine virtuelle de l'application Web, puis sélectionnez l'authentification de base.

- ou -

Pour utiliser l'authentification par formulaires, activez l'accès anonyme.

L'authentification de base et l'authentification par formulaires doivent être utilisées avec SSL afin de protéger les informations d'identification en texte brut transmises sur le réseau. Si vous choisissez l'authentification de base, vous devez utiliser SSL pour l'ensemble des pages (pas uniquement pour la page de connexion initiale) puisque les informations d'identification sont transmises à chaque demande.



De même, il est préférable d'utiliser SSL pour toutes les pages si vous adoptez l'authentification par formulaires. Vous pourrez ainsi protéger les informations d'identification en texte brut lors de la connexion initiale ainsi que le ticket d'authentification transmis lors des demandes suivantes.

Configuration de ASP.NET

Étape

Informations supplémentaires

Si vous choisissez l'authentification de base, configurez votre application Web ASP.NET afin d'utiliser l'authentification Windows.

- ou -

Si vous choisissez l'authentification par formulaires, configurez votre application Web ASP.NET afin d'utiliser ce type d'authentification.

Modifiez le fichier Web.config qui se trouve dans le répertoire virtuel de l'application Web.
Définissez l'élément <authentication> comme suit :

<authentication mode="Windows" />

- ou -

Modifiez le fichier Web.config qui se trouve dans le répertoire virtuel de l'application Web.
Définissez l'élément <authentication> comme suit :

<authentication mode="Forms" />

Désactivez l'emprunt d'identité dans l'application Web ASP.NET.

Modifiez le fichier Web.config qui se trouve dans le répertoire virtuel de votre application Web.
Définissez l'élément <identity> comme suit :

<identity impersonate="false" />

Remarque : le résultat est identique à l'absence d'élément <identity>. L'emprunt d'identité n'est pas requis puisque les informations d'identification de l'utilisateur sont transmises explicitement au service Web par l'intermédiaire du proxy.

Configuration du proxy du service Web

Étape

Informations supplémentaires

Rédigez du code pour capturer et définir explicitement les informations d'identification sur le proxy du service Web.

Consultez les fragments de code présentés plus haut dans les sections « Authentification de base » et « Authentification par formulaires ».

Configuration du serveur d'applications

Configuration de IIS

Étape

Informations supplémentaires

Désactivez l'accès anonyme pour le répertoire de la racine virtuelle de votre application.

Activez l'authentification de base.







Remarque : l'authentification de base sur le serveur d'applications (service Web) permet au service Web de transmettre à la base de données le contexte de sécurité de l'appelant initial (le nom d'utilisateur et le mot de passe de l'appelant étant disponibles en texte brut et pouvant être utilisés pour répondre aux demandes d'authentification réseau provenant du serveur de base de données). Si la transmission du contexte de sécurité de l'appelant initial au-delà du service Web n'est pas nécessaire, envisagez de configurer IIS au niveau du serveur d'applications afin d'utiliser l'authentification intégrée de Windows, qui offre une sécurité renforcée (les informations d'identification ne transitent pas par le réseau et le service Web ne peut y accéder).

Configuration de ASP.NET (service Web)

Étape

Informations supplémentaires

Configurez ASP.NET pour utiliser l'authentification Windows.

Modifiez le fichier Web.config qui se trouve dans le répertoire virtuel du service Web.
Définissez l'élément <authentication> comme suit :

<authentication mode="Windows" />

Configurez le service Web ASP.NET pour l'emprunt d'identité.

Modifiez le fichier Web.config qui se trouve dans le répertoire virtuel du service Web.
Définissez l'élément <identity> comme suit :

<identity impersonate="true" />

Remarque : cette étape est nécessaire uniquement si vous souhaitez transmettre le contexte de sécurité de l'appelant initial par l'intermédiaire du service Web vers le sous-système en aval suivant (une base de données, par exemple). Une fois l'emprunt d'identité activé, l'accès aux ressources (locales et distantes) utilise le contexte de sécurité de l'appelant initial dont l'identité a été empruntée.
Si vous souhaitez simplement activer des vérifications d'autorisation par utilisateur dans un objet distant, l'emprunt d'identité est inutile.

Sous-système approuvé

Le modèle de sous-système approuvé propose une méthode différente (plus simple à mettre en œuvre) de transmission du contexte de sécurité de l'appelant initial. Il fixe une limite de confiance entre le service Web et l'application Web. Le service Web approuve l'application Web et lui laisse le soin de correctement authentifier et autoriser les appelants avant de transmettre les demandes au service Web. Aucune authentification des appelants initiaux n'intervient au niveau du service Web. Le service Web authentifie l'identité fixe approuvée utilisée par l'application Web pour communiquer avec le service Web. Dans la plupart des cas, il s'agit de l'identité du processus de travail ASP.NET.

Ce modèle est présenté dans la figure 10.6.

Modèle de sous-système approuvé

Figure 10.6
Modèle de sous-système approuvé

Transmission de l'identité de l'appelant

Si vous utilisez le modèle de sous-système approuvé, il est possible que vous deviez transmettre l'identité de l'appelant initial (son nom et non son contexte de sécurité), pour effectuer un audit au niveau de la base de données, par exemple.

Vous pouvez transmettre l'identité au niveau de l'application à l'aide de paramètres de méthodes et de procédures stockées. Vous pouvez également faire appel à des paramètres de requêtes approuvés (voir l'exemple ci-dessous) pour extraire de la base de données les données spécifiques à des utilisateurs.

SELECT x,y,z FROM SomeTable WHERE UserName = "Alice"
Étapes de configuration

Les tableaux qui suivent décrivent la procédure de configuration du serveur Web et du serveur d'applications.

Configuration du serveur Web
Configuration de IIS

Étape

Informations supplémentaires

Configurez l'authentification IIS.

L'application Web peut adopter n'importe quelle forme d'authentification pour authentifier les appelants initiaux.

Configuration de ASP.NET

Étape

Informations supplémentaires

Configurez l'authentification et vérifiez que l'emprunt d'identité est désactivé.

Modifiez le fichier Web.config qui se trouve dans le répertoire virtuel de votre application Web.
Définissez l'élément <authentication> avec la valeur authentication mode="Windows","Forms","Passport"

<authentication mode="Windows|Forms|Passport" />

Définissez l'élément <identity> comme suit :

<identity impersonate="false" />

(OU supprimez l'élément <identity>)

Redéfinissez le mot de passe du compte ASPNET utilisé pour exécuter ASP.NET OU créez un compte de domaine doté de privilèges minimum pour l'exécution de ASP.NET et spécifiez les informations relatives au compte au niveau de l'élément <processModel> du fichier Web.config.

Pour plus d'informations sur l'accès aux ressources réseau (y compris les services Web) à partir de ASP.NET et sur le choix et la configuration d'un compte de processus pour ASP.NET, consultez les sections « Accès aux ressources réseau » et « Identité de processus pour ASP.NET » du Module 8, « Sécurité ASP.NET ».

Configuration du proxy du service Web

Étape

Informations supplémentaires

Configurez le proxy du service Web pour utiliser les informations d'identification par défaut pour tous les appels transmis au service Web.

Utilisez la ligne de code suivante :

proxy.Credentials = DefaultCredentials;

Configuration du serveur d'applications
Configuration de IIS

Étape

Informations supplémentaires

Désactivez l'accès anonyme pour le répertoire de la racine virtuelle de votre service Web.

Activez l'authentification intégrée de Windows.

 

Configuration de ASP.NET

Étape

Informations supplémentaires

Configurez ASP.NET pour utiliser l'authentification Windows.

Modifiez le fichier Web.config dans le répertoire virtuel du service Web.
Définissez l'élément <authentication> comme suit :

<authentication mode="Windows" />

Désactivez l'emprunt d'identité.

Modifiez le fichier Web.config dans le répertoire virtuel de l'application.
Définissez l'élément <identity> commet suit :

<identity impersonate="false" />

Accès aux ressources système

Pour plus d'informations sur l'accès aux ressources système (au journal des événements et au Registre, par exemple) à partir des services Web ASP.NET, consultez la section « Accès aux ressources système » du Module 8, « Sécurité ASP.NET ». Les méthodes et les limitations évoquées dans le Module 8 s'appliquent également aux services Web ASP.NET.

Accès aux ressources réseau

Lorsque vous accédez aux ressources réseau à partir d'un service Web, vous devez tenir compte de l'identité utilisée pour répondre aux demandes d'authentification réseau émanant de l'ordinateur distant. Trois options se présentent à vous :

  • l'identité du processus (déterminée par le compte utilisé pour l'exécution du processus de travail ASP.NET) ;

  • une identité de service (créée, par exemple, en appelant LogonUser) ;

  • l'identité de l'appelant initial (avec le service Web configuré pour l'emprunt d'identité).

Pour plus d'informations sur les avantages que présentent ces différentes méthodes, ainsi que des détails sur leur configuration, consultez la section « Accès aux ressources réseau » du Module 8, « Sécurité ASP.NET ».

Accès aux objets COM

L'attribut AspCompat (utilisé par les applications Web lorsqu'elles appellent des objets COM à threads cloisonnés) n'est pas disponible pour les services Web. Cela signifie que lorsque vous appelez des objets à modèle cloisonné à partir de services Web, une commutation de threads intervient, et se traduit par une légère baisse en termes de performances. De plus, si votre service Web fait appel à l'emprunt d'identité, votre jeton d'emprunt d'identité est perdu lors de l'appel du composant COM. Cette opération entraîne généralement une exception Accès refusé.

Informations supplémentaires

Utilisation de certificats clients avec les services Web

Cette section décrit des techniques d'utilisation des certificats clients X.509 dans le cadre de l'authentification des services Web.

Vous pouvez utiliser l'authentification des certificats clients dans un service Web pour authentifier les composants suivants :

  • d'autres services Web ;

  • des applications communiquant directement avec le service Web (des applications de bureau de type serveur ou côté client, par exemple).

Authentification de navigateurs Web clients avec des certificats

Un service Web ne peut pas utiliser des certificats clients pour authentifier des appelants si ces derniers communiquent avec une application Web intermédiaire, car le transfert du certificat d'un appelant initial vers le service Web via l'application Web est impossible. Si l'application Web peut utiliser des certificats pour authentifier ses clients, les mêmes certificats ne peuvent être utilisés par le service Web en vue d'une authentification.

La raison de l'échec de ce scénario serveur à serveur vient du fait que l'application Web ne dispose pas d'un accès au certificat du client (plus particulièrement, sa clé privée) dans son magasin de certificats. La figure 10.7 ci-dessous illustre ce problème.

Authentification des certificats clients du service Web

Figure 10.7
Authentification des certificats clients du service Web

Utilisation du modèle de sous-système approuvé

Pour résoudre ce problème et permettre la prise en charge de l'authentification par certificats au niveau du service Web, vous devez faire appel à un modèle de sous-système approuvé. Cette méthode permet au service Web d'authentifier l'application Web à l'aide du certificat de cette dernière (et non le certificat de l'appelant initial). Le service Web doit approuver l'application Web afin qu'elle authentifie ses utilisateurs et qu'elle effectue l'autorisation nécessaire pour s'assurer que seuls les utilisateurs autorisés peuvent accéder aux données et aux fonctionnalités du service Web.

La figure 10.8 ci-dessous illustre cette méthode.

Le service Web authentifie l'application Web approuvée

Figure 10.8
Le service Web authentifie l'application Web approuvée

Si la logique du mécanisme d'autorisation dans le service Web exige plusieurs rôles, l'application Web peut envoyer différents certificats fondés sur l'appartenance de l'appelant à des rôles. Par exemple, vous pouvez utiliser un certificat pour les membres d'un groupe Administrateurs (administrateurs autorisés à mettre à jour des données dans une base de données principale) et un autre certificat pour tous les autres utilisateurs (autorisés uniquement à effectuer des opérations de lecture).

Remarque : dans des scénarios de ce type, vous pouvez utiliser un serveur de certificats local (accessible uniquement aux deux serveurs) pour gérer l'ensemble des certificats de l'application Web.

Dans ce scénario :

  • L'application Web authentifie ses utilisateurs à l'aide de certificats clients.

  • L'application Web agit en tant qu'opérateur de contrôle d'appels, autorise ses utilisateurs et contrôle l'accès au service Web.

  • L'application Web appelle le service Web et transmet un autre certificat représentant l'application (ou, éventuellement, un ensemble de certificats fondés sur l'appartenance de l'appelant à des rôles).

  • Le service Web authentifie l'application Web et l'approuve afin qu'elle autorise les clients.

  • IPSec est utilisé entre l'application Web et le service Web et offre un contrôle d'accès supplémentaire. IPSec empêche toute tentative d'accès non autorisé à partir d'autres ordinateurs. L'authentification par certificats au niveau du serveur du service Web empêche également tout accès non autorisé.

Mise en œuvre d'une solution

Pour utiliser l'authentification par certificats au niveau du service Web dans le cadre de ce scénario, utilisez un processus distinct pour appeler le service Web et transmettre le certificat. Vous ne pouvez pas manipuler les certificats directement à partir de l'application Web ASP.NET, car cette dernière ne présente aucun profil utilisateur chargé ni magasin de certificats associé. Le processus distinct doit être configuré afin d'être exécuté à l'aide d'un compte associé à un profil utilisateur (et à un magasin de certificats). Deux options se présentent à vous :

  • Vous pouvez faire appel à une application serveur Microsoft Enterprise Services.

  • Vous pouvez utiliser un service Windows.

La figure 10.9 illustre ce scénario dans le contexte d'une application serveur Microsoft Enterprise Services.

Authentification de certificats clients avec des services Web

Figure 10.9
Authentification de certificats clients avec des services Web

Les points suivants résument les événements successifs illustrés dans la figure 10.9 :

  1. L'appelant initial est authentifié par l'application Web à l'aide de certificats clients.

  2. Agissant en tant qu'opérateur de contrôle d'appels, l'application Web se charge d'autoriser l'accès à des fonctionnalités spécifiques (notamment celles qui impliquent un échange avec le service Web).

  3. L'application Web appelle un composant desservi exécutant une application Microsoft Enterprise Services out-of-process.

  4. Un profil utilisateur est associé au compte utilisé pour l'exécution de l'application Microsoft Enterprise Services. Le composant accède à un certificat client à partir de son magasin de certificats. Le certificat est utilisé par le service Web pour authentifier l'application Web.

  5. Le composant desservi appelle le service Web et transmet le certificat client lors de chaque demande de méthode. Le service Web authentifie l'application Web à l'aide du certificat et approuve l'application Web afin qu'elle autorise correctement les appelants initiaux.

Pourquoi utiliser un autre processus ?

Si un profil utilisateur contenant un magasin de certificats est requis, vous devez utiliser un processus supplémentaire (plutôt que d'utiliser le processus Web Aspnet_wp.exe pour contacter le service Web).

Une application Web exécutée à l'aide du compte ASPNET n'a pas accès aux certificats résidant sur le serveur Web. En effet, les magasins de certificats sont gérés à partir de profils utilisateur associés à des comptes d'utilisateurs interactifs. Les profils utilisateur sont créés uniquement pour des comptes interactifs lorsque vous vous connectez physiquement à l'aide du compte. Le compte ASPNET n'est pas conçu en tant que compte d'utilisateur interactif ; pour plus de sécurité, il est configuré avec le privilège « Refuser l'ouverture d'une session interactive ».

Important : ne reconfigurez pas le compte ASPNET pour supprimer ce privilège et le transformer en compte d'ouverture de session interactive. Utilisez un processus distinct avec un compte de service configuré pour accéder aux certificats, comme décrit plus haut dans ce module.

Informations supplémentaires
  • Pour plus d'informations sur l'implémentation de cette méthode, consultez la section « Procédure : Appeler un service Web à l'aide de certificats clients à partir de ASPNET » dans ce guide.

  • Pour plus d'informations sur la configuration de IPSec, consultez la section « Procédure : Utiliser IPSec pour fournir une communication sécurisée entre deux serveurs » dans ce guide.

Communication sécurisée

L'objectif d'une communication sécurisée est de garantir l'intégrité et la confidentialité des messages du service Web lors de leur transfert entre applications sur le réseau. Deux méthodes apportent une solution à ce problème. Elles concernent les options applicables au niveau du transport et au niveau des messages.

Options applicables au niveau du transport

Ces options incluent les composants suivants :

  • SSL

  • IPSec

Elles peuvent convenir dans les situations suivantes :

  • Vous envoyez un message directement de votre application à un service Web et ce message n'est pas acheminé par des systèmes intermédiaires.

  • Vous pouvez contrôler la configuration des deux points de terminaison impliqués dans le transfert du message.

Options applicables au niveau des messages

Vous pouvez utiliser cette méthode pour garantir l'intégrité et la confidentialité des messages s'ils sont acheminés par un nombre aléatoire de systèmes intermédiaires. Cela permet de signer les messages pour préserver leur intégrité et offre, pour des raisons de confidentialité, la possibilité de crypter tout ou partie du message.

Utilisez cette méthode dans les situations suivantes :

  • Vous envoyez un message à un service Web et il est probable qu'il soit transmis à d'autres services Web ou acheminé par des systèmes intermédiaires.

  • Vous ne contrôlez pas la configuration des deux points de terminaison (lors de l'envoi de messages d'une société à une autre, par exemple).

Informations supplémentaires

  • Le Kit de développement des services Web (WSDK) fournit des fonctionnalités de cryptage des messages conformes à la spécification WS-Security.

  • Pour plus d'informations sur SSL et IPSec, consultez le Module 4, « Communication sécurisée ».

Résumé

Ce module traite essentiellement de la sécurité des services Web au niveau de la plate-forme et du transport (point à point) assurée par les services sous-jacents des technologies ASP.NET et IIS et du système d'exploitation. Si la sécurité au niveau de la plate-forme offre des solutions sécurisées pour des scénarios intranet étroitement intégrés, elle ne convient pas à des scénarios hétérogènes. La sécurité au niveau des messages, issue de la spécification WS-Security (architecture GXA), est alors nécessaire. Vous pouvez utiliser le Kit de développement des services Web (WSDK) pour mettre en place des solutions de sécurité des services Web au niveau des messages.

Pour les environnements de domaines Windows étroitement intégrés :

  • Si vous souhaitez transmettre l'identité de l'appelant initial d'une application Web ASP.NET vers un service Web distant, l'application Web ASP.NET doit utiliser l'authentification Kerberos (avec des comptes configurés pour la délégation), l'authentification de base ou l'authentification par formulaires.

    • Si vous optez pour l'authentification Kerberos, activez l'emprunt d'identité pour l'application Web, puis configurez la propriété Credentials du proxy du service Web à l'aide de DefaultCredentials.

    • Si vous optez pour l'authentification de base ou l'authentification par formulaires, capturez les informations d'identification de l'appelant, puis définissez la propriété Credentials du proxy du service Web en ajoutant un objet CredentialCache.

Pour les scénarios impliquant uniquement des services Web :

  • Utilisez l'authentification de base ou l'authentification Kerberos et définissez les informations d'identification dans le proxy client.

  • Utilisez une application Microsoft Enterprise Services out-of-process ou un service Windows pour manipuler des certificats X.509 à partir d'applications Web.

  • Dans la mesure du possible, procédez à des vérifications d'autorisation au niveau du système (autorisation de fichiers ou autorisation des URL).

  • Pour des autorisations précises (par exemple au niveau de la méthode Web), utilisez des rôles .NET (de manière déclarative ou impérative).

  • Procédez à l'autorisation de clients non Windows à l'aide de rôles .NET (à l'aide d'un objet GenericPrincipal contenant des rôles).

  • Désactivez les protocoles HTTP-GET et HTTP-POST sur les serveurs de production.

  • Utilisez la sécurité au niveau du transport si le transfert sécurisé de messages via des systèmes intermédiaires ne pose pas problème.

  • Utilisez la sécurité au niveau du transport si les performances de SSL sont acceptables.

  • Utilisez WS-Security et le Kit de développement des services Web (WSDK) pour développer des solutions au niveau des messages.

Afficher:
© 2014 Microsoft