Microsoft.com
Bienvenue Connexion
Le réseau pour les développeurs
 Version imprimable       Envoyer     
Cliquez pour évaluer et commenter
MSDN
MSDN Library
Articles Techniques
Développement .NET
Prescriptive Guidance
Securité
 Module 8 : Sécurité ASP.NET
Module 8 : Sécurité ASP.NET
Dernière mise à jour le 31 août 2004
Sur cette page

Dans ce module Dans ce module
Objectifs Objectifs
S'applique à S'applique à
Architecture de la sécurité ASP.NET Architecture de la sécurité ASP.NET
Stratégies d'authentification et d'autorisation Stratégies d'authentification et d'autorisation
Configuration de la sécurité Configuration de la sécurité
Programmation de la sécurité Programmation de la sécurité
Authentification Windows Authentification Windows
Authentification par formulaires Authentification par formulaires
Authentification Passport Authentification Passport
Authentification personnalisée Authentification personnalisée
Identité de processus pour ASP.NET Identité de processus pour ASP.NET
Emprunt d'identité Emprunt d'identité
Accès aux ressources système Accès aux ressources système
Accès aux objets COM Accès aux objets COM
Accès aux ressources réseau Accès aux ressources réseau
Communication sécurisée Communication sécurisée
Stockage des secrets Stockage des secrets
Sécurisation des états de session et d'affichage Sécurisation des états de session et d'affichage
Considérations sur les batteries de serveurs Internet Considérations sur les batteries de serveurs Internet
Résumé Résumé

Dans ce module

ASP.NET est un outil essentiel dans le cadre du développement d'applications Web distribuées. Il fournit un ensemble de fonctionnalités de sécurité qui facilitent la création d'applications Web sécurisées. ASP.NET est conçu pour fonctionner avec les fonctionnalités de sécurité actuelles de Internet Information Services (IIS), de la plate-forme Windows et de .NET Framework et offre également une grande souplesse et des possibilités d'extension. Vous pouvez ainsi créer des mécanismes de sécurité personnalisés étroitement intégrés dans vos applications.

Ce module fournit des conseils et des recommandations dans le cadre du traitement de l'authentification, de l'autorisation et de la communication sécurisée lors de la création d'applications Web ASP.NET sécurisées.

Remarque : la plupart des recommandations et des conseils présentés dans ce module s'appliquent également au développement de services Web ASP.NET et d'objets .NET Remoting hébergés par ASP.NET (présentés respectivement dans les Modules 10 et 11).

Objectifs

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

  • sécuriser votre application ASP.NET ;

  • sécuriser les données secrètes et les informations d'état gérées par les applications ASP.NET ;

  • comprendre l'architecture de la sécurité des applications ASP.NET et découvrir comment les fonctionnalités de sécurité de IIS, Windows, .NET Framework et ASP.NET fonctionnent ensemble pour assurer la sécurité d'une application Web distribuée ;

  • choisir une stratégie d'authentification et d'autorisation pour votre application ;

  • comprendre l'incidence de l'identité du processus ASP.NET et de l'emprunt d'identité sur la capacité de votre application à accéder aux ressources en aval (fichiers et bases de données, par exemple) ;

  • implémenter le système de sécurité dans votre application Web ASP.NET à l'aide d'une combinaison d'outils de configuration de produits et de techniques de programmation.

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 versions 5.0 et ultérieures

  • Microsoft Active Directory

  • .NET Framework version 1.0 (avec le service pack 2)

  • Visual Studio versions 1.0 .NET et ultérieures

  • Visual C# .NET

  • SQL Server 2000 (avec le service pack 2) et versions ultérieures

Architecture de la sécurité ASP.NET

ASP.NET fonctionne avec IIS, .NET Framework et les services de sécurité sous-jacents fournis par le système d'exploitation afin de proposer plusieurs mécanismes d'authentification et d'autorisation. Ces mécanismes sont résumés dans la figure 8.1.

Services de sécurité ASP.NET

Figure 8.1
Services de sécurité ASP.NET

La figure 8.1 illustre les mécanismes d'authentification et d'autorisation fournis par IIS et ASP.NET. Lorsqu'un client lance une demande Web, la séquence suivante d'événements d'autorisation et d'authentification intervient :

  1. La demande Web HTTP(S) est reçue du réseau. SSL peut être utilisé pour garantir l'identité du serveur (à l'aide de certificats serveur) et éventuellement l'identité du client.

    Remarque : SSL offre également un canal sécurisé pour protéger les données sensibles transmises entre le client et le serveur (et inversement).

  2. IIS authentifie l'appelant à l'aide de l'authentification de base, Digest, intégrée (NTLM ou Kerberos) ou par certificats. Si l'ensemble ou une partie de votre site ne nécessite pas d'accès authentifié, IIS peut être configuré pour l'authentification anonyme. IIS crée un jeton d'accès Windows pour chaque utilisateur authentifié. Si l'authentification anonyme est sélectionnée, IIS crée un jeton d'accès pour le compte d'utilisateur Internet anonyme (IUSR_MACHINE par défaut).

  3. IIS autorise l'appelant à accéder à la ressource demandée. Les autorisations NTFS définies par les listes de contrôle d'accès associées à la ressource demandée sont utilisées pour autoriser l'accès. 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 l'authentification anonyme est utilisée).

  5. ASP.NET authentifie l'appelant.
    Si ASP.NET est configuré pour l'authentification Windows, aucune autre authentification n'intervient à ce stade. ASP.NET accepte tout jeton reçu de IIS.

    Si ASP.NET est configuré pour l'authentification par formulaires, les informations d'identification fournies par l'appelant (à l'aide d'un formulaire HTML) sont authentifiées auprès d'un magasin de données, généralement une base de données Microsoft® SQL Server? ou un service d'annuaire Active Directory®. Si ASP.NET est configuré pour l'authentification Passport, l'utilisateur est redirigé vers un site Passport et le service d'authentification Passport se charge de l'authentification de l'utilisateur.

  6. ASP.NET autorise l'accès à la ressource ou à l'opération demandée.
    Le module UrlAuthorizationModule (module HTTP fourni par le système) utilise les règles d'autorisation configurées dans le fichier Web.config (c'est-à-dire l'élément <authorization>) pour garantir que l'appelant peut accéder au fichier ou au dossier demandé.

    Dans le cadre de l'authentification Windows, le module FileAuthorizationModule (autre module HTTP) vérifie que l'appelant dispose de l'autorisation appropriée pour l'accès à la ressource demandée. Le jeton d'accès de l'appelant est comparé à la liste de contrôle d'accès qui protège la ressource.

    Vous pouvez également utiliser des rôles .NET de manière déclarative ou par programmation pour vous assurer que l'appelant est autorisé à accéder à la ressource demandée ou à effectuer l'opération demandée.

  7. Le code dans votre application accède aux ressources locales et/ou distantes à l'aide d'une identité donnée. Par défaut, ASP.NET ne fait pas appel à l'emprunt d'identité. 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 (si l'emprunt d'identité est activé) ou une identité de service configuré.

Opérateurs de contrôle d'appels

Les points d'autorisation ou opérateurs de contrôle d'appels dans une application Web ASP.NET sont fournis par IIS et ASP.NET :

IIS

Lorsque l'authentification anonyme est désactivée, IIS accepte uniquement les demandes des utilisateurs qu'il est en mesure d'authentifier dans son domaine ou dans un domaine approuvé.

Pour les types de fichiers statiques (par exemple les fichiers .jpg, .gif et .htm qui ne sont pas mappés à une extension ISAPI), IIS utilise les autorisations NTFS associées au fichier demandé pour procéder au contrôle d'accès.

ASP.NET

Les opérateurs de contrôle d'appels ASP.NET comprennent les modules UrlAuthorizationModule et FileAuthorizationModule , ainsi que les demandes PrincipalPermission et les vérifications de rôles.

UrlAuthorizationModule

Vous pouvez configurer des éléments <authorization> dans le fichier Web.config de l'application pour déterminer les utilisateurs et les groupes d'utilisateurs qui peuvent accéder à l'application. Le mécanisme d'autorisation repose sur l'objet IPrincipal stocké dans HttpContext.User.

FileAuthorizationModule

Pour les types de fichiers mappés par IIS à l'extension ISAPI de ASP.NET (Aspnet_isapi.dll), des vérifications d'accès automatiques sont réalisées à l'aide du jeton d'accès Windows de l'utilisateur authentifié (qui peut être IUSR_MACHINE) par rapport à la liste de contrôle d'accès associée au fichier ASP.NET demandé.

Remarque : l'emprunt d'identité n'est pas indispensable au fonctionnement de l'autorisation de fichiers.

La classe FileAuthorizationModule procède uniquement à des vérifications d'accès pour le fichier demandé, et non pour les fichiers auxquels le code accède dans la page demandée, bien que les vérifications d'accès de ceux-ci soient effectuées par IIS.

Par exemple, si vous demandez le fichier Default.aspx et si celui-ci contient un contrôle utilisateur incorporé (Usercontrol.ascx), qui à son tour comprend une balise d'image (pointant vers Image.gif), FileAuthorizationModule réalise une vérification d'accès pour Default.aspx et Usercontrol.ascx, car ces types de fichiers sont mappés par IIS à l'extension ASAPI de ASP.NET.

FileAuthorizationModule n'effectue pas de vérification pour Image.gif, car il s'agit d'un fichier statique géré en interne par IIS. Toutefois, dans la mesure où les vérifications d'accès des fichiers statiques sont réalisées par IIS, l'utilisateur authentifié doit bénéficier d'un accès en lecture au fichier à l'aide d'une liste de contrôle d'accès configurée correctement.

Ce scénario est présenté dans la figure 8.2.

Remarque à l'attention des administrateurs système : l'utilisateur authentifié nécessite des autorisations de lecture NTFS sur tous les fichiers impliqués dans le scénario. La seule variable concerne l'opérateur de contrôle d'appel qui est utilisé pour appliquer le contrôle d'accès. Le compte du processus ASP.NET requiert uniquement un accès en lecture aux types de fichiers ASP.NET inscrits.

Collaboration des opérateurs de contrôle d'appels IIS et ASP.NET

Figure 8.2
Collaboration des opérateurs de contrôle d'appels IIS et ASP.NET

Dans ce scénario, vous pouvez empêcher l'accès au niveau du portail de fichiers. Si vous configurez la liste de contrôle d'accès associée à Default.aspx et que vous refusez l'accès à un utilisateur donné, le contrôle utilisateur ou les images incorporées ne pourront pas être envoyés au client par le code dans Default.aspx. Si l'utilisateur demande les images directement, IIS effectue alors les vérifications d'accès.

Demandes PrincipalPermission et vérifications explicites de rôles

En plus des opérateurs de contrôle d'appels configurables de IIS et de ASP.NET, vous pouvez également faire appel aux demandes PrincipalPermission (de manière déclarative ou par programmation) comme mécanisme supplémentaire et précis de contrôle d'accès. Les vérifications PrincipalPermission (effectuées par la classe PrincipalPermissionAttribute) vous permettent de gérer l'accès aux classes, aux méthodes ou aux blocs de code en fonction de l'identité des différents utilisateurs et des groupes auxquels ils appartiennent, comme le définit l'objet IPrincipal associé au thread actif.

Remarque : les demandes PrincipalPermission utilisées pour demander l'appartenance aux rôles diffèrent de l'appel à IPrincipal.IsInRole pour tester l'appartenance aux rôles. Dans le premier cas, une exception est générée si l'appelant n'est pas membre du rôle spécifié, tandis que dans le deuxième cas, seule une valeur booléenne est renvoyée pour confirmer l'appartenance aux rôles.

Dans le cadre de l'authentification Windows, ASP.NET associe automatiquement un objet WindowsPrincipal représentant l'utilisateur authentifié à la demande Web en cours (à l'aide de HttpContext.User). L'authentification par formulaires et l'authentification Passport créent un objet GenericPrincipal contenant l'identité appropriée et aucun rôle, puis l'associent à l'objet HttpContext.User.

Informations supplémentaires

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

  • Pour plus d'informations sur la programmation de la sécurité (et les objets IPrincipal), consultez la section « Programmation de la sécurité » plus loin dans ce module.

Stratégies d'authentification et d'autorisation

ASP.NET propose plusieurs mécanismes d'autorisation déclarative et par programmation, qui peuvent être utilisés avec différents modes d'authentification. Vous pouvez ainsi développer une stratégie d'autorisation renforcée et une autre stratégie, qui peut être configurée pour offrir différents degrés de précision, par exemple par utilisateur ou par groupe d'utilisateurs (en fonction des rôles).

Cette section présente les options d'autorisation (configurables et par programmation) disponibles pour un ensemble d'options d'authentification couramment utilisées.

Ces options d'authentification sont récapitulées ci-dessous :

  • Authentification Windows avec emprunt d'identité

  • Authentification Windows sans emprunt d'identité

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

  • Authentification par formulaires

  • Authentification Passport

Options d'autorisation disponibles

Le tableau suivant présente les différentes options d'autorisation disponibles. Pour chaque option, le tableau indique si l'authentification Windows et/ou l'emprunt d'identité sont requis. Si l'authentification Windows n'est pas indispensable, l'option d'autorisation concernée est disponible pour tous les autres types d'authentification. Ce tableau vous permet d'affiner votre stratégie d'authentification ou d'autorisation.

Tableau 8.1 : Configuration de l'authentification Windows et de l'emprunt d'identité

Option d'autorisation

Authentification Windows requise

Emprunt d'identité requis

FileAuthorizationModule

Oui

Non

UrlAuthorizationModule

Non

Non

Demandes PrincipalPermission

Non

Non

Rôles .NET

Non

Non

Rôles Microsoft Enterprise Services

Oui

Oui (dans l'application Web ASP.NET)

Autorisations NTFS (pour les types de fichiers statiques demandés directement, non mappés à une extension ISAPI)

N/A - Ces fichiers ne sont pas gérés par ASP.NET.
Avec tout mécanisme d'authentification IIS (non anonyme), les autorisations doivent être configurées individuellement pour les utilisateurs authentifiés.
Avec l'authentification anonyme, les autorisations doivent être configurées pour IUSR_MACHINE.

Non (IIS effectue la vérification d'accès.)

Autorisations NTFS (pour les fichiers accessibles par le code de l'application Web)

Non

Non
Si l'emprunt d'identité est utilisé, configurez les listes de contrôle d'accès par rapport à l'identité Windows empruntée, qui est soit l'appelant initial, soit l'identité indiquée sur l'élément <identity> dans le fichier Web.config.

Authentification Windows avec emprunt d'identité

Les éléments de configuration suivants vous 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 application dans le fichier Web.config qui lui est associé.

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

Dans cette configuration, le code de votre application Web prend l'identité de l'appelant authentifié par IIS.

Sécurité configurable

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

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

    • Ressources demandées par les clients. Le module ASP.NET FileAuthorizationModule effectue les vérifications d'accès des types de fichiers demandés qui sont mappés à l'extension ISAPI de ASP.NET. Il utilise le jeton d'accès de l'appelant initial et la liste de contrôle d'accès associée aux ressources demandées afin d'effectuer les vérifications d'accès.
      Pour les types de fichiers statiques (non mappés à une extension ISAPI), IIS effectue les vérifications d'accès à l'aide du jeton d'accès de l'appelant et de la liste de contrôle d'accès associée au fichier.

    • Ressources accessibles par votre application. Vous pouvez configurer des listes de contrôle d'accès Windows pour les ressources auxquelles votre application accède (fichiers, dossiers, clés du Registre, objets Active Directory, etc.) par rapport à l'appelant initial.

  • Autorisation des URL. Vous pouvez configurer l'autorisation des URL dans le fichier Web.config. Dans le cadre de l'authentification Windows, les noms d'utilisateurs prennent 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>

  • Rôles Microsoft Enterprise Services (COM+). Les rôles sont gérés dans le catalogue COM+. Vous pouvez utiliser l'outil d'administration des Services de composants ou un script pour configurer les rôles.

Sécurité par programmation

La sécurité par programmation désigne les vérifications de la sécurité situées dans le code de votre application Web. Les options de sécurité par programmation disponibles lors de l'utilisation de l'emprunt d'identité et de l'authentification Windows sont les suivantes :

  • Demandes PrincipalPermission

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

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

    • Déclarative (des attributs précèdent les interfaces, les classes et les méthodes)

      [PrincipalPermission(SecurityAction.Demand, 
                  Role=@"NomDomaine\GroupeWindows)]

  • Vérifications de rôles explicites. Vous pouvez vérifier les rôles à l'aide de l'interface IPrincipal.

    IPrincipal.IsInRole(@"NomDomaine\GroupeWindows");

  • Rôles Microsoft Enterprise Services (COM+). Vous pouvez vérifier les rôles par programmation à l'aide de la classe ContextUtil.

    ContextUtil.IsCallerInRole("Responsable")
Contexte d'utilisation

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

  • Les utilisateurs de votre application disposent de comptes Windows qui peuvent être authentifiés par le serveur.

  • Vous devez transmettre le contexte de sécurité de l'appelant initial au niveau intermédiaire (« middle-tier ») et/ou au niveau des données de votre application Web pour prendre en charge 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.

Avant d'utiliser l'emprunt d'identité dans votre application, mesurez les compromis qu'implique cette méthode par rapport à l'utilisation du modèle de sous-système approuvé. Ce point est développé dans le paragraphe « Choix d'un modèle d'accès aux ressources » de la section « Méthodes d'autorisation » dans le Module 3, « Authentification et autorisation ».

Les inconvénients de l'emprunt d'identité sont les suivants :

  • Évolutivité limitée de l'application en raison de l'incapacité à regrouper efficacement les connexions à des bases de données.

  • Administration plus lourde dans la mesure où les listes de contrôle d'accès associées aux ressources principales doivent être configurées individuellement pour chaque utilisateur.

  • La délégation requiert l'authentification Kerberos et un environnement configuré correctement.

Informations supplémentaires

  • Pour plus d'informations sur l'authentification Windows, consultez la section « Authentification Windows » plus loin dans ce module.

  • Pour plus d'informations sur l'emprunt d'identité, consultez la section « Emprunt d'identité » plus loin dans ce module.

  • Pour plus d'informations sur l'autorisation des URL, consultez la section « Remarques concernant les autorisations d'URL » plus loin dans ce module.

  • Pour plus d'informations sur les rôles Microsoft Enterprise Services (COM+), consultez le Module 9, « Sécurité des services Microsoft Enterprise Services ».

Authentification Windows sans emprunt d'identité

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

<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

    • Ressources demandées par les clients. Le module ASP.NET FileAuthorizationModule effectue les vérifications d'accès des types de fichiers demandés qui sont mappés à l'extension ISAPI de ASP.NET. Il utilise le jeton d'accès de l'appelant initial et la liste de contrôle d'accès associée aux ressources demandées afin d'effectuer les vérifications d'accès. L'emprunt d'identité n'est pas obligatoire.
      Pour les types de fichiers statiques (non mappés à une extension ISAPI), IIS effectue les vérifications d'accès à l'aide du jeton d'accès de l'appelant et de la liste de contrôle d'accès associée au fichier.

    • Ressources accessibles à votre application. Configurez les listes de contrôle d'accès Windows pour les ressources auxquelles votre application accède (fichiers, dossiers, clés du Registre, objets Active Directory) par rapport à l'identité du processus ASP.NET.

  • Autorisation des URL. Configurez l'autorisation des URL dans le fichier Web.config. Dans le cadre de l'authentification Windows, les noms d'utilisateurs prennent 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

Les options de sécurité par programmation ci-après sont disponibles :

  • Demandes PrincipalPermission

    • Impérative

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

    • Déclarative

      [PrincipalPermission(SecurityAction.Demand, 
                  Role=@"NomDomaine\GroupeWindows")]

  • 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 :

  • Les utilisateurs de votre application disposent de comptes Windows qui peuvent être authentifiés par le serveur.

  • Vous souhaitez utiliser une identité fixe pour accéder aux ressources en aval (par exemple des bases de données) afin de prendre en charge le regroupement de connexions.

Informations supplémentaires

  • Pour plus d'informations sur l'authentification Windows, consultez la section « Authentification Windows » plus loin dans ce module.

  • Pour plus d'informations sur l'autorisation des URL, consultez la section « Remarques concernant les autorisations d'URL » plus loin dans ce module.

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

L'élément <identity> du fichier Web.config prend en charge des attributs de nom d'utilisateur et de mot de passe facultatifs, ce qui vous permet de configurer une identité fixe spécifique que votre application Web peut emprunter. L'extrait 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 illustre l'élément <identity>, selon 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 ne nécessite pas le privilège « Fonctionner en tant que partie intégrante du système d'exploitation ».

Authentification par formulaires

Les éléments de configuration suivants vous indiquent comment activer l'authentification par formulaires de manière déclarative dans le fichier Web.config.

<authentication mode="Forms">
  <forms loginUrl="logon.aspx" name="AuthCookie" timeout="60" path="/">
  </forms>
</authentication>
Sécurité configurable

Lorsque vous utilisez l'authentification par formulaires, les options d'autorisation disponibles sont les suivantes :

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

    • Ressources demandées par les clients. Les ressources demandées nécessitent des listes de contrôle d'accès qui permettent un accès en lecture au compte d'utilisateur Internet anonyme (IIS doit être configuré pour permettre l'accès anonyme lorsque vous utilisez l'authentification par formulaires).
      L'autorisation de fichiers ASP.NET n'est pas disponible, car elle nécessite l'authentification Windows.

    • Ressources accessibles par votre application. Configurez des listes de contrôle d'accès Windows pour les ressources auxquelles votre application accède (fichiers, dossiers, clés du Registre et objets Active Directory) par rapport à l'identité du processus ASP.NET.

  • Autorisation des URL

    Configurez l'autorisation des URL dans le fichier Web.config. Dans le cadre de l'authentification par formulaires, le format des noms d'utilisateurs est déterminé par votre magasin de données personnalisé (une base de données SQL Server ou Active Directory).

    • Si vous utilisez un magasin de données SQL Server :

      <authorization>
<deny users="?" />
  <allow users="Marie,Bernard,Jean" roles="Responsable,Ventes" />
</authorization>

    • Si vous utilisez Active Directory comme magasin de données, les noms d'utilisateurs et les noms de groupes apparaissent au format X.500 : 

      <authorization>
  <deny users="unCompte@domaine.corpe.votreEntreprise.com" />
  <allow roles ="CN=Soulier Jérôme,CN=FTE_amériquenord,CN=Utilisateurs,
                DC=domain,DC=corp,DC=votreEntreprise,DC=com" />
</authorization>
Sécurité par programmation

Les options de sécurité par programmation ci-après sont disponibles :

  • Demandes PrincipalPermission

    • Impérative

          PrincipalPermission permCheck = new PrincipalPermission(
                                         null, "Responsable");
    permCheck.Demand();

    • Déclarative

      [PrincipalPermission(SecurityAction.Demand, 
                  Role="Responsable")]

  • Vérifications de rôles explicites. Vous pouvez vérifier les rôles à l'aide de l'interface IPrincipal.

    IPrincipal.IsInRole("Responsable");
Contexte d'utilisation

L'authentification par formulaires est la plus adaptée pour les applications Internet. Utilisez l'authentification par formulaires dans les cas suivants :

  • Les utilisateurs de votre application ne disposent pas de comptes Windows.

  • Vous souhaitez que les utilisateurs se connectent à votre application en entrant des informations d'identification dans un formulaire HTML.

Informations supplémentaires

  • Pour plus d'informations sur l'authentification par formulaires, consultez la section « Authentification par formulaires » plus loin dans ce module.

  • Pour plus d'informations sur l'autorisation des URL, consultez la section « Remarques concernant les autorisations d'URL » plus loin dans ce module.

Authentification Passport

Les éléments de configuration suivants vous indiquent comment activer l'authentification Passport de manière déclarative dans le fichier Web.config.

<authentication mode="Passport" />
Contexte d'utilisation

L'authentification Passport est utilisée sur Internet lorsque les utilisateurs d'applications ne disposent pas de comptes Windows et que vous voulez implémenter une solution reposant sur une connexion unique. Les utilisateurs qui se sont préalablement connectés avec un compte Passport sur un site Passport participant n'auront pas à se connecter à votre site configuré avec l'authentification Passport.

Configuration de la sécurité

Cette section décrit la procédure à suivre pour configurer la sécurité d'une application Web ASP.NET. Cette procédure est résumée dans la figure 8.3.

Configuration de la sécurité d'une application ASP.NET

Figure 8.3
Configuration de la sécurité d'une application ASP.NET

Configuration des paramètres IIS

Pour configurer la sécurité IIS, vous devez effectuer les opérations suivantes :

  1. Installez éventuellement un certificat de serveur Web (si SSL est requis).

    Pour plus d'informations, consultez la section « Procédure : Configurer SSL sur un serveur Web » dans ce guide.

  2. Configurez l'authentification IIS.

  3. Configurez éventuellement le mappage des certificats clients (si vous utilisez l'authentification par certificats).

    Pour plus d'informations sur le mappage des certificats clients, consultez l'article Q313070, « How To: Configure Client Certificate Mappings in Internet Information Services (IIS) 5.0 » (en anglais) de la Base de connaissances Microsoft.

  4. Définissez les autorisations NTFS pour les fichiers et les dossiers. Entre eux, IIS et le module ASP.NET FileAuthorizationModule vérifient que l'utilisateur authentifié (ou le compte d'utilisateur Internet anonyme) bénéficie des droits d'accès nécessaires (en fonction des paramètres des listes de contrôle d'accès) pour accéder au fichier demandé.

Configuration des paramètres ASP.NET

Les paramètres de configuration au niveau de l'application sont gérés dans des fichiers Web.config, qui sont situés dans le répertoire de la racine virtuelle de votre application et éventuellement dans des sous-dossiers supplémentaires (ces paramètres peuvent parfois remplacer les paramètres des dossiers parents).

  1. Configuration de l'authentification. L'authentification doit être définie au niveau de chaque application Web (et non dans le fichier Machine.config) dans le fichier Web.config situé dans le répertoire de la racine virtuelle de l'application Web. 

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

  2. Configuration de l'emprunt d'identité. Par défaut, les applications ASP.NET n'utilisent pas l'emprunt d'identité. Les applications sont exécutées à l'aide de l'identité du processus ASP.NET configuré (généralement ASPNET) et l'accès aux ressources effectué par votre application utilise cette identité. Vous devez faire appel à l'emprunt d'identité uniquement dans les cas suivants :

    • Vous faites appel aux services Microsoft Enterprise Services et vous souhaitez utiliser les rôles Microsoft Enterprise Services (COM+) pour autoriser l'accès aux fonctionnalités fournies par les composants desservis.

    • IIS est configuré pour l'authentification anonyme et vous souhaitez faire appel au compte d'utilisateur Internet anonyme pour l'accès aux ressources. Pour plus d'informations sur cette méthode, consultez la section « Accès aux ressources réseau » plus loin dans ce module.

    • Vous devez transmettre le contexte de sécurité de l'utilisateur authentifié au niveau suivant (la base de données, par exemple).

    • Vous avez migré une application ASP classique vers ASP.NET et vous souhaitez conserver le même comportement d'emprunt d'identité. Les applications ASP classiques empruntent par défaut l'identité de l'appelant.

    Pour configurer l'emprunt d'identité ASP.NET, utilisez l'élément <identity> suivant dans le fichier Web.config de votre application.

    <identity impersonate="true" />

  3. Configuration de l'autorisation. L'autorisation des URL détermine si un utilisateur ou un rôle peut émettre des verbes HTTP spécifiques (par exemple, GET, HEAD et POST) sur un fichier donné. Pour implémenter l'autorisation des URL, vous devez effectuer les tâches suivantes.

    1. Ajoutez un élément <authorization> au fichier Web.config situé dans le répertoire de la racine virtuelle de votre application.

    2. Limitez l'accès aux utilisateurs et aux rôles en utilisant les attributs allow et deny. L'exemple suivant issu du fichier Web.config utilise l'authentification Windows et autorise l'accès à Bernard et à Marie, mais interdit l'accès à tout autre utilisateur.

      <authorization>
  <allow users="NomDomaine\Bernard, NomDomaine\Marie" />
  <deny users="*" />
</authorization>

      Important : vous devez ajouter <deny users="?"/> ou <deny users="*"/> à la fin de l'élément <authorization>. Sinon, l'accès est accordé à toutes les identités authentifiées.

Remarques concernant les autorisations d'URL

Prenez en compte les éléments suivants lorsque vous configurez l'autorisation des URL :

  • « * » fait référence à toutes les identités.

  • "?" fait référence aux identités non authentifiées (c'est-à-dire l'identité anonyme).

  • L'emprunt d'identité n'est pas indispensable au fonctionnement de l'autorisation des URL.

  • Les paramètres d'autorisation du fichier Web.config font généralement référence à tous les fichiers du répertoire actif et de tous les sous-répertoires (sauf si un sous-répertoire contient son propre fichier Web.config avec un élément <authorization> ; dans ce cas, les paramètres du sous-répertoire remplacent les paramètres du répertoire parent).

    Remarque : l'autorisation des URL s'applique uniquement aux types de fichiers qui sont mappés par IIS à l'extension ISAPI de ASP.NET, aspnet_isapi.dll.

    Vous pouvez faire appel à la balise <location> pour appliquer les paramètres d'autorisation à un fichier ou à un répertoire donné. L'exemple suivant indique comment appliquer l'autorisation à un fichier spécifique (Page.aspx).

    <location path="page.aspx" />
  <authorization>
    <allow users="NomDomaine\Bernard, NomDomaine\Marie" />
    <deny users="*" />
  </authorization>
</location>

  • Les utilisateurs et les rôles pour l'autorisation des URL sont déterminés par vos paramètres d'authentification :

    • Lorsque vous utilisez <authentication mode="Windows" />, vous autorisez l'accès aux comptes d'utilisateurs et de groupes Windows.

      Les noms d'utilisateurs prennent la forme « NomDomaine\NomUtilisateurWindows »

      Les noms de rôles prennent la forme « NomDomaine\NomGroupeWindows »

      Remarque : le groupe Administrateurs local est désigné par « BUILTIN\Administrators ». Le groupe Utilisateurs local est signalé par « BUILTIN\Users ».

    • Lorsque vous utilisez <authentication mode="Forms" />, vous autorisez, pour l'utilisateur et les rôles, l'objet IPrincipal qui était stocké dans le contexte HTTP actif. Par exemple, si vous utilisiez des formulaires pour authentifier les utilisateurs auprès d'une base de données, vous effectuerez l'autorisation par rapport aux rôles extraits de la base de données.

    • Lorsque vous utilisez <authentication mode="Passport" />, vous effectuez l'autorisation par rapport à l'ID utilisateur Passport (PUID) ou aux rôles extraits d'un magasin. Vous pouvez par exemple mapper un PUID à un compte donné et à un ensemble de rôles stockés dans une base de données SQL Server ou dans Active Directory.

      Remarque : cette fonctionnalité sera intégrée dans le système d'exploitation Microsoft Windows .NET Server 2003.

    • Lorsque vous utilisez <authentication mode="None" />, il est possible que l'autorisation ne soit pas réalisée. « None » spécifie que vous ne souhaitez pas effectuer d'authentification ou que vous souhaitez utiliser votre propre mécanisme personnalisé (et aucun des modules d'authentification .NET).
      Toutefois, si vous faites appel à l'authentification personnalisée, vous devez créer un objet IPrincipal avec des rôles et le stocker dans HttpContext.User. Si vous faites ensuite appel à l'autorisation des URL, celle-ci est réalisée par rapport à l'utilisateur et aux rôles (quelle que soit la méthode d'extraction employée) gérés dans l'objet IPrincipal.

Exemples d'autorisation des URL

La liste suivante présente la syntaxe de certains exemples courants d'autorisation des URL :

  • Refuser l'accès au compte anonyme

     <deny users="?" />

  • Refuser l'accès à tous les utilisateurs

    <deny users="*"/>

  • Refuser l'accès au rôle Responsable

    <deny roles="Responsable"/>

  • Exemple d'authentification par formulaires 

    <configuration>
  <system.web>
      <authentication mode="Forms">
        <forms name=".ASPXUSERDEMO" 
               loginUrl="login.aspx" 
               protection="All" timeout="60" />
      </authentication>
      <authorization>
        <deny users="jdoe@somewhere.com" />
        <deny users="?" />
      </authorization>
  </system.web>
</configuration>

Remarque : le fonctionnement de l'élément <authorization> est lié à l'objet IPrincipal actif stocké dans HttpContext.User et à la méthode de transfert de données HTTP stockée dans HttpContext.Request.RequestType.

Ressources sécurisées

  1. Utilisez des listes de contrôle d'accès Windows pour sécuriser les ressources qui incluent des fichiers, des dossiers et des clés du Registre.
    Si vous n'utilisez pas l'emprunt d'identité, les ressources auxquelles votre application doit accéder doivent utiliser une liste de contrôle d'accès qui accorde au moins un accès en lecture au compte du processus ASP.NET.

    Si vous utilisez l'emprunt d'identité, les fichiers et les clés du Registre doivent utiliser une liste de contrôle d'accès qui accorde au moins un accès en lecture à l'utilisateur authentifié (ou au compte d'utilisateur Internet anonyme, si l'authentification anonyme est appliquée).

  2. Sécurisez les fichiers Web.config et Machine.config :

    • Utilisez des listes de contrôle d'accès correctes. Si ASP.NET utilise l'emprunt d'identité, l'identité empruntée requiert un accès en lecture. Dans le cas contraire, l'identité du processus ASP.NET nécessite un accès en lecture. Utilisez la liste de contrôle d'accès suivante pour les fichiers Web.config et Machine.config.

      Système : Contrôle total

      Administrateurs : Contrôle total

      Identité du processus ou identité empruntée : Lecture

      Si vous n'empruntez pas l'identité du compte d'utilisateur Internet anonyme (IUSR_MACHINE), vous devez refuser l'accès à ce compte.

      Remarque : si votre application est mappée à un partage UNC, l'identité UNC nécessite également un accès en lecture aux fichiers de configuration.

    • Supprimez les modules HTTP inutiles. Le fichier Machine.config contient un ensemble de modules HTTP par défaut, dans l'élément <httpModules>, notamment :

      • WindowsAuthenticationModule

      • FormsAuthenticationModule

      • PassportAuthenticationModule

      • UrlAuthorizationModule

      • FileAuthorizationModule

      • OutputCacheModule

      • SessionStateModule

      Si votre application n'utilise pas un module, supprimez-le pour éliminer les problèmes de sécurité potentiels liés à l'exploitation d'un module au sein de votre application.

  3. Si vous le souhaitez, vous pouvez verrouiller les paramètres de configuration en utilisant l'élément <location> avec l'attribut allowOverride="false" , comme décrit ci-dessous.

Verrouillage des paramètres de configuration

Les paramètres de configuration sont hiérarchiques. Les paramètres des fichiers Web.config dans les sous-répertoires se substituent aux paramètres des fichiers Web.config des répertoires parents. De plus, les paramètres du fichier Web.config se substituent aux paramètres du fichier Machine.config.

L'élément <location> associé à l'attribut allowOverride permet de verrouiller les paramètres de configuration afin qu'ils ne soient pas remplacés à des niveaux inférieurs. Par exemple :

<location path="somepath" allowOverride="false" />
 . . . paramètres de configuration arbitraires .  . .
</location>

Notez que le chemin peut faire référence à un site Web ou un à répertoire virtuel et qu'il s'applique au répertoire nommé et à tous les sous-répertoires. Si vous attribuez la valeur « false » à allowOverride , aucun fichier de configuration de niveau inférieur ne pourra remplacer les paramètres indiqués dans l'élément <location>. La capacité à verrouiller les paramètres de configuration s'applique à tous les types de paramètres, et pas uniquement aux paramètres de sécurité tels que les modes d'authentification.

Dans le contexte du fichier Machine.config, le chemin d'accès complet doit être fourni et inclure le site Web, le nom du répertoire virtuel et, facultativement, un sous-répertoire et un nom de fichier. Par exemple :

<location path="Nom site Web/NomRépVirt/NomSousRép/NomPage.aspx" >
 . . .
</location>

Dans le contexte du fichier Web.config, le chemin d'accès est relatif au répertoire virtuel de l'application. Par exemple :

<location path="SubDirName/PageName.aspx" >
. . .
</location>
Interdiction des téléchargements de fichiers

Vous pouvez faire appel à la classe HttpForbiddenHandler pour empêcher le téléchargement de certains types de fichiers sur le Web. Cette classe est utilisée en interne par ASP.NET pour empêcher le téléchargement de certains fichiers au niveau du système (les fichiers de configuration, par exemple, et notamment web.config). Pour obtenir la liste complète des types de fichiers ainsi limités, consultez la section <httpHandlers> du fichier Machine.config.

Vous pouvez envisager d'utiliser HttpForbiddenHandler pour les fichiers que votre application utilise en interne, mais qui ne sont pas destinés à être téléchargés.

Remarque : vous devez également sécuriser les fichiers à l'aide de listes de contrôle d'accès Windows pour déterminer les utilisateurs qui peuvent accéder aux fichiers lorsqu'ils sont connectés au serveur Web.

  • Pour utiliser HttpForbiddenHandler afin d'empêcher le téléchargement d'un type de fichier donné

    1. Créez un mappage d'application dans IIS pour le type de fichier spécifié afin de le mapper à Aspnet_isapi.dll.

      1. Dans la barre des tâches, cliquez sur le bouton Démarrer, sur Programmes, sur Outils d'administration, puis sélectionnez Internet Information Services (IIS).

      2. Sélectionnez le répertoire virtuel de votre application, cliquez avec le bouton droit, puis cliquez sur Propriétés.

      3. Sélectionnez Paramètres de l'application, puis cliquez sur Configuration.

      4. Cliquez sur Ajouter pour créer un mappage d'application.

      5. Cliquez sur Parcourir, puis sélectionnez
        c:\winnt\Microsoft.NET\Framework\v1.0.3705\aspnet_isapi.dll.

      6. Entrez l'extension du type de fichier dont vous souhaitez empêcher le téléchargement (par exemple, .abc) dans le champ Extension.

      7. Vérifiez que les options Tous les verbes et Moteur de script sont sélectionnées et que l'option Vérifier l'existence du fichier n'est pas sélectionnée.

      8. Cliquez sur OK pour fermer la boîte de dialogue Ajout/modification de mappage d'extension d'application.

      9. Cliquez sur OK pour fermer la boîte de dialogue Configuration de l'application, puis de nouveau sur OK pour fermer la boîte de dialogue Propriétés.

    2. Ajoutez un mappage <HttpHandler> pour le type de fichier spécifié dans le fichier Web.config.

      Un exemple pour le type de fichier .abc est présenté ci-après.

      <httpHandlers>
  <add verb="*" path="*.abc" 
    type="System.Web.HttpForbiddenHandler"/>
</httpHandlers>

Communication sécurisée

Utilisez les protocoles SSL et IPSec (Internet Protocol Security) pour sécuriser les liaisons de communication.

Informations supplémentaires

  • Pour plus d'informations sur l'utilisation de SSL pour sécuriser la liaison au serveur de base de données, consultez la section « Procédure : Utiliser SSL pour sécuriser les communications avec SQL Server 2000 ».

  • 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 ».

Programmation de la sécurité

Une fois que vous avez défini les paramètres de sécurité configurables de votre application Web, vous devez améliorer et affiner la stratégie d'autorisation de celle-ci par programmation. Dans cette optique, vous faites appel à des attributs .NET déclaratifs dans vos assemblys et effectuez des vérifications d'autorisation impératives dans le code.

Cette section décrit les étapes de programmation qui sont indispensables pour procéder à l'autorisation dans une application Web ASP.NET.

Mode d'autorisation

Le modèle de base d'autorisation des utilisateurs dans votre application Web est présenté ci-après :

  1. Récupérez les informations d'identification.

  2. Validez les informations d'identification.

  3. Placez les utilisateurs dans des rôles.

  4. Créez un objet IPrincipal.

  5. Placez l'objet IPrincipal dans le contexte HTTP actuel.

  6. Procédez à l'autorisation en fonction de l'identité des utilisateurs et des rôles auxquels ils appartiennent.

Important : les étapes 1 à 5 sont effectuées automatiquement par ASP.NET si vous avez configuré l'authentification Windows. Pour les autres mécanismes d'authentification (par formulaires, Passport et méthodes personnalisées), vous devez rédiger un code pour réaliser ces étapes, comme décrit ci-après.

Récupération des informations d'identification

Vous devez commencer par récupérer les informations d'identification (nom d'utilisateur et mot de passe) de l'utilisateur. Si votre application n'utilise pas l'authentification Windows, vous devez vérifier que les informations d'identification en texte brut sont correctement sécurisées sur le réseau à l'aide de SSL.

Validation des informations d'identification

Si vous avez configuré l'authentification Windows, les informations d'identification sont validées automatiquement à l'aide des services sous-jacents du système d'exploitation.

Si vous utilisez un autre mécanisme d'authentification, vous devez rédiger un code pour valider les informations d'identification auprès d'un magasin de données tel qu'une base de données SQL Server ou Active Directory.

Pour plus d'informations sur le stockage sécurisé des informations d'identification des utilisateurs dans une base de données SQL Server, consultez la section « Authentification des utilisateurs auprès d'une base de données » du Module 12, « Sécurité de l'accès aux données ».

Placement des utilisateurs dans des rôles

Votre magasin de données utilisateur doit également contenir la liste des rôles de chaque utilisateur. Vous devez rédiger un code pour récupérer la liste des rôles de l'utilisateur validé.

Création d'un objet IPrincipal

L'autorisation est effectuée par rapport à l'utilisateur authentifié, dont l'identité et la liste des rôles sont gérés dans un objet IPrincipal (qui est transmis dans le contexte de la demande Web active).

Si vous avez configuré l'authentification Windows, ASP.NET construit automatiquement un objet WindowsPrincipal. Il contient l'identité de l'utilisateur authentifié ainsi qu'une liste des rôles, qui correspond à la liste des groupes Windows auxquels l'utilisateur appartient.

Si vous utilisez l'authentification par formulaires, Passport ou personnalisée, vous devez rédiger un code dans le gestionnaire d'événements Application_AuthenticateRequest de Global.asax pour créer un objet IPrincipal. La classe GenericPrincipal est fournie par .NET Framework et doit être utilisée dans la plupart des scénarios.

Placement de l'objet IPrincipal dans le contexte HTTP actuel

Associez l'objet IPrincipal au contexte HTTP actif (à l'aide de la variable HttpContext.User). ASP.NET effectue cette opération automatiquement lorsque vous utilisez l'authentification Windows. Dans le cas contraire, vous devez associer l'objet manuellement.

Autorisation reposant sur l'identité des utilisateurs et les rôles auxquels ils appartiennent

Utilisez des rôles .NET de manière déclarative (pour obtenir l'autorisation au niveau de la méthode ou de la classe) ou de manière impérative dans le code si votre application nécessite une logique d'autorisation plus précise.

Vous pouvez utiliser des demandes PrincipalPermission déclaratives ou impératives (à l'aide de la classe PrincipalPermission) ou effectuer des vérifications de rôles explicites en appelant la méthode IPrincipal.IsInRole().

Une demande PrincipalPermission déclarative est présentée dans l'exemple suivant (qui implique l'authentification Windows). La méthode qui suit l'attribut sera exécutée uniquement si l'utilisateur authentifié est membre du groupe Windows Responsable. Si l'appelant n'est pas membre de ce groupe, une exception SecurityException est générée.

[PrincipalPermission(SecurityAction.Demand, 
                     Role=@"NomDomaine\Responsable")]
public void SomeMethod()
{
}

L'exemple suivant présente une vérification de rôles explicite dans le code. Dans cet exemple, l'authentification Windows est utilisée. Si un mécanisme d'authentification autre que Windows est utilisé, le code est presque le même. Au lieu de convertir l'objet User en objet WindowsPrincipal, il faut le convertir en objet GenericPrincipal.

// Extraire l'utilisateur authentifié du contexte HTTP actuel.
// La variable User équivaut à HttpContext.Current.User 
// si vous utilisez une page .aspx ou .asmx.
WindowsPrincipal authenticatedUser = User as WindowsPrincipal;
if (null != authenticatedUser)
{
  // Remarque : pour extraire le nom de l'utilisateur authentifié, utilisez la 
  // ligne de code suivante.
  // string username = authenticatedUser.Identity.Name;

  // Effectuer une vérification de rôle.
  if (authenticatedUser.IsInRole(@"NomDomaine\Responsable") )
  {
    // L'utilisateur est autorisé à exécuter des fonctionnalités de responsable.
  }
}
else
{
  // L'utilisateur n'est pas autorisé à exécuter des fonctionnalités de responsable.
}

Informations supplémentaires

  • Pour obtenir une implémentation pratique du modèle d'authentification par formulaires ci-dessus, consultez la section « Authentification par formulaires » plus loin dans ce module.

Création d'une classe IPrincipal personnalisée

La classe GenericPrincipal fournie par .NET Framework doit être utilisée dans la plupart des cas lorsque vous recourez à un mécanisme d'authentification non Windows. Elle propose des vérifications de rôles à l'aide de la méthode IPrincipal.IsInRole.

Vous devrez parfois implémenter votre propre classe IPrincipal. Vous trouverez ci-dessous les raisons nécessitant l'implémentation de votre propre classe IPrincipal :

  • Vous souhaitez une fonctionnalité de vérification des rôles étendue. Vous souhaitez disposer de méthodes qui vous permettent de vérifier si un utilisateur particulier est membre de plusieurs rôles. Par exemple :

    CustomPrincipal.IsInAllRoles( "Rôle", "Rôle2", "Rôle3" )
CustomPrincipal.IsInAnyRole( "Rôle1", "Rôle2", "Rôle3" )

  • Vous souhaitez implémenter une méthode ou une propriété supplémentaire qui renvoie une liste de rôles dans un tableau. Par exemple :

    string[] roles = CustomPrincipal.Roles;

  • Vous souhaitez que votre application applique la logique de hiérarchie des rôles. Il semble normal qu'un directeur (Direction générale), par exemple, soit situé plus haut dans la hiérarchie qu'un responsable d'équipe (Responsable). Des méthodes telles que celles présentées ci-dessous permettent d'effectuer ce test.

    CustomPrincipal.IsInHigherRole("Responsable");
CustomPrincipal.IsInLowerRole("Responsable");

  • Vous souhaitez implémenter une initialisation différée des listes de rôles. Vous pouvez, par exemple, charger dynamiquement la liste de rôles uniquement lors d'une demande de vérification des rôles.

  • Vous souhaitez implémenter l'interface IIdentity pour que l'utilisateur soit authentifié par un certificat X509ClientCertificate. Par exemple :

    CustomIdentity id = CustomPrincipal.Identity;
X509ClientCertificate cert = id.ClientCertificate;

Informations supplémentaires

Pour plus d'informations sur la création d'une classe IPrincipal, consultez la section « Procédure : Implémenter IPrincipal » dans ce guide.

Authentification Windows

Utilisez l'authentification Windows lorsque les utilisateurs de votre application disposent de comptes Windows qui peuvent être authentifiés par le serveur (par exemple dans des scénarios d'applications intranet).

Si vous configurez ASP.NET pour l'authentification Windows, IIS effectue l'authentification de l'utilisateur à l'aide du mécanisme d'authentification IIS configuré. Ce scénario est présenté dans la figure 8.4.

L'authentification Windows ASP.NET utilise IIS pour authentifier les appelants

Figure 8.4
L'authentification Windows ASP.NET utilise IIS pour authentifier les appelants

Le jeton d'accès de l'appelant authentifié (qui peut être le compte d'utilisateur Internet anonyme si IIS est configuré pour l'authentification anonyme) est mis à la disposition de l'application ASP.NET. Prenez note des éléments suivants :

  • Le module ASP.NET FileAuthorizationModule est autorisé à effectuer des vérifications d'accès pour les fichiers ASP.NET demandés à l'aide du jeton d'accès de l'appelant initial.

    Important : l'autorisation de fichiers ASP.NET procède uniquement aux vérifications d'accès des types de fichiers qui sont mappés à Aspnet_isapi.dll.

  • L'autorisation de fichiers ne nécessite pas d'emprunt d'identité. Lorsque l'emprunt d'identité est activé, l'accès aux ressources effectué par votre application utilise l'identité empruntée de l'appelant. Dans ce cas, vérifiez que les listes de contrôle d'accès associées aux ressources contiennent une entrée de contrôle d'accès (ACE) qui accorde au minimum un accès en lecture à l'identité de l'appelant initial.

Identification de l'utilisateur authentifié

ASP.NET associe un objet WindowsPrincipal à la demande Web active. Il contient l'identité de l'utilisateur Windows authentifié ainsi que la liste des rôles auxquels l'utilisateur appartient. Dans le cadre de l'authentification Windows, la liste des rôles est composée d'un ensemble de groupes Windows auxquels l'utilisateur appartient.

Le code suivant indique comment obtenir l'identité de l'utilisateur Windows authentifié et comment effectuer un test simple des rôles pour l'autorisation.

WindowsPrincipal user = User as WindowsPrincipal;
if (null != user)
{
  string username = user.Identity.Name;
  // Effectuer une vérification de rôle.
  if ( user.IsInRole(@"NomDomaine\Responsable") )
  {
    // L'utilisateur est autorisé à exécuter des fonctionnalités de responsable.
  }
}
else
{
  // Génère une exception de sécurité car nous n'avons pas d'objet WindowsPrincipal.
}

Authentification par formulaires

Lorsque vous utilisez l'authentification par formulaires, la séquence d'événements déclenchée par un utilisateur non authentifié qui tente d'accéder à une ressource ou un fichier sécurisé (auquel cas l'autorisation des URL refuse l'accès à l'utilisateur) est présentée dans la figure 8.5.

Séquence d'événements de l'authentification par formulaires

Figure 8.5
Séquence d'événements de l'authentification par formulaires

La séquence d'événements illustrée dans la figure 8.5 est récapitulée ci-après :

  1. L'utilisateur soumet une demande Web pour Default.aspx.

    IIS autorise la demande car l'accès anonyme est activé. ASP.NET vérifie les éléments <authorization> et détecte un élément <deny users=?" />.

  2. L'utilisateur est redirigé vers la page de connexion (Login.aspx) conformément à la spécification de l'attribut loginUrl de l'élément <forms>.

  3. L'utilisateur fournit les informations d'identification et soumet le formulaire de connexion.

  4. Les informations d'identification sont validées dans un magasin (SQL Server ou Active Directory) et les rôles peuvent éventuellement être extraits. Vous devez récupérer une liste des rôles si vous souhaitez utiliser l'autorisation par rôle.

  5. Un cookie est créé avec un FormsAuthenticationTicket et est renvoyé au client. Les rôles peuvent éventuellement être stockés dans le ticket. Si vous stockez la liste des rôles dans le ticket, vous n'avez plus besoin d'accéder à la base de données pour récupérer de nouveau la liste pour toutes les demandes Web suivantes émanant du même utilisateur.

  6. L'utilisateur est redirigé à l'aide de la redirection côté client vers la page initialement demandée (Default.aspx).

  7. Dans le gestionnaire d'événements Application_AuthenticateRequest (dans Global.asax), le ticket est utilisé pour créer un objet IPrincipal et est stocké dans HttpContext.User.

    ASP.NET vérifie les éléments <authorization> et détecte un élément <deny users=?" />. Cependant, cette fois, l'utilisateur est authentifié.

    ASP.NET vérifie les éléments <authorization> pour s'assurer que l'utilisateur se trouve dans l'élément <allow>.

    L'utilisateur est autorisé à accéder à Default.aspx.

Étapes de développement de l'authentification par formulaires

Les étapes clés que vous devez réaliser pour implémenter l'authentification par formulaires sont présentées dans la liste suivante :

  1. Configurez IIS pour l'accès anonyme.

  2. Configurez ASP.NET pour l'authentification par formulaires.

  3. Créez un formulaire de connexion Web et validez les informations d'identification fournies.

  4. Récupérez la liste des rôles auprès du magasin de données personnalisé.

  5. Créez un ticket d'authentification par formulaires (stockez les rôles dans le ticket).

  6. Créez un objet IPrincipal.

  7. Placez l'objet IPrincipal dans le contexte HTTP actuel.

  8. Autorisez l'utilisateur en fonction du nom de l'utilisateur ou des rôles auxquels il appartient.

Configuration de IIS pour l'accès anonyme

Le répertoire virtuel de votre application doit être configuré pour l'accès anonyme dans IIS.

  • Pour configurer IIS pour l'accès anonyme

    1. Démarrez l'outil d'administration Internet Information Services (IIS).

    2. Sélectionnez le répertoire virtuel de votre application, cliquez avec le bouton droit, puis cliquez sur Propriétés.

    3. Cliquez sur Sécurité de répertoire.

    4. Dans le groupe Connexions anonymes et contrôle d'authentification, cliquez sur Modifier.

    5. Sélectionnez Accès anonyme.

Configuration de ASP.NET pour l'authentification par formulaires

Un exemple de configuration est présenté ci-après.

<authentication mode="Forms">
  <forms name="MyAppFormsAuth" 
       loginUrl="login.aspx" 
       protection="Encryption"
       timeout="20" 
       path="/" >
  </forms>
</authentication>
Création d'un formulaire de connexion Web et validation des informations d'identification fournies

Validez les informations d'identification dans une base de données SQL Server ou dans Active Directory.

Informations supplémentaires

  • Voir « Procédure : Utiliser l'authentification par formulaires avec SQL Server 2000 » dans ce guide.

  • Voir « Procédure : Utiliser l'authentification par formulaires avec Active Directory » dans ce guide.

Extraction de la liste des rôles du magasin de données personnalisé

Obtenez les rôles à partir d'une table d'une base de données SQL Server ou des groupes/listes de distribution configurés dans Active Directory. Pour plus d'informations, reportez-vous aux explications précédentes.

Création d'un ticket d'authentification par formulaires

Stockez les rôles extraits dans le ticket. Cette procédure est illustrée dans le code suivant.

// Ce gestionnaire d'événements est exécuté lorsque l'utilisateur clique sur le bouton Connexion
// après avoir fourni des informations d'identification.
private void Logon_Click(object sender, System.EventArgs e)
{
  // Valider les informations d'identification auprès d'une base de données SQL
  // ou de Active Directory
  bool isAuthenticated = IsAuthenticated( txtUserName.Text, 
                                          txtPassword.Text );
  if (isAuthenticated == true )
  {
    // Extraire le jeu de rôles de cet utilisateur à partir de la base de données SQL Server
    // ou de Active Directory. Les rôles sont renvoyés sous forme de
    // chaîne contenant des noms de rôles séparés par des canaux.
    // Exemples : "Responsable|Employé|Ventes|"
    // Cela facilite leur stockage dans le ticket d'authentification.

    string roles = RetrieveRoles( txtUserName.Text, txtPassword.Text );

    // Créer le ticket d'authentification et stocker les rôles dans la
    // propriété personnalisée UserData du ticket d'authentification.
    FormsAuthenticationTicket authTicket = new 
       FormsAuthenticationTicket(
                    1,                          // version
                    txtUserName.Text,           // nom d'utilisateur
                    DateTime.Now,               // création
                    DateTime.Now.AddMinutes(20),// Expiration
                    false,                      // Persistant
                    roles );                    // Données utilisateur
     // Crypter le ticket.
     string encryptedTicket = FormsAuthentication.Encrypt(authTicket);
     // Créer un cookie et ajouter le ticket crypté au 
     // cookie sous forme de données.
     HttpCookie authCookie = 
               new HttpCookie(FormsAuthentication.FormsCookieName,
                              encryptedTicket);

     // Ajouter le cookie à l'ensemble de cookies sortants. 
     Response.Cookies.Add(authCookie); 
     // Rediriger l'utilisateur vers la page demandée à l'origine.
     Response.Redirect( FormsAuthentication.GetRedirectUrl(
                        txtUserName.Text, 
                        false ));
  }
}
Création d'un objet IPrincipal

Créez l'objet IPrincipal dans le gestionnaire d'événements Application_AuthenticationRequest dans Global.asax. Utilisez la classe GenericPrincipal, sauf si vous avez besoin de fonctionnalités de rôle étendues. Dans ce cas, créez une classe personnalisée qui implémente IPrincipal.

Placement de l'objet IPrincipal dans le contexte HTTP actuel

La création d'un objet GenericPrincipal est présentée ci-après.

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
  // Extraire le cookie d'authentification par formulaires.
  string cookieName = FormsAuthentication.FormsCookieName;
  HttpCookie authCookie = Context.Request.Cookies[cookieName];
  if(null == authCookie)
  {
    // Il n'existe aucun cookie d'authentification.
    return;
  } 
  FormsAuthenticationTicket authTicket = null;
  try
  {
    authTicket = FormsAuthentication.Decrypt(authCookie.Value);
  }
  catch(Exception ex)
  {
    // Enregistrer dans le journal les informations d'exception (omis pour simplifier).
    return;
  }
  if (null == authTicket)
  {
    // Échec du décryptage du cookie.
    return; 
  }
  // Lorsque le ticket a été créé, la propriété UserData a été attribuée à
  // la chaîne de noms de rôles délimitée par des canaux.
  string[] roles = authTicket.UserData.Split(new char[]{'|'});

  // Créer un objet Identity.
  FormsIdentity id = new FormsIdentity( authTicket ); 
  // Cet objet Principal sera transmis dans l'ensemble de la demande.
  GenericPrincipal principal = new GenericPrincipal(id, roles);
  // Associer le nouvel objet Principal à l'objet HttpContext actuel.
  Context.User = principal;
}
Autorisation de l'utilisateur en fonction du nom de l'utilisateur ou des rôles auxquels il appartient

Utilisez des demandes PrincipalPermission déclaratives pour limiter l'accès aux méthodes. Utilisez des demandes PrincipalPermission impératives et/ou des vérifications de rôles explicites (IPrincipal.IsInRole) pour procéder à une authentification précise dans les méthodes.

Instructions concernant l'implémentation de l'authentification par formulaires

  • Utilisez SSL lorsque vous enregistrez les informations d'identification à l'aide d'un formulaire HTML.
    Vous devez utiliser SSL non seulement pour la page de connexion, mais également pour les autres pages, chaque fois que les informations d'identification ou le cookie d'authentification sont envoyés sur le réseau. Ainsi, les risques associés aux attaques de relecture du cookie sont limités.

  • Authentifiez les utilisateurs auprès d'un magasin de données personnalisé. Utilisez SQL Server ou Active Directory.

  • Récupérez une liste des rôles à partir du magasin de données personnalisé et stockez une liste des rôles délimitée dans la propriété UserData de la classe FormsAuthenticationTicket. Cette opération permet d'optimiser les performances, car elle élimine les accès répétés au magasin de données pour chaque demande Web. En outre, vous ne n'êtes plus obligé de stocker les informations d'identification de l'utilisateur dans le cookie d'authentification.

  • Si la liste des rôles est importante et susceptible d'excéder la taille limite de cookie, stockez les informations concernant les rôles dans la base de données ou l'objet cache ASP.NET et récupérez-les pour chaque demande ultérieure.

  • Pour chaque demande après l'authentification initiale :

    • Récupérez les rôles du ticket dans le gestionnaire d'événements Application_AuthenticateRequest.

    • Créez un objet IPrincipal et stockez-le dans le contexte HTTP (HttpContext.User). .NET Framework l'associe également au thread .NET actif (Thread.CurrentPrincipal).

    • Utilisez la classe GenericPrincipal , sauf si vous devez créer une implémentation IPrincipal personnalisée, par exemple pour prendre en charge des opérations complexes sur les rôles.

  • Utilisez deux cookies, l'un pour la personnalisation et l'autre pour l'autorisation et l'authentification sécurisées. Rendez le cookie de personnalisation persistant (vérifiez qu'il ne contient aucune information qui permettrait à une demande d'effectuer une opération dont l'accès est restreint, comme la soumission d'une commande dans la partie sécurisée d'un site).

  • Utilisez un nom de cookie (à l'aide de l'attribut Forms de l'élément <forms>) et un chemin distincts pour chaque application Web. Cette opération garantit que les utilisateurs authentifiés dans une application ne sont pas considérés comme authentifiés lors de l'utilisation d'une seconde application hébergée par le même serveur Web.

  • Vérifiez que les cookies sont activés dans les navigateurs clients. Pour obtenir une méthode d'authentification par formulaires qui ne nécessite pas de cookies, consultez la section « Authentification par formulaires sans cookie » plus loin dans ce module.

Informations supplémentaires

  • Voir « Procédure : Utiliser l'authentification par formulaires avec SQL Server 2000 » dans ce guide.

  • Voir « Procédure : Utiliser l'authentification par formulaires avec Active Directory » dans ce guide.

  • Voir « Procédure : Créer des objets GenericPincipal avec l'authentification par formulaires » dans ce guide.

Hébergement de plusieurs applications à l'aide de l'authentification par formulaires

Si vous hébergez plusieurs applications Web qui utilisent l'authentification par formulaires sur le même serveur Web, un utilisateur qui est authentifié dans une application peut soumettre une demande à une autre application sans être redirigé vers la page de connexion de cette application. Les règles d'autorisation des URL dans la seconde application peuvent refuser l'accès à l'utilisateur, sans offrir la possibilité d'indiquer les informations d'identification à l'aide du formulaire de connexion.

Ce cas de figure se présente uniquement si les attributs de nom et de chemin de l'élément <forms> sont identiques pour plusieurs applications et si chaque application utilise un élément <machineKey> commun dans le fichier Web.config.

Informations supplémentaires

Pour plus d'informations sur ce problème et pour connaître les techniques de résolution, consultez les articles suivants de la Base de connaissances Microsoft (articles en anglais) :

Authentification par formulaires sans cookie

Si vous devez utiliser une solution d'authentification par formulaires sans cookie, vous pouvez envisager de recourir à la méthode utilisée par Microsoft Mobile Internet Toolkit. L'authentification par formulaires mobile repose sur l'authentification par formulaires mais elle utilise la chaîne de demande pour transmettre le ticket d'authentification à la place d'un cookie.

Informations supplémentaires

Pour plus d'informations sur l'authentification par formulaires mobile, consultez l'article Q311568, « INFO: How To Use Mobile Forms Authentication with Microsoft Mobile Internet Toolkit » (en anglais) de la Base de connaissances Microsoft.

Authentification Passport

Utilisez l'authentification Passport lorsque les utilisateurs de votre application disposent de comptes Passport et que vous souhaitez implémenter une solution impliquant une seule connexion avec d'autres sites Passport activés.

Lorsque vous configurez ASP.NET pour l'authentification Passport, l'utilisateur est invité à se connecter, puis il est dirigé vers le site Passport. Une fois les informations d'identification validées, l'utilisateur est redirigé vers votre site.

Configuration de ASP.NET pour l'authentification Passport

Pour configurer ASP.NET pour l'authentification Passport, utilisez les paramètres Web.config suivants.

<authentication mode="Passport">
  <passport redirectUrl="internal" />
</authentication>
<authorization>
  <deny users="?" />
  <allow users="*" />
</authorization>

Mappage d'une identité Passport dans des rôles dans Global.asax

Pour mapper une identité Passport dans des rôles, implémentez le gestionnaire d'événements PassportAuthentication_OnAuthentication dans Global.asax, comme l'illustre le code suivant.

void PassportAuthentication_OnAuthenticate(Object sender, 
                                           PassportAuthenticationEventArgs e)
{
  if(e.Identity.Name == "0000000000000001")
  {
    string[] roles = new String[]{"Développeur", "Admin", "Testeur"};
    Context.User = new GenericPrincipal(e.Identity, roles);
  }
}

Test de l'appartenance aux rôles

Le fragment de code suivant indique la procédure d'extraction de l'identité Passport authentifiée et de vérification de l'appartenance aux rôles dans une page aspx.

PassportIdentity passportId = Context.User.Identity as PassportIdentity;
if (null == passportId)
{
  Response.Write("Il ne s'agit pas d'une identité PassportIdentity<br>");
  return;
}
Response.Write("IsInRole: développeur ? " + Context.User.IsInRole("Développeur"));

Authentification personnalisée

Si aucun des modules d'authentification proposés dans .NET Framework ne répond à vos besoins en matière d'authentification, vous pouvez faire appel à une authentification personnalisée et implémenter votre propre mécanisme d'authentification. Par exemple, il est possible que votre entreprise utilise déjà une stratégie d'authentification personnalisée qui est largement utilisée par d'autres applications.

Pour implémenter une authentification personnalisée dans ASP.NET :

  • Configurez le mode d'authentification dans le fichier Web.config comme l'indique le code suivant. ASP.NET est averti qu'aucun de ses modules d'authentification intégrés ne doit être appelé.

    <authentication mode="None" />

  • Créez une classe qui implémente l'interface System.Web.IHttpModule pour créer un module HTTP personnalisé. Ce module doit se connecter à l'événement HttpApplication.AuthenticateRequest et fournir un délégué qui doit être appelé pour chaque demande soumise à l'application lorsque l'authentification est nécessaire.

    Un module d'authentification doit effectuer les opérations suivantes :

    • Obtenir les informations d'identification auprès de l'appelant.

    • Valider les informations d'identification auprès d'un magasin.

    • Créer un objet IPrincipal et le stocker dans HttpContext.User.

    • Créer et protéger un jeton d'authentification et le renvoyer à l'utilisateur (généralement une chaîne de demande, un cookie ou un champ de formulaire masqué).

    • Obtenir le jeton d'authentification pour les demandes ultérieures, le valider et le soumettre de nouveau.

Informations supplémentaires

Pour plus d'informations sur la méthode d'implémentation d'un module HTTP personnalisé, consultez l'article Q307996, « COMMENT FAIRE : Créer un module ASP.NET HTTP avec Visual C# .NET » dans la Base de connaissances Microsoft.

Identité de processus pour ASP.NET

Exécutez ASP.NET (précisément le processus de travail Aspnet_wp.exe) en utilisant un compte doté de privilèges minimum.

Utilisez un compte doté de privilèges minimum

Utilisez un compte doté de privilèges minimum pour limiter les problèmes susceptibles de compromettre l'intégrité du processus. Si une personne résolue parvient à compromettre l'intégrité du processus ASP.NET qui exécute votre application Web, elle pourra facilement hériter des privilèges et des droits d'accès accordés au compte du processus et les exploiter. Un compte configuré avec des privilèges minimum limite les dommages susceptibles d'être causés.

Évitez d'exécuter ASP.NET avec le compte SYSTEM

N'utilisez pas le compte SYSTEM doté de privilèges élevés pour exécuter ASP.NET et n'accordez pas au compte du processus ASP.NET le privilège « Fonctionner en tant que partie intégrante du système ». Vous pouvez être tenté d'utiliser l'une des ces options pour que votre code puisse appeler l'API LogonUser afin d'obtenir une identité fixe (en principe pour l'accès aux ressources du réseau). Pour découvrir d'autres méthodes, consultez la section « Accès aux ressources réseau » plus loin dans ce module.

Les raisons pour lesquelles ASP.NET ne doit pas être exécuté en tant que SYSTEM et pour lesquelles le privilège « Fonctionner en tant que partie intégrante du système d'exploitation » ne doit pas être accordé sont les suivantes :

  • Les dommages que peut causer un utilisateur malveillant lorsque l'intégrité du système est compromise sont beaucoup plus importants, mais les possibilités d'attaques ne sont pas affectées.

  • Le principe du moindre privilège est remis en cause. Le compte ASPNET a été spécialement configuré comme compte doté de privilèges minimum conçu pour les applications Web ASP.NET.

Informations supplémentaires

Pour plus d'informations sur le privilège « Fonctionner en tant que partie intégrante du système d'exploitation », consultez la section Security Briefs (en anglais) du Microsoft Systems Journal (août 1999).

Contrôleurs de domaine et compte du processus ASP.NET

En général, il est déconseillé d'exécuter votre serveur Web sur un contrôleur de domaine, car si l'intégrité du serveur est compromise, celle du domaine l'est également. Si vous devez exécuter ASP.NET sur un contrôleur de domaine, accordez au compte du processus ASP.NET les privilèges appropriés, comme le souligne l'article Q315158, « CORRECTIF : ASP.NET ne fonctionne pas avec le compte ASPNET par défaut sur un contrôleur de domaine » dans la Base de connaissances Microsoft.

Utilisation du compte ASPNET par défaut

Le compte local ASPNET a été configuré précisément pour l'exécution des applications Web ASP.NET en utilisant les privilèges les plus faibles possible. Utilisez ASPNET chaque fois que cela est possible.

Les applications Web ASP.NET s'exécutent par défaut avec ce compte, configuré par l'élément <processModel> du fichier Machine.config. 

<processModel userName="machine" password="AutoGenerate" />

Remarque : le nom d'utilisateur machine fait référence au compte ASPNET. Le compte est créé avec un mot de passe sécurisé cryptographique lorsque vous installez .NET Framework. Le mot de passe est configuré dans la base de données du Gestionnaire de comptes de sécurité (SAM) mais il est également stocké dans le LSA (Local System Authority) sur l'ordinateur local. Le système extrait le mot de passe du LSA lorsqu'il lance le processus de travail ASP.NET.

Si votre application accède aux ressources réseau, le compte ASPNET doit être capable d'être authentifié par l'ordinateur distant. Vous avez deux possibilités :

  • Associez le mot de passe du compte ASPNET à une valeur connue puis créez un compte en double (avec le même nom d'utilisateur et le même mot de passe) sur l'ordinateur distant. Cette méthode est la seule option dans les cas suivants :

    • Le serveur Web et l'ordinateur distant sont dans des domaines séparés pour lesquels il n'existe aucune relation d'approbation.

    • Le serveur Web et l'ordinateur distant sont séparés par un pare-feu et vous ne souhaitez pas ouvrir les ports nécessaires pour prendre en charge l'authentification Windows.

  • Si vous recherchez avant tout une administration facile, utilisez un compte de domaine doté de privilèges minimum.
    Pour éviter de mettre à jour et de synchroniser manuellement les mots de passe, vous pouvez utiliser un compte de domaine doté de privilèges minimum pour exécuter ASP.NET. Il est essentiel que le compte de domaine soit complètement verrouillé pour limiter les risques si l'intégrité du processus venait à être compromise. Si une personne malveillante parvient à compromettre le processus de travail ASP.NET, elle sera en mesure d'accéder aux ressources du domaine, sauf si le compte est complètement verrouillé.

Remarque : si vous utilisez un compte local et si le compte est ensuite compromis, les seuls ordinateurs susceptibles d'être attaqués sont ceux sur lesquels vous avez créé des comptes en double. Si vous utilisez un compte de domaine, la visibilité du compte est accordée à chaque ordinateur du domaine. Le compte doit toutefois disposer d'autorisations lui permettant d'accéder à ces ordinateurs.

Élément <processModel>

L'élément <processModel> du fichier Machine.config est associé aux attributs userName et password qui indiquent le compte à utiliser pour exécuter le processus de travail ASP.NET (Aspnet_wp.exe).

Remarque : contrairement au mode d'exécution des applications ASP classiques, le code ASP.NET n'est jamais exécuté dans le processus dllhost.exe ou en tant que compte IWAM_MACHINENAME, même lorsque le niveau de protection des applications est associé à la valeur Élevée (Isolé) dans IIS.

Les demandes ASP.NET envoyées à IIS sont directement routées vers le processus de travail ASP.NET (Aspnet_wp.exe). L'extension ASP.NET ISAPI, Aspnet_isapi.dll, est exécutée dans l'espace d'adressage de processus IIS (Inetinfo.exe). Cette exécution est contrôlée par l'entrée de la métabase InProcessIsapiApps , laquelle ne doit pas être modifiée. L'extension ISAPI est chargée du routage des demandes vers le processus de travail ASP.NET. Les applications ASP.NET exécutent ensuite le processus de travail ASP.NET. Les domaines d'application fournissent des limites d'isolation.

Dans IIS 6, vous serez en mesure d'isoler les applications ASP.NET en configurant des regroupements d'applications, et chaque regroupement disposera de sa propre instance d'application.

Vous disposez de plusieurs options de configuration de l'attribut <processModel> userName. Par exemple :

  • "machine". Le processus de travail est exécuté en tant que compte ASPNET par défaut doté de privilèges minimum. Le compte dispose d'un accès réseau mais ne peut être authentifié pour aucun autre ordinateur sur le réseau, car le compte est local sur l'ordinateur et il n'existe aucune autorité qui se porte garante du compte. Sur le réseau, ce compte est représenté sous la forme « NomOrdinateur\ASPNET ».

  • "system". Le processus de travail est exécuté en tant que compte SYSTEM local. Ce compte bénéficie de privilèges étendus sur l'ordinateur local et il est également en mesure d'accéder au réseau à l'aide des informations d'identification de l'ordinateur. Sur le réseau, ce compte est représenté sous la forme « NomDomaine\NomOrdinateur$ ».

  • Informations d'identification spécifiques. Lorsque vous fournissez des informations d'identification pour userName et pour password, gardez en mémoire le principe du moindre privilège. Si vous spécifiez un compte local, l'application Web ne peut pas être authentifiée sur le réseau, sauf si vous créez un compte en double sur l'ordinateur distant. Si vous choisissez d'utiliser un compte de domaine doté de privilèges minimum, assurez-vous qu'il ne s'agit pas d'un compte qui est autorisé à accéder à plus d'ordinateurs qu'il n'est nécessaire sur le réseau.

Stockage d'informations d'identification <processModel> cryptées

Si vous utilisez des informations d'identification personnalisées, exécutez l'utilitaire aspnet_setreg.exe pour les stocker sous forme cryptée dans le Registre. Évitez de stocker des informations d'identification en texte brut dans le fichier Machine.config.

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.

L'exemple suivant illustre le format des attributs userName et password avant et après l'emploi de cet utilitaire. Notez que les valeurs d'attribut pointent vers la clé de Registre sécurisée et les valeurs nommées qui contiennent les informations d'identification cryptées.

<!-- Avant -->
<processModel userName="UnComptePersonnalisé"
              password="MotDePasseTexteBrut" . . ./>

<!-- Après -->
<processModel
        userName="registry:HKLM\SOFTWARE\YourSecureApp\processModel\
                  ASPNET_SETREG,userName"
        password="registry:HKLM\SOFTWARE\YourSecureApp\processModel\
                  ASPNET_SETREG,password" . . ./>

Informations supplémentaires

  • Pour plus d'informations sur l'accès aux ressources du réseau à partir d'applications Web ASP.NET, consultez la section « Accès aux ressources réseau » plus loin dans ce module.

  • Pour obtenir des informations détaillées sur la création d'un compte personnalisé pour l'exécution de ASP.NET, consultez la section « Procédure : Créer un compte personnalisé pour exécuter ASP.NET » dans ce guide.

Emprunt d'identité

Avec l'introduction de FileAuthorizationModule et l'utilisation efficace des opérateurs de contrôle d'appels et des limites de confiance, l'emprunt d'identité risque de présenter plus d'inconvénients que d'avantages dans ASP.NET.

Emprunt d'identité et ressources locales

Si vous utilisez l'emprunt d'identité et accédez aux ressources locales à partir du code de votre application Web, vous devez configurer les listes de contrôle d'accès associées à chaque ressource sécurisée pour qu'elles contiennent une entrée de contrôle d'accès qui accorde au minimum un accès en lecture à l'utilisateur authentifié.

Une méthode plus appropriée consiste à éviter l'emprunt d'identité, à accorder des autorisations au compte du processus ASP.NET et à utiliser l'autorisation des URL, l'autorisation de fichiers ainsi que des vérifications de rôles impératives et déclaratives.

Emprunt d'identité et ressources distantes

Si vous utilisez l'emprunt d'identité, puis accédez à des ressources distantes à partir du code de votre application Web, l'accès échouera, sauf si vous utilisez l'authentification de base, l'authentification par formulaires ou l'authentification Kerberos. Si vous utilisez l'authentification Kerberos, les comptes d'utilisateurs doivent être configurés correctement pour la délégation. Ils doivent être signalés comme « sensibles et ne pouvant pas être délégués » dans Active Directory.

Informations supplémentaires

Pour plus d'informations sur la configuration de la délégation Kerberos, consultez les sections suivantes :

  • « Transmission de l'appelant initial à la base de données » dans le Module 5, « Sécurité intranet ».

  • « Procédure : Implémenter une délégation Kerberos pour Windows 2000 » dans ce guide.

Emprunt d'identité et threads

Si un thread qui utilise l'emprunt d'identité crée un autre thread, ce dernier hérite du contexte de sécurité du compte du processus ASP.NET et non du compte dont l'identité a été empruntée.

Accès aux ressources système

Par défaut, ASP.NET ne fait pas appel à l'emprunt d'identité. Par conséquent, si votre application Web accède aux ressources système locales, elle utilise pour cela le contexte de sécurité associé au processus de travail Aspnet_wp.exe. Le contexte de sécurité est déterminé par le compte utilisé pour l'exécution du processus de travail.

Accès au journal d'événements

Les autorisations dont disposent les comptes dotés de privilèges minimum sont suffisantes pour leur permettre d'écrire des enregistrements dans le journal d'événements à l'aide des sources d'événements existantes. Cependant, ces privilèges ne sont pas suffisants pour leur permettre de créer des sources d'événements. Pour cela, une nouvelle entrée doit être placée sous la ruche de Registre suivante.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\<log>

Pour éviter ce problème, créez les sources d'événements utilisées par votre application lors de l'installation, lorsque les privilèges d'administrateur sont disponibles. L'une des méthodes conseillées consiste à utiliser une classe Installer .NET qui peut être instanciée par le programme d'installation Windows Installer (si vous utilisez le déploiement .msi) ou par l'utilitaire système InstallUtil.exe (dans le cas contraire).

Si vous n'êtes pas en mesure de créer des sources d'événements lors de l'installation, vous devez ajouter une autorisation à la clé de Registre suivante et accorder un accès au compte du processus ASP.NET (ou à tout compte dont l'identité a été empruntée si votre application utilise l'emprunt d'identité).

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog

Le compte doit bénéficier des autorisations minimales suivantes :

  • Requête valeur de clé

  • Affectation valeur de clé

  • Créer une sous-clé

  • Énumérer les sous-clés

  • Notifier

  • Lecture

Le code suivant peut être utilisé pour écrire dans le journal des événements d'applications à partir de ASP.NET une fois que les autorisations ont été appliquées au Registre :

string source = "Votre application source";
string logToWriteTo = "Application";
string eventText = "Exemple d'événement";

if (!EventLog.SourceExists(source))
{
  EventLog.CreateEventSource(source, logToWriteTo);
}
EventLog.WriteEntry(source, eventText, EventLogEntryType.Warning, 234);

Accès au Registre

Toute clé du Registre à laquelle votre application accède requiert une entrée de contrôle d'accès dans la liste de contrôle d'accès, qui accorde (au minimum) un accès en lecture au compte du processus ASP.NET.

Informations supplémentaires

Pour plus d'informations sur les classes Installer et l'utilitaire InstallUtil.exe, consultez la section « .NET Framework Tools » (en anglais) du Kit de développement logiciel .NET Framework sur MSDN.

Accès aux objets COM

Dans ASP, les demandes sont traitées à l'aide de threads du pool de threads STA (Single Threaded Apartment). Dans ASP.NET, les demandes sont traitées à l'aide de threads du pool de threads MTA (Multithreaded Apartment, cloison multithread). Ces différences de traitement ont une incidence sur les applications Web ASP.NET qui appellent des objets du modèle de threads cloisonnés (Apartment).

Objets du modèle de threads cloisonnés (Apartment)

Lorsqu'une application Web ASP.NET appelle un objet du modèle de threads cloisonnés (Apartment), tel qu'un objet COM Visual Basic 6, vous devez observer deux règles :

  • Vous devez marquer votre page ASP.NET avec la directive AspCompat, comme l'indique le code suivant.

    <%@ Page Language="C#" AspCompat="True" %>

  • Ne créez pas vos objets COM en dehors de gestionnaires d'événements Page spécifiques. Créez les objets COM dans des gestionnaires d'événements Page tels que Page_Load et Page_Init). Ne créez pas d'objets COM dans le constructeur de la page.

Nécessité de la directive AspCompat

Par défaut, ASP.NET utilise les threads MTA pour traiter les demandes. Une commutation de threads intervient lorsqu'un objet du modèle de threads cloisonnés (Apartment) est appelé à partir de ASP.NET, car ce type d'objet n'est pas directement accessible par les threads MTA (COM utiliserait un thread STA).

Lorsque vous indiquez la directive AspCompat, la page est traitée par un thread STA. Ceci évite une commutation de threads de MTA à STA. Ceci est important du point de vue de la sécurité si votre application Web fait appel à l'emprunt d'identité, car une commutation de threads entraîne la perte du jeton d'emprunt d'identité. Le jeton d'emprunt d'identité n'est ainsi pas associé au nouveau thread.

La directive AspCompat n'est pas prise en charge par les services Web ASP.NET. Ainsi, lorsque vous appelez des objets du modèle de threads cloisonnés (Apartment) à partir du code du service Web, une commutation de threads intervient et vous perdez le jeton d'emprunt d'identité. Cette opération débouche généralement sur une exception Accès refusé.

Informations supplémentaires

Ne créez pas d'objets COM en dehors d'événements Page spécifiques

Ne créez pas d'objets COM en dehors de gestionnaires d'événements Page spécifiques. Le fragment de code suivant illustre les opérations à ne pas effectuer.

<%@ Page Language="C#" AspCompat="True" %>
<script runat="server">
  // Objet COM créé à l'extérieur des événements Page
  YourComObject obj = new apartmentObject();
  public void Page_Load()
  {
    obj.Foo()
  }
</script>

Lorsque vous utilisez des objets du modèle de threads cloisonnés (Apartment), il est important de créer l'objet dans des événements Page spécifiques, tels que Page_Load, comme l'indique le code suivant.

<%@ Page Language="C#" AspCompat="True" %>
<script runat="server">
public void Page_Load()
{
  YourComObject obj  = new apartmentObject();
  obj.Foo()
}
</script>

Informations supplémentaires

Pour plus d'informations, consultez l'article Q308095, « PRB: Creating STA Components in the Constructor in ASP.NET ASPCOMPAT Mode Negatively Impacts Performance » (en anglais) de la Base de connaissances Microsoft.

Objets C# et VB .NET dans COM+

L'outil de développement Microsoft C#® et le système de développement Microsoft Visual Basic® .NET gèrent tous les modèles de threads (threads libres, neutres, Les deux et threads cloisonnés). Par défaut, lorsque des objets sont hébergés dans COM+, C# et Visual Basic .NET, ils sont signalés sous la forme Les deux. Par conséquent, lorsqu'ils sont appelés par ASP.NET, l'accès est direct et vous ne risquez aucune commutation de threads.

Accès aux ressources réseau

Il est possible que votre application ait besoin d'accéder aux ressources réseau. Il est important que vous puissiez identifier les éléments suivants :

  • Ressources auxquelles votre application doit accéder.

    Il peut s'agir, par exemple, de fichiers sur des partages de fichiers, des bases de données, des serveurs DCOM ou des objets Active Directory.

  • L'identité utilisée pour l'accès aux ressources.

    Si votre application accède à des ressources distantes, cette identité doit pouvoir être authentifiée par l'ordinateur distant.

Remarque : pour obtenir des informations détaillées sur l'accès aux bases de données SQL Server distantes, consultez le Module 12, « Sécurité de l'accès aux données ».

Vous pouvez accéder à des ressources distantes à partir d'une application ASP.NET en utilisant l'une des techniques suivantes :

  • Utilisez l'identité du processus ASP.NET.

  • Utilisez un composant desservi.

  • Utilisez le compte d'utilisateur Internet anonyme (par exemple IUSR_MACHINE).

  • Utilisez l'API LogonUser et empruntez une identité Windows spécifique.

  • Utilisez l'appelant initial.

Utilisez l'identité de processus ASP.NET

Lorsque l'application n'est pas configurée pour l'emprunt d'identité, l'identité du processus ASP.NET fournit l'identité par défaut lorsque votre application tente d'accéder à des ressources distantes. Si vous souhaitez utiliser le compte du processus ASP.NET pour l'accès aux ressources distantes, trois options se présentent à vous :

  • Utilisez des comptes en miroir.
    Cette méthode est la plus simple. Elle implique la création d'un compte local disposant d'un nom d'utilisateur et d'un mot de passe correspondants sur l'ordinateur distant. Vous devez remplacer le mot de passe du compte ASPNET dans le Gestionnaire des utilisateurs par une valeur connue (utilisez un mot de passe sécurisé). Ensuite, vous devez associer cette valeur explicitement à l'élément <processModel> dans le fichier Machine.config et remplacer la valeur « AutoGenerate » existante. Évitez d'utiliser des informations d'identification en texte brut. Faites appel à l'utilitaire aspnet_setreg.exe pour stocker des informations d'identification cryptées dans le Registre, comme cela est expliqué plus haut.

    Important : si vous remplacez le mot de passe ASPNET par une valeur connue, le mot de passe dans le LSA ne correspondra plus au mot de passe du compte SAM. Si vous devez rétablir la valeur « AutoGenerate » par défaut, effectuez l'une des opérations suivantes :

    Exécuter Aspnet_regiis.exe pour rétablir la configuration par défaut de ASP.NET. Pour plus d'informations, consultez l'article Q306005, « COMMENT FAIRE : Réparer un mappage IIS après avoir supprimé et réinstallé IIS » dans la Base de connaissances Microsoft.

  • Créer un compte local personnalisé et doté de privilèges minimum pour exécuter ASP.NET et créer un compte en double sur l'ordinateur distant.

  • Exécuter ASP.NET en utilisant un compte de domaine doté de privilèges minimum.

    Cela suppose que les ordinateurs serveur et les ordinateurs clients figurent dans le même domaine ou dans des domaines autorisés à approuver.

Informations supplémentaires

Pour plus d'informations sur la configuration d'un compte de processus ASP.NET, consultez la section « Procédure : Créer un compte personnalisé pour exécuter ASP.NET » dans ce guide.

Utilisation d'un composant desservi

Vous pouvez utiliser un composant desservi out-of-process, configuré pour son exécution en tant qu'identité fixe afin d'accéder aux ressources réseau. La figure 8.6 ci-dessous illustre cette méthode.

Utilisation d'un composant desservi out-of-process afin de fournir une identité fixe pour l'accès aux ressources réseau

Figure 8.6
Utilisation d'un composant desservi out-of-process afin de fournir une identité fixe pour l'accès aux ressources réseau

L'utilisation d'un composant desservi out-of-process (dans une application serveur Microsoft Enterprise Services) présente les avantages suivants :

  • Flexibilité en ce qui concerne l'identité utilisée. Vous ne vous reposez pas uniquement sur l'identité ASP.NET.

  • Le code approuvé ou doté de privilèges élevés peut être isolé de votre application Web principale.

  • Du point de vue de la sécurité, l'apport d'un processus supplémentaire accroît le degré de sécurité. Il est donc beaucoup plus difficile pour une personne malveillante de franchir la limite du processus et d'accéder à un processus doté de privilèges plus élevés.

  • Si vous devez configurer manuellement l'emprunt d'identité avec des appels d'API LogonUser, vous pouvez le faire dans un processus qui est indépendant de votre application Web principale.

    Remarque : pour appeler l'API LogonUser, vous devez accorder au processus Microsoft Enterprise Services le privilège « Fonctionner en tant que partie intégrante du système d'exploitation ». L'augmentation des privilèges d'un processus qui est distinct de votre application Web n'est pas un souci majeur en termes de sécurité.

Utilisation du compte d'utilisateur Internet anonyme

Vous pouvez utiliser le compte d'utilisateur Internet anonyme pour accéder aux ressources réseau si IIS est configuré pour l'authentification anonyme. C'est le cas si l'une des conditions suivantes est vérifiée :

  • Votre application gère l'accès anonyme.

  • Votre application utilise l'authentification par formulaires, l'authentification Passport ou l'authentification personnalisée (lorsque IIS est configuré pour l'accès anonyme).

  • Pour utiliser le compte anonyme pour l'accès aux ressources distantes

    1. Configurez IIS pour l'authentification anonyme. Vous pouvez définir pour ASP.NET le mode d'authentification Windows, par formulaires, Passport ou Aucune, en fonction des besoins de votre application en matière d'authentification.

    2. Configurez ASP.NET pour l'emprunt d'identité. Utilisez le paramètre suivant dans le fichier Web.config :

      <identity impersonate="true" />

    3. Configurez le compte anonyme en tant que compte de domaine doté de privilèges minimum,

      - ou -

      Dupliquez le compte anonyme en utilisant le même nom d'utilisateur et le même mot de passe sur l'ordinateur distant. Cette méthode est indispensable lorsque vous effectuez des appels sur plusieurs domaines non autorisés à approuver ou au travers de pare-feu lorsque les ports nécessaires pour gérer l'authentification intégrée de Windows ne sont pas ouverts.

      Pour permettre la prise en charge d'une telle méthode, vous devez effectuer les opérations suivantes :

      1. Utilisez le Gestionnaire de services Internet pour désactiver la case à cocher Autoriser la vérification de mot de passe par IIS pour le compte anonyme.

        Si vous sélectionnez cette option, la session de connexion créée à l'aide du compte anonyme spécifié aboutit à des informations d'identification réseau NULL (et par conséquent, ne peut pas être utilisée pour accéder aux ressources réseau). Si vous désactivez cette option, la session de connexion est une session de connexion interactive utilisant des informations d'identification réseau.

      2. Définissez les informations d'identification du compte dans le Gestionnaire des utilisateurs ainsi que dans le Gestionnaire de services Internet.

Important : si vous empruntez l'identité du compte anonyme (par exemple IUSR_MACHINE), les ressources doivent être sécurisées par rapport à ce compte à l'aide de listes de contrôle d'accès configurées correctement. Les ressources auxquelles votre application doit accéder doivent accorder un accès en lecture (au minimum) au compte anonyme. Toutes les autres ressources doivent refuser l'accès au compte anonyme.

Hébergement de plusieurs applications Web

Vous pouvez utiliser un compte d'utilisateur Internet anonyme séparé pour chaque racine virtuelle dans votre site Web. Dans un environnement hébergé, ceci vous permet d'autoriser, de suivre et d'auditer séparément les demandes émanant d'applications Web séparées. La figure 8.7 ci-dessous illustre cette méthode.

Emprunt d'identité de comptes d'utilisateurs Internet anonymes séparés par application (répertoire virtuel)

Figure 8.7
Emprunt d'identité de comptes d'utilisateurs Internet anonymes séparés par application (répertoire virtuel)

  • Pour configurer le compte d'utilisateur Internet anonyme pour un répertoire virtuel spécifique

    1. Démarrez le Gestionnaire de services Internet à partir du groupe de programmes Outils d'administration.

    2. Sélectionnez le répertoire virtuel de votre application, cliquez avec le bouton droit, puis cliquez sur Propriétés.

    3. Cliquez sur l'onglet Sécurité de répertoire.

    4. Cliquez sur Modifier dans le groupe Connexions anonymes et contrôle d'authentification.

    5. Sélectionnez Accès anonyme, puis cliquez sur Modifier.

    6. Entrez le nom d'utilisateur et le mot de passe du compte que IIS doit utiliser lorsque des utilisateurs anonymes se connectent au site.

    7. Assurez-vous que la case à cocher Autoriser la vérification de mot de passe par IIS n'est PAS activée.

Utilisation de LogonUser et emprunt d'une identité Windows spécifique

Vous pouvez emprunter une identité en configurant les attributs de nom d'utilisateur et de mot de passe dans l'élément <identity> du fichier Web.config ou en appelant l'API Win32® LogonUser dans le code de votre application.

Important : comme nous l'avons mentionné plus haut dans ce module, l'utilisation de LogonUser ou d'une entité empruntée fixe n'est pas recommandée avec .NET Framework 1.0 sur des serveurs Windows 2000, car vous êtes obligé d'accorder au compte du processus ASP.NET le puissant privilège « Fonctionner en tant que partie intégrante du système d'exploitation ».

Microsoft Windows .NET Server 2003 n'est pas concerné par cette limitation. La version 1.1 de .NET Framework apporte en outre des améliorations à ce scénario sur Windows 2000. Le processus IIS se charge notamment de la connexion afin que ASP.NET ne nécessite pas le privilège « Fonctionner en tant que partie intégrante du système d'exploitation ».

Utilisation de l'appelant initial

Pour utiliser l'identité de l'appelant initial pour l'accès aux ressources distantes, vous devez être en mesure de déléguer le contexte de sécurité de l'appelant du serveur Web à l'ordinateur distant.

Avertissement d'évolutivité : si vous accédez au niveau des services de données de votre application à l'aide de l'identité empruntée de l'appelant initial, vous risquez de limiter sérieusement les possibilités d'évolutivité de l'application, car le regroupement de connexions à la base de données devient inefficace. Le contexte de sécurité des connexions à la base de données est différent pour chaque utilisateur.

Les modes d'authentification suivants gèrent la délégation :

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

  • Certificats clients mappés à des comptes Windows. Le mappage doit être effectué par IIS.

  • Authentification de base. L'authentification de base gère l'accès aux ressources distantes, car les informations d'identification de l'appelant initial sont disponibles en texte brut au niveau du serveur Web. Elles peuvent être utilisées pour répondre aux demandes d'authentification en provenance d'ordinateurs distants.
    L'authentification de base doit être utilisée en conjonction avec une session de connexion par fichier de commandes ou interactive. Le type de session de connexion généré par l'authentification de base est configurable dans la métabase IIS. Pour plus d'informations, consultez le Kit de développement de plate-forme : Internet Information Services 5.1 sur MSDN.

    Important : l'authentification de base est la méthode gérant la délégation la moins sécurisée. En effet, un nom d'utilisateur et un mot de passe sont transmis du navigateur au serveur sur le réseau, et ils sont mis en mémoire cache sur le serveur Web. Vous pouvez utiliser SSL pour protéger les informations d'identification lors de leur transit, mais vous devez éviter la mise en cache des informations d'identification en texte brut sur le serveur Web chaque fois que cela est possible.

  • Pour utiliser l'appelant initial pour l'accès aux ressources distantes

    1. Configurez IIS pour l'authentification intégrée de Windows (Kerberos), l'authentification par certificats (avec le mappage de certificats IIS) ou l'authentification de base.

    2. Configurez ASP.NET pour l'emprunt d'identité et l'authentification Windows.

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

    3. Si vous utilisez la délégation Kerberos, configurez les comptes Active Directory pour la délégation.

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.

  • Pour plus d'informations sur l'emprunt d'identité ASP.NET, consultez l'article .NET Framework Developers Guide (en anglais) sur MSDN.

Accès aux fichiers sur un partage de fichiers UNC

Si votre application doit accéder à des fichiers sur un partage de fichiers UNC (Universal Naming Convention) à l'aide de ASP.NET, il est important d'ajouter des autorisations NTFS au dossier du partage. Vous devez également définir les autorisations du partage pour accorder au minimum un accès en lecture au compte du processus ASP.NET ou à l'identité empruntée (si votre application est configurée pour l'emprunt d'identité).

Accès aux ressources réseau non Windows

Si votre application doit accéder à des ressources non Windows, telles que des bases de données situées sur des plates-formes autres que Windows ou sur des applications de grands systèmes, vous devez considérer les points suivants :

  • Quels sont les opérateurs de contrôle d'appels et les limites de confiance associés à la ressource ?

  • Quelles sont les informations d'identification requises pour l'authentification ?

  • La ressource doit-elle connaître l'identité de l'appelant initial ou approuve-t-elle l'application appelante (à l'aide d'une identité de service ou de processus fixe) ?

  • Quel est le coût en termes de performances associé à l'établissement des connexions ? Si le coût est important, vous devrez peut-être mettre en place un regroupement de connexions (en utilisant par exemple la fonction de pool d'objets de Microsoft Enterprise Services).

Si la ressource doit être en mesure d'authentifier l'appelant initial (et que l'authentification Windows n'est pas disponible), vous disposez des options suivantes :

  • Transmettez les informations d'identification à l'aide de paramètres (appel de méthode).

  • Transmettez les informations d'identification dans une chaîne de connexion. Utilisez SSL ou IPSec pour sécuriser les informations d'identification en texte brut transmises sur un réseau.
    Stockez les informations d'identification de manière sécurisée dans votre application, par exemple à l'aide de DPAPI. Pour plus d'informations sur le stockage sécurisé de chaînes de connexion à une base de données, consultez la section « Stockage sécurisé des chaînes de connexion de base de données » dans le Module 12, « Sécurité de l'accès aux données ».

  • Utilisez un magasin de données centralisé pour l'authentification, auquel les deux plates-formes peuvent accéder, par exemple un répertoire LDAP.

Communication sécurisée

Utilisez SSL pour sécuriser la liaison de communication entre le navigateur et le serveur Web. SSL garantit la confidentialité et l'intégrité des messages. Utilisez SSL et/ou IPSec pour fournir un canal sécurisé du serveur Web au serveur d'applications ou au serveur de base de données.

Informations supplémentaires

Pour plus d'informations sur la communication sécurisée, consultez le Module 4, « Communication sécurisée ».

Stockage des secrets

Les applications Web doivent souvent stocker des secrets. Ceux-ci doivent être protégés contre des administrateurs malveillants et des utilisateurs Web malintentionnés :

  • Administrateurs malveillants. Les administrateurs malveillants et les utilisateurs peu scrupuleux ne doivent pas être en mesure de visualiser les informations confidentielles. Par exemple, l'administrateur du serveur Web ne doit pas être en mesure de lire le mot de passe d'un compte de connexion SQL Server sur un ordinateur SQL Server situé sur le réseau.

  • Utilisateurs Web malintentionnés. Certains composants (tels que FileAuthorizationModule) empêchent les utilisateurs d'accéder aux fichiers confidentiels. Toutefois, les secrets ne doivent pas figurer en texte brut dans les fichiers de configuration, afin d'éviter tout problème au cas où une personne malveillante obtiendrait l'accès à un fichier de configuration.

Quelques exemples de secrets sont répertoriés ci-après :

  • Chaînes de connexion SQL. Le stockage du mot de passe et du nom d'utilisateur en texte brut est une erreur courante. Il est recommandé d'utiliser l'authentification Windows à la place de l'authentification SQL. Si vous ne pouvez pas utiliser l'authentification Windows, consultez les sections suivantes du Module 12, « Sécurité de l'accès aux données », qui présente d'autres possibilités de sécurisation des données :

    • « Stockage sécurisé des chaînes de connexion de base de données »

    • « Communication sécurisée »

  • Informations d'identification utilisées pour les rôles d'applications SQL. Les rôles d'applications SQL doivent être activés avec une procédure stockée qui requiert le nom du rôle et le mot de passe associé. Pour plus d'informations, consultez la section « Autorisation » du Module 12, « Sécurité de l'accès aux données ».

  • Identités fixes dans le fichier Web.config. Par exemple :

    <identity impersonate="true" userName="bernard" password="inClearText"/>

    L'utilitaire aspnet_setreg.exe permet de remplacer les informations d'identification en texte brut par un pointeur associé à une clé de Registre sécurisée qui contient les informations d'identification cryptées.

  • Identité du processus dans le fichier Machine.config. Par exemple :

    <process userName="cUsTuMUzerName" password="kUsTumPazzWerD" >

    Conformément à l'élément <identity>, il est conseillé d'utiliser aspnet_setreg.exe pour stocker les informations d'identification sous forme cryptée dans le Registre.

  • Clés utilisées pour stocker les données de manière sécurisée. Il est impossible de stocker les clés de manière sécurisée dans le logiciel. Cependant, certaines tâches peuvent minimiser le risque. Vous pouvez, par exemple, créer un gestionnaire de section de configuration sécurisé qui utilise un cryptage asymétrique pour crypter une clé de session. La clé de session peut ensuite être stockée dans un fichier de configuration.

  • État de la session SQL Server. Pour utiliser SQL Server afin de gérer l'état de la session de l'application Web ASP.NET, utilisez les paramètres Web.config suivants.

    <sessionState ... stateConnectionString="tcpip=127.0.0.1:42424"
                sqlConnectionString="data source=127.0.0.1;
                user id=NomUtilisateur;password=MonMotDePasse" />

    L'utilitaire aspnet_setreg.exe prend également en charge les attributs stateConnectionString et sqlConnectionString sur l'élément <sessionState>, qui permet de stocker ces valeurs sous forme cryptée dans le Registre.

  • Mots de passe utilisés pour l'authentification par formulaires auprès d'une base de données.

    Si votre application valide les informations d'authentification auprès d'une base de données, ne stockez pas les mots de passe dans la base de données. Utilisez un hachage du mot de passe accompagné d'une valeur salt (nombre aléatoire) et comparez les hachages.

    Pour plus d'informations, consultez la section « Authentification des utilisateurs auprès d'une base de données » du Module 12, « Sécurité de l'accès aux données ».

Options de stockage des secrets dans ASP.NET

Les développeurs d'applications Web .NET ont à leur disposition plusieurs méthodes de stockage des secrets, notamment :

  • Classes de cryptographie .NET. .NET Framework inclut des classes susceptibles d'être utilisées pour le cryptage et le décryptage. Vous devez stocker la clé de cryptage de manière sécurisée pour utiliser ces méthodes.

  • API Data Protection (DPAPI). DPAPI est constitué de deux API Win32 qui cryptent et décryptent les données à l'aide d'une clé issue du mot de passe de l'utilisateur. Lorsque vous utilisez DPAPI, vous ne vous occupez pas de la gestion des clés. Le système d'exploitation gère la clé, qui est le mot de passe de l'utilisateur.

  • Chaînes de construction COM+. Si votre application utilise des composants desservis, vous pouvez stocker le secret dans une chaîne de construction d'objet. La chaîne est stockée dans le catalogue COM+ en texte brut.

  • CAPICOM. Il s'agit d'un objet COM Microsoft qui offre un accès COM à l'outil Crypto API sous-jacent.

  • Crypto API. Il s'agit des API Win32 de bas niveau qui effectuent le cryptage et le décryptage.

Informations supplémentaires

Pour plus d'informations, consultez l'entrée « Cryptography, CryptoAPI and CAPICOM » dans le Kit de développement de plate-forme sur MSDN.

Stockage des secrets dans des fichiers sur des volumes logiques séparés

Vous pouvez envisager d'installer les répertoires de l'application Web sur un volume logique distinct du système d'exploitation (par exemple E: au lieu de C:). Le fichier Machine.config (situé sous C:\WINNT\Microsoft.NET) et éventuellement d'autres fichiers contenant des secrets tels que des fichiers UDL (Universal Data Link), sont ainsi situés sur un volume logique distinct des répertoires de l'application Web.

Cette méthode vise à éliminer tout risque de simplification des droits d'accès aux fichiers et à offrir une protection contre les bogues susceptibles de permettre le parcours du répertoire car :

  • Les bogues de simplification des droits d'accès aux fichiers peuvent rendre les fichiers accessibles dans les dossiers de l'application Web.

    Remarque : les routines de simplification des droits d'accès aux fichiers renvoient les chemins d'accès complet des fichiers. Il s'agit généralement du nom de chemin absolu dans lequel toutes les références relatives et les références au répertoire actif ont été intégralement résolues.

  • Les bogues susceptibles de permettre le parcours du répertoire peuvent rendre les fichiers accessibles dans d'autres dossiers sur le même volume logique.

Aucun des bogues décrits ci-avant et ayant rendu accessibles des fichiers sur d'autres volumes logiques n'a encore été publié.

Sécurisation des états de session et d'affichage

Les applications Web doivent gérer différents types d'états, notamment l'état d'affichage et l'état de la session. Cette section aborde la gestion des états des applications Web ASP.NET.

Sécurisation de l'état d'affichage

Si vos applications Web ASP.NET Web utilisent l'état d'affichage :

  • Assurez l'intégrité de l'état d'affichage (pour garantir qu'il n'est altéré en aucune manière lors du transit) en attribuant la valeur « true » au paramètre enableViewStateMac , comme l'indique le code suivant. ASP.NET génère alors un code d'authentification des messages (Message Authentication Code, MAC) sur l'état d'affichage de la page lorsque celle-ci est republiée par le client.

    <![CDATA[<% @ Page enableViewStateMac=true >]]>

  • Configurez l'attribut validation sur l'élément <machineKey> dans le fichier Machine.config afin de spécifier l'algorithme à utiliser pour le cryptage et la validation des données. Considérez les points suivants relatifs à l'attribut validation :

    • L'algorithme SHA1 (Secure Hash Algorithm 1) génère une taille de hachage plus élevée que MD5 (Message Digest 5) et est par conséquent considéré comme étant plus sécurisé. Cependant, l'état d'affichage protégé avec SHA1 ou MD5 peut être décodé lors du transit ou du côté client et peut ainsi être visualisé en texte brut.

    • Utilisez la norme 3DES (3 Data Encryption Standard) pour détecter les modifications de l'état d'affichage et pour crypter celui-ci durant son transit. Dans cet état, l'état d'affichage ne peut pas être visualisé en texte brut, même s'il est décodé.

Sécurisation des cookies

Les cookies qui contiennent des données d'authentification, d'autorisation ou d'autres données sensibles doivent être protégés lors de leur transit à l'aide de SSL. Dans le cadre de l'authentification par formulaires, la méthode FormsAuthentication.Encrypt peut être utilisée pour crypter le ticket d'authentification transmis entre le client et le serveur dans un cookie.

Sécurisation de l'état de la session SQL

Le gestionnaire d'état de la session ASP.NET par défaut (in-process) est associé à certaines limitations. Par exemple, il ne fonctionne pas sur plusieurs ordinateurs situés dans une batterie de serveurs Internet. Pour contourner ce problème, ASP.NET autorise le stockage de l'état de la session dans une base de données SQL Server ou un service d'état distant.

L'état de la session SQL peut être configuré soit dans Machine.config, soit dans Web.config. Le paramètre par défaut dans machine.config est indiqué ci-après.

<sessionState mode="InProc" 
              stateConnectionString="tcpip=127.0.0.1:42424" 
              stateNetworkTimeout="10"
              sqlConnectionString="data source=127.0.0.1;user id=sa;password="
              cookieless="false" timeout="20"/>

Par défaut, le script SQL InstallSqlState.sql, qui permet de créer la base de données utilisée pour l'état de la session SQL, est installé à l'emplacement suivant :

C:\WINNT\Microsoft.NET\Framework\v1.0.3705

Lorsque vous utilisez l'état de la session SQL, deux problèmes sont à prendre en compte.

  • Vous devez sécuriser le chaîne de connexion de la base de données.

  • Vous devez sécuriser l'état de la session lors de son transit sur le réseau.

Sécurisation de la chaîne de connexion de la base de données

Si vous utilisez l'authentification SQL pour établir une connexion au serveur, la chaîne de connexion définie dans l'attribut sqlConnectionString contient un nom d'utilisateur et un mot de passe. Exécutez l'utilitaire aspnet_setreg.exe pour stocker une chaîne de connexion cryptée dans le Registre. L'exemple suivant illustre l'élément <sessionState> avant et après l'utilisation de aspnet_setreg.exe.

<!-- Avant -->
<sessionState 
    mode="SQLServer", 
    sqlConnectionString="data source=Server;user id=userID;password=pwd" . . . />
<!-- Après -->
<sessionState mode="SQLServer"
              sqlConnectionString="registry:HKLM\SOFTWARE\YourSecureApp\
              sessionState\ASPNET_SETREG,sqlConnectionString" />

Remarque : vous pouvez également faire appel à l'utilitaire aspnet_setreg.exe pour crypter l'attribut stateConnectionString si vous utilisez le service d'état ASP.NET.

Si possible, adoptez l'authentification Windows pour la base de données d'état SQL Server. Cette méthode présente l'avantage de ne pas stocker d'informations d'identification dans la chaîne de connexion et de ne pas les transmettre sur le réseau au serveur de base de données.

  • Pour utiliser l'authentification Windows, vous pouvez faire appel à l'identité du processus ASP.NET (généralement ASPNET).

    1. Créez un compte en double (avec le même nom et le même mot de passe) sur le serveur de base de données.

    2. Créez une connexion SQL Server pour le compte.

    3. Créez un utilisateur de base de données dans la base de données ASPState et mappez la connexion SQL au nouvel utilisateur.
      La base de données ASPState est créée par le script InstallSQLState.sql.

    4. Créez un rôle de base de données défini par l'utilisateur et ajoutez l'utilisateur de base de données au rôle.

    5. Configurez les autorisations dans la base de données pour le rôle de base de données.

Vous pouvez ensuite modifier la chaîne de connexion afin d'utiliser une connexion approuvée, comme l'indique le code suivant :

sqlConnectionString="server=127.0.0.1;
                     database=BaseDeDonnéesÉtat;
                     Integrated Security=SSPI;"
Sécurisation de l'état de la session sur le réseau

Vous devrez peut-être protéger l'état de la session lors de son transit sur le réseau vers la base de données SQL Server. Ceci dépend du niveau de sécurité du réseau hébergeant le serveur Web et les serveurs de données. Si la base de données est physiquement sécurisée dans un environnement approuvé, vous pourrez éviter cette mesure de sécurité supplémentaire.

Vous pouvez utiliser IPSec pour protéger l'ensemble du trafic IP entre les serveurs Web et SQL Server. Vous pouvez également utiliser SSL pour sécuriser la liaison à SQL Server. Dans le cadre de cette méthode, vous avez la possibilité de crypter uniquement la connexion utilisée pour l'état de la session, et non l'ensemble du trafic entre les ordinateurs.

Informations supplémentaires

  • Pour plus d'informations sur la configuration d'un état de session SQL, consultez l'article Q317604, « COMMENT FAIRE : Configurer SQL Server pour stocker un état de session ASP.NET » dans la Base de connaissances Microsoft.

  • Pour plus d'informations sur l'utilisation de SSL pour SQL Server, consultez la section « Procédure : Utiliser SSL pour sécuriser les communications avec SQL Server 2000 » dans ce guide.

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

Considérations sur les batteries de serveurs Internet

Dans un scénario de batterie de serveurs Internet, il n'est pas garanti que les demandes successives émanant du même client soient traitées par le même serveur Web. Cela a des conséquences sur la gestion de l'état et sur les formes de cryptages qui reposent sur des attributs gérés par l'élément <machineKey> du fichier Machine.config.

État de la session

La gestion de l'état de session in-process ASP.NET par défaut (qui reflète la fonctionnalité ASP précédente) entraîne une affinité du serveur et ne peut pas être utilisée dans un scénario de batterie de serveurs Internet. Pour le déploiement de batteries de serveurs Internet, l'état de la session doit être stocké en dehors du processus (out-of-process) dans le service d'état ASP.NET ou dans une base de données SQL Server, comme décrit précédemment.

Remarque : vous ne pouvez pas utiliser l'état de l'application pour gérer des compteurs globaux ou des valeurs uniques dans des scénarios de batterie de serveurs Internet (application Web configurée pour l'exécution sur plusieurs serveurs) ou de domaine privé Web (application Web configurée pour l'exécution sur plusieurs processeurs), car l'état de l'application n'est pas partagé sur plusieurs processus ou ordinateurs.

DPAPI

DPAPI peut fonctionner avec le magasin de l'ordinateur ou le magasin d'utilisateurs (qui nécessite un profil d'utilisateur chargé). Si vous utilisez DPAPI avec le magasin de l'ordinateur, la chaîne cryptée est spécifique à un ordinateur particulier et vous devez par conséquent générer les données cryptées sur chaque ordinateur. Ne copiez pas les données cryptées sur plusieurs ordinateurs organisés en cluster ou en batterie de serveurs Internet.

Si vous utilisez DPAPI avec le magasin d'utilisateurs, vous pouvez décrypter les données sur n'importe quel ordinateur avec un profil d'utilisateur itinérant.

Informations supplémentaires

Pour plus d'informations sur DPAPI, consultez le Module 12, « Sécurité de l'accès aux données ».

Utilisation de l'authentification par formulaires dans une batterie de serveurs Internet

Si vous utilisez l'authentification par formulaires, il est essentiel que tous les serveurs de la batterie de serveurs Internet partagent la même clé d'ordinateur, qui est utilisée pour le cryptage, le décryptage et la validation du ticket d'authentification.

La clé d'ordinateur est gérée par l'élément <machineKey> du fichier Machine.config. Le paramètre par défaut est présenté ci-après.

<machineKey validationKey="AutoGenerate" 
            decryptionKey="AutoGenerate" 
            validation="SHA1"/>

Avec ce paramètre, chaque ordinateur génère une clé de décryptage et de validation différente. Vous devez modifier l'élément <machineKey> et placer les clés communes sur tous les serveurs de la batterie de serveurs Internet.

Élément <machineKey>

L'élément <machineKey> situé dans le fichier Machine.config permet de configurer les clés utilisées pour le cryptage et le décryptage des données des cookies d'authentification par formulaires et pour la vérification de l'intégrité et le cryptage de l'état d'affichage.

Lorsque la méthode FormsAuthentication.Encrypt ou FormsAuthentication.Decrypt est appelée, et lorsque l'état d'affichage est créé ou extrait, les valeurs de l'élément <machineKey> sont consultées.

<machineKey validationKey="autogenerate|value"
            decryptionKey="autogenerate|value"
            validation="SHA1|MD5|3DES" />
Attribut validationKey

La valeur de l'attribut validationKey permet de créer et de valider les codes MAC pour l'état d'affichage et les tickets d'authentification par formulaires. L'attribut de validation indique l'algorithme qui doit être utilisé lors de la procédure de génération de codes MAC. Prenez note des éléments suivants :

  • Dans le cadre de l'authentification par formulaires, cette clé fonctionne avec l'attribut <forms> protection. Si la valeur Validation est associée à l'attribut protection et que la méthode FormsAuthentication.Encrypt est appelée, la valeur du ticket et l'attribut validationKey sont utilisés pour calculer un code MAC qui est ajouté au cookie. Lorsque la méthode FormsAuthentication.Decrypt est appelée, le code MAC est calculé puis comparé au code MAC qui est ajouté au ticket.

  • Dans le cadre de l'état d'affichage, la valeur de l'état d'affichage d'un contrôle et l'attribut validationKey sont utilisés pour calculer un code MAC, qui est ajouté à l'état d'affichage. Lorsque l'état d'affichage est republié par le client, le code MAC est recalculé puis comparé au code MAC qui est ajouté à l'état d'affichage.

Attribut decryptionKey

La valeur de l'attribut decryptionKey permet de crypter et de décrypter les tickets d'authentification par formulaires et l'état d'affichage. Les algorithmes DES ou Triple DES (3DES) sont utilisés. L'algorithme utilisé varie selon que le pack de cryptage élevé Windows 2000 (High Encryption Pack) est installé ou non sur le serveur. S'il est installé, 3DES est utilisé. Dans le cas contraire, DES est utilisé. Prenez note des éléments suivants :

  • Dans le cadre de l'authentification par formulaires, cette clé fonctionne en conjonction avec l'attribut <forms> protection. Si l'attribut protection a la valeur Encryption et si la méthode FormsAuthentication.Encrypt ou Decrypt est appelée, la valeur du ticket est cryptée ou décryptée à l'aide de la valeur decryptionKey spécifiée.

  • Dans le cadre de l'état d'affichage, la valeur de l'état d'affichage d'un contrôle est cryptée à l'aide de la valeur decryptionKey lorsqu'elle est envoyée au client. Elle est ensuite décryptée lorsque le client republie les données sur le serveur.

Attribut Validation

Cet attribut stipule l'algorithme qui doit être utilisé lors de la validation, du cryptage ou du décryptage. Il peut adopter les valeurs SHA1, MD5 ou 3DES. Ces valeurs sont décrites ci-après :

  • SHA1. L'algorithme HMACSHA1 est utilisé lorsque le paramètre est associé à la valeur SHA1. Il génère un hachage (digest) de 160 bits (20 octets) de l'entrée. HMACSHA1 est un algorithme de hachage reposant sur une clé. La clé utilisée comme entrée de cet algorithme est indiquée par l'attribut validationKey.
    SHA1 est un algorithme très utilisé, car la taille des éléments cryptés est plus importante que celle d'autres algorithmes.

  • MD5. Génère un hachage de 20 octets à l'aide de l'algorithme MD5.

  • 3DES. Crypte les données à l'aide de l'algorithme Triple DES (3DES).

    Remarque : lorsque l'attribut Validation est associé à la valeur 3DES, il n'est pas utilisé par l'authentification par formulaires. SHA1 est utilisé dans ce cas.

Informations supplémentaires

Résumé

Ce module vous a présenté différentes techniques et méthodes permettant de sécuriser des applications Web ASP.NET. La plupart des recommandations et des conseils présentés dans ce module s'appliquent également au développement de services Web ASP.NET et d'objets .NET Remoting hébergés par ASP.NET. En résumé :

  • Si votre application utilise l'authentification par formulaires et si les performances sont importantes lors de l'authentification de l'utilisateur, récupérez la liste des rôles et stockez-les dans le ticket d'authentification.

  • Si vous utilisez l'authentification par formulaires, créez un objet Principal et stockez-le dans le contexte pour chaque demande.

  • Si les rôles sont trop nombreux pour être stockés dans un cookie d'authentification, utilisez le cache d'application global pour stocker les rôles.

  • Ne créez pas de compte personnalisé doté de privilèges minimum pour exécuter ASP.NET. À la place, modifiez le mot de passe du compte ASPNET et créez un compte en double sur le serveur Windows distant auquel votre application doit accéder.

  • Si vous créez un compte personnalisé pour exécuter ASP.NET, utilisez le principe du moindre privilège. Par exemple :

    • Utilisez un compte de domaine doté de privilèges minimum si vous accordez la priorité à l'administration.

    • Si vous utilisez un compte local, vous devez créer un compte en double sur l'ordinateur distant auquel l'application Web doit accéder. Vous devez utiliser des comptes locaux lorsque votre application doit accéder à des ressources dans des domaines non autorisés à approuver ou lorsqu'un pare-feu empêche l'authentification Windows.

    • N'exécutez pas ASP.NET à l'aide du compte local SYSTEM.

    • N'accordez pas au compte ASPNET le privilège « Fonctionner en tant que partie intégrante du système d'exploitation ».

  • Utilisez SSL dans les cas de figure suivants :

    • Lorsque des informations de sécurité sensibles sont transmises entre le navigateur et le serveur Web.

    • Lorsque l'authentification de base est utilisée (pour protéger les informations d'identification).

    • Lorsque l'authentification par formulaires est utilisée pour l'authentification (contrairement à la personnalisation).

  • Évitez de stocker des secrets en texte brut.

    • Ne stockez pas d'informations d'identification en texte brut dans le fichier Machine.config ou web.config. Exécutez l'utilitaire aspnet_setreg.exe pour stocker des informations d'identification cryptées dans le Registre pour les éléments <identity>, <processModel> et <sessionState>.

© 2009 Microsoft Corporation. Tous droits réservés. Conditions d'utilisation | Marques | Confidentialité
Page view tracker