Cette page vous a-t-elle été utile ?
Votre avis sur ce contenu est important. N'hésitez pas à nous faire part de vos commentaires.
Vous avez d'autres commentaires ?
1500 caractères restants
Exporter (0) Imprimer
Développer tout

Authentification dans ASP.NET : conseils de sécurité .NET

Jeff Kercher, auteur
Edward Jezierski, responsable programmes
Microsoft Corporation

Résumé : cet article traite de l'importance des aspects relatifs à la sécurité lors de la conception d'une application serveur. Les services IIS (Internet Information Services) et ASP.NET offrent des modèles de sécurité qui permettent d'authentifier vos utilisateurs comme il convient et d'obtenir le contexte de sécurité adéquat au sein de votre application.

Sommaire

Introduction
Remarques relatives à la sécurité
Relations entre IIS et ASP.NET
Méthodes d'authentification
Sécurité des services Web
Système CAS (Code Access Security)
Sécurité des canaux
Informations complémentaires
Annexe A

Introduction

La sécurité est un des principaux soucis pour les architectes et les développeurs de programmes. Les applications qui contiennent des informations stratégiques doivent être protégées contre les attaques malveillantes et contre toute tentative éventuelle de la part de la concurrence de dérober des informations ou des éléments relevant de la propriété intellectuelle. Lors de la conception d'un modèle de sécurité pour votre application, vous devez connaître parfaitement les exigences de sécurité d'un point de vue commercial, ainsi que les conséquences que le choix d'un modèle de sécurité spécifique peut avoir sur les performances, l'évolutivité et le déploiement.

Remarques relatives à la sécurité

Lorsque vous créez une application serveur, le document de spécification correspondant doit contenir une section relatives aux questions liées à la sécurité. Dans la spécification fonctionnelle de votre application, vous devez examiner les éléments suivants et, dans la mesure du possible, apporter une réponse concrète :

  • Objectifs de sécurité. Mettre en évidence les objectifs à atteindre et vous assurer que vous pouvez les décrire.
  • Risques relatifs à la sécurité. Connaître les points vulnérables de votre application. Vous devez également avoir une idée précise des menaces éventuelles qui guettent votre activité.
  • Authentification. Il s'agit d'accepter les informations d'identification fournies par un utilisateur et de les valider auprès d'une autorité désignée. L'identité de l'utilisateur (ou éventuellement celle d'une application ou d'un ordinateur) constitue ce que l'on appelle l'entité de sécurité. Le client doit fournir des informations d'identification pour permettre aux serveur de vérifier cette entité. Une fois que l'identité est connue, l'application peut autoriser l'entité à accéder aux ressources du système. La section suivante de ce document présente divers critères qui vous aideront à choisir la méthode d'authentification appropriée.
  • Autorisation. Il s'agit de déterminer si l'identité déclinée a le droit d'accéder à une ressource spécifique.
  • Sécurisation de la transmission des données. En cryptant les données envoyées sur le réseau, vous vous assurez qu'elles ne seront pas consultées sans permission ou falsifiées pendant leur transfert. Vous devez tenir compte du degré de sécurisation qu'exigent les données circulant sur le réseau.
  • Emprunt d'identité. Ce dispositif permet à un processus serveur de s'exécuter en utilisant les informations d'identification du client. Lorsque le serveur emprunte l'identité du client, toutes les opérations qu'il exécute sont réalisées avec les informations d'identification de ce client. Toutefois, l'emprunt d'identité ne permet pas au serveur d'accéder à des ressources distantes au nom du client. Pour ce type d'opération, une délégation s'avère nécessaire.
  • Délégation. Comme l'emprunt d'identité, ce dispositif permet à un processus serveur de s'exécuter en utilisant les informations d'identification du client. Cependant, la délégation va plus loin en autorisant le processus serveur à appeler d'autres ordinateurs au nom du client.
  • Sécurité du système d'exploitation. Ce dispositif fait référence à la mise en place de liste de contrôle d'accès (ACL) et à la sécurité du réseau pour interdire les personnes non habilitées d'accéder aux ressources sécurisées. Vous devez définir les listes ACL adéquates sur les ressources à protéger afin d'en permettre l'accès aux seules entités autorisées.
  • Sécurisation des accès physiques. Il s'agit tout simplement d'installer votre machine serveur dans une salle sécurisée. Ne négligez pas cet aspect.
  • Système CAS. Ce système permet d'approuver un code à des degrés différents, en fonction de sa provenance et de certains autres aspects concernant son identité. Vous devez déterminer comment créer vos propres droits d'accès.

Relations entre IIS et ASP.NET

Pour concevoir votre application, vous devez clairement comprendre les relations entre l'authentification des services IIS et l'architecture de sécurité de Microsoft® ASP.NET. Ceci vous permettra d'authentifier correctement vos utilisateurs et de mettre en place le contexte de sécurité adapté à votre application. Notez que la configuration de la sécurité des applications ASP.NET et la configuration de sécurité IIS sont totalement indépendantes, de sorte que vous pouvez les utiliser indépendamment ou conjointement.

Pour IIS, les paramètres de configuration relatifs à la sécurité sont stockés dans la métabase de données IIS. Ceux concernant la sécurité ASP .NET (mais pas uniquement ceux-là) sont regroupés dans des fichiers de configuration XML. Cette distinction simplifie en général le déploiement de votre application du point de vue sécuritaire, mais le modèle de sécurité adopté par l'application va également exiger la configuration adéquate aussi bien de la métabase IIS que de l'application ASP.NET via son fichier de configuration (Web.config).

La figure 1 illustre les relations entre IIS et ASP.NET.

Figure 1.
figure 1. Relations entre IIS et ASP.NET sur le plan de la sécurité

Fournisseurs d'authentification ASP.NET et sécurité IIS

ASP.NET met en œuvre l'authentification en utilisant des fournisseurs d'authentification, à savoir des modules de code qui vérifient les informations d'identification et implémentent d'autres fonctionnalités de sécurité, comme la génération de cookies. ASP.NET prend en charge les trois fournisseurs suivants :

  • Authentification par formulaire. Avec ce fournisseur, les requêtes non authentifiées sont redirigées vers un formulaire HTML spécifié par le biais d'un processus de redirection côté client. L'utilisateur peut ensuite fournir les informations d'identification nécessaires à l'ouverture de la session et renvoyer le formulaire au serveur. Si l'application authentifie la requête (à l'aide d'une logique qui lui est propre), ASP.NET émet un cookie contenant les informations d'identification ou une clé en vue d'acquérir à nouveau l'identité du client. Les requêtes suivantes contiennent le cookie dans leur en-tête, de sorte qu'il n'est pas nécessaire de procéder à de nouvelles authentifications.
  • Authentification par passport. Ce service d'authentification centralisé, fourni par Microsoft, offre un système de connexion unique et des services d'abonnement (membership) pour les sites participants. ASP.NET, en association avec le kit de développement (SDK) Microsoft® Passport, offre une fonctionnalité similaire à l'authentification par formulaire aux utilisateurs de Passport.
  • Authentification Windows. Ce module utilise les fonctions d'authentification d'IIS. Une fois qu'IIS a procédé à l'authentification, ASP.NET utilise le jeton (token) de l'identité authentifiée pour autoriser l'accès.

Pour appliquer un fournisseur d'authentification particulier à une application ASP.NET, vous devez créer une entrée dans le fichier de configuration de celle-ci, comme indiqué ci-après :

// fichier web.config
<authentication mode = "[Windows/Cookie/Passport/None]">
</authentication>

Outre l'authentification, ASP.NET propose un mécanisme d'emprunt d'identité visant à déterminer le jeton de sécurité du thread de l'application. Pour obtenir le jeton adéquat, il vous appartient de configurer de manière appropriée l'authentification IIS, les fournisseurs d'authentification ASP.NET et les paramètres d'emprunt d'identité ASP .NET. La figure 2 montre les combinaisons les plus probables entre l'authentification IIS et les fournisseurs ASP.NET.

figure 2.
figure 2. Schéma des paramètres de sécurité ASP.NET et IIS

Authentification utilisant des comptes Windows

Si vous envisagez d'authentifier des utilisateurs en vous servant des comptes gérés par un contrôleur de domaine Microsoft Windows NT® ou au sein de Microsoft Windows® 2000 Active Directory™, vous devez utiliser l'authentification IIS couplée au Fournisseur Windows pour ASP.NET, comme le montre la figure 2. Ce faisant, vous n'avez pas besoin d'écrire un code d'authentification spécifique. Lorsque l'authentification se déroule selon cette méthode, ASP.NET crée un objet Windows Principal (entité) et l'associe au contexte de l'application, en fonction de l'utilisateur authentifié. Ainsi, le thread ASP.NET peut s'exécuter en tant qu'utilisateur authentifié et obtenir l'adhésion au groupe de l'utilisateur.

Dans certains cas, vous pouvez contourner l'authentification IIS et mettre en place une solution personnalisée. Cela est également possible avec ASP.NET. Vous écrivez par exemple un filtre ISAPI personnalisé qui vérifie les informations d'identification de l'utilisateur par rapport à Active Directory et la création de l'objet Windows Principal se fera manuellement. D'autres méthodes sont également possibles mais vous devrez écrire davantage de code qu'en utilisant directement le fournisseur .NET.

Authentification utilisant des comptes non-Windows

Si vous prévoyez d'authentifier des utilisateurs au niveau de l'application et si ces utilisateurs n'ont pas de comptes Windows, vous allez configurer IIS pour une authentification anonyme. Dans cette configuration, vous disposez des modules d'authentification .NET suivants :

  • None : si vous n'authentifiez pas les utilisateurs ou si vous développez un code d'authentification personnalisé.
  • Forms : si vous souhaitez qu'une page de connexion soit présentée aux utilisateurs.
  • Passport : si vous utilisez les services Passport.
Emprunt d'identité et délégation

Avec l'emprunt d'identité, les applications ASP.NET peuvent éventuellement s'exécuter avec l'identité du client au nom duquel elles fonctionnent. L'emprunt d'identité est généralement employé pour contrôler l'accès aux ressources. Examinez avec soin si ce dispositif est vraiment nécessaire ou non, car il consomme davantage de ressources serveur. La délégation est une forme plus puissante de l'emprunt d'identité car le processus serveur a alors l'accès à des ressources distantes tout en agissant en tant que client.

Si l'emprunt d'identité est activé, ASP.NET reçoit le jeton qui lui permet de réaliser cet emprunt à partir d'IIS. Dans une application Web, vous contrôlez mieux l'emprunt d'identité avec ASP.NET qu'avec les pages ASP classiques. Il suffit en effet de spécifier une valeur dans le fichier Web.config de l'application.

Lorsque vous spécifiez le paramètre d'emprunt d'identité, trois options sont possibles :

  • Emprunt d'identité activé. Dans ce cas, ASP.NET emprunte le jeton qui lui est transmis par IIS, qui correspond soit à un utilisateur authentifié, soit à un compte d'utilisateur Internet anonyme.
    <identity impersonate="true"/>
    
    
  • Emprunt d'identité activé, avec mention d'une identité d'emprunt spécifique. Dans ce cas, ASP.NET emprunte le jeton généré en utilisant l'identité configurée. Le jeton du client, s'il existe, n'est pas utilisé.
    <identity impersonate="true" name="domain\user" password="pwd"/>
    
    
  • Emprunt d'identité désactivé. Il s'agit de l'option par défaut qui assure la compatibilité avec ASP. Dans ce cas, le thread ASP .NET s'exécute en utilisant le jeton du processus de travail de l'application, qui par défaut est le compte système IIS, quelle que soit la combinaison d'authentification (IIS ou ASP.NET) utilisée.
    <identity impersonate="false"/>
    
    

Si l'application réside sur un partage UNC, ASP.NET va toujours emprunter le jeton UNC IIS pour accéder à ce partage, à moins qu'un compte configuré soit employé. Si le compte explicitement configuré est spécifié, ASP.NET l'utilise de préférence au jeton UNC IIS.

Le tableau 1 montre le jeton du thread utilisé par ASP.NET pour exécuter la requête, en fonction de trois paramètres de configuration différents dans Web.config. Remarquez bien que le compte IUSR_SERVER désigne le compte configuré en vue d'un accès anonyme pour l'URL en cours (il ne s'agit donc pas nécessairement d'un compte IUSR_). Le compte processus est celui qu'utilise le processus de travail de l'application pour s'exécuter : par défaut, il s'agit du compte système (System Account), sauf s'il en existe un autre, configuré.


Tableau 1. Jeton de thread ASP pour configurations ASP et IIS

Emprunt d'identité ASP.NETIIS utilise le compte anonymeIIS n'utilise pas le compte anonymeL'application réside sur un partage UNC
DésactivéCompte processusCompte processusJeton UNC IIS
Activé IUSR_SERVER Utilisateur authentifiéJeton UNC IIS
Activé avec l'utilisateur spécifié "Jeff""Jeff""Jeff""Jeff"
Identités d'application

Il est conseillé d'exécuter le processus de travail d'application ASP .NET (aspnet_wp.exe) en utilisant un compte spécialement configuré, avec des privilèges moindres que le compte System par défaut. Il y a à cela deux raisons. Premièrement, même si le dispositif de sécurité est violé, l'intrus ne possède pas d'accès en tant qu'administrateur. Deuxièmement, cela permet aux fournisseurs d'applications hébergées (FAH) d'exécuter des applications en utilisant des comptes "moins puissants", afin que les applications hébergées ne puissent pas compromettre l'intégrité du serveur ou réaliser des opérations exigeant des droits d'administration.

Pour exécuter le processus de travail ASP en utilisant un compte spécifié, ajoutez un élément <processModel> dans le fichier de configuration racine (machine.config), qui se trouve dans le dossier \WINNT\Microsoft.NET\Framework\Version\Config, comme indiqué ci-dessous :

<system.web>
 <processModel enable="true" username="domain\user" password="pwd"/>
</system.web>

Outre la spécification d'un compte utilisateur particulier, vous pouvez donner à l'attribut username une des deux valeurs spécialement reconnues, à savoir "SYSTEM" ou "MACHINE". Dans les deux cas, l'attribut password doit être défini à "AutoGenerate", puisqu'aucune information d'identification n'est requise. Le paramètre "SYSTEM" (par défaut) exécute le processus de travail en utilisant le compte System, alors qu'avec le paramètre "MACHINE", le processus s'exécute avec un compte spécial nommé à l'aide d'un préfixe ASPNET. Ce compte est semblable au compte IWAM_MACHINENAME utilisé par IIS pour exécuter des instances de dllhost.exe en cas d'hébergement d'applications ASP standard. Le compte ASPNET est créé durant l'installation .NET.

Si vous utilisez un compte personnalisé, celui-ci doit posséder les droits d'accès nécessaires sur les répertoires suivants.

  • Un accès Lecture/Écriture est requis sur le répertoire %installroot%\ASP.NET Temporary Files. Les sous-répertoires qui en dépendent servent à stocker une sortie compilée de manière dynamique.
  • Un accès Lecture/Écriture est requis sur le répertoire %temp%. Celui-ci est utilisé par les compilateurs lors de la compilation dynamique.
  • Un accès Lecture est requis sur le répertoire de l'application.
  • Un accès Lecture est requis sur l'arborescence %installroot% pour permettre l'accès aux assembly système.

Notez que les rubriques de contrôle d'accès (ACE) appropriées sont définies durant le processus d'installation pour le compte ASPNET.

Si vous utilisez un compte processus spécialement configuré, vous devez savoir qu'il limite de façon non négligeable l'emprunt d'identité. Bien qu'il vous soit possible d'emprunter l'identité du client, vous ne pouvez pas utiliser la forme étendue d'emprunt d'identité lorsqu'un compte d'emprunt spécifique est défini dans le fichier Web.config de l'application. Cette option requiert en effet que le processus de travail ait le privilège SE_TCB_NAME ("Agir en tant que partie du système d'exploitation"), ce qui n'est généralement pas le cas d'un processus à l'identité plus faible. L'emprunt d'identité par requête continue toutefois de fonctionner car IIS crée la session de connexion et transmet le jeton d'emprunt d'identité directement au processus de travail. Cette restriction s'applique uniquement à Windows 2000 et Windows NT 4. Microsoft Windows XP apporte des améliorations qui permettent la création de sessions de connexion spécifiques sans que ce privilège soit nécessaire.

Pour plus d'informations, consultez les chapitres suivants du Guide .NET Framework Developers Guide :

  • "How ASP.NET Security Works"
  • "ASP.NET Authentication"
  • "ASP.NET Configuration Concepts"
  • "Using IIS Authentication With ASP.NET Impersonation"

Pour plus d'informations sur l'authentification dans IIS 5.0, reportez-vous à l'article " Internet Information Services 5.0 Authentication Methods Lien non MSDN France Site en anglais".

Méthodes d'authentification

Dans vos applications Web .NET, vous disposez de nombreuses options d'authentification. Par exemple, vous pouvez choisir un des mécanismes IIS pris en charge ou procéder à une authentification au sein même du code de votre application. Au moment de faire votre choix, vous devez tenir compte de certains des facteurs suivants :

  • Systèmes d'exploitation serveur et client
  • Type de navigateur client
  • Nombre d'utilisateurs, emplacement et type de la base de données des noms d'utilisateurs et des mots de passe
  • Aspects liés au déploiement : votre application est-elle de type Internet ou intranet, réside-t-elle derrière un pare-feu, etc.
  • Type de l'application, par exemple : s'agit-il d'un site Web interactif ou d'un service Web non interactif ?
  • Degré de confidentialité des données que vous protégez
  • Performances et facteurs d'évolutivité
  • Autorisations à accorder, par exemple : voulez-vous mettre votre application à la disposition de tous les utilisateurs, ou souhaitez-vous limiter certains domaines à des utilisateurs reconnus et d'autres domaines aux administrateurs uniquement ?

Choix d'une méthode d'authentification

Vous pouvez utiliser le diagramme proposé en Annexe A pour vous aider à déterminer la méthode d'authentification la plus adaptée, en fonction des besoins de votre application. Pour utiliser ce diagramme, répondez aux questions concernant la nature de la base utilisateurs et le modèle de déploiement. Les cases d'extrémité du diagramme désignent les méthodes d'authentification appropriées qu'il est possible d'adopter.

Après examen du diagramme, reportez-vous aux sous-sections suivantes qui contiennent des informations plus détaillées sur les différentes méthodes et apportent des éléments qui vous aideront dans votre choix. À la fin de cette section, vous devez être en mesure de choisir une méthode.

Explication des points de décision du diagramme
  1. Les utilisateurs doivent-ils se connecter avec un login ? Est-ce qu'un nom d'utilisateur et un mot de passe sont nécessaires pour accéder au site ou au service ?
  2. La personnalisation est-elle nécessaire ? Le site va-t-il proposer un contenu personnalisé, sans exiger des utilisateurs qu'ils ouvrent une session ?
  3. Comptes utilisateurs ? Les comptes utilisateurs sont-ils des comptes Windows NT Domain, Active Directory, ou sont-ils stockés dans d'autres bases de données, par exemple une base relationnelle, un autre service de répertoire LDAP (Lightweight Directory Access Protocol) ou un fichier XML ?
  4. Une connexion unique ou une connexion transparente est-elle nécessaire ? Voulez-vous que les utilisateurs se connectent via une page de connexion ou souhaitez-vous que l'authentification se déroule automatiquement ? Par exemple, vous pouvez demander une authentification automatique pour une transaction automatisée BtoB (Business-to-Business).
  5. Avez-vous besoin d'une connexion sécurisée ? Voulez-vous que votre système soit quasiment inviolable pour empêcher les pirates de dérober des noms d'utilisateur et des mots de passe sur le réseau ? Cette décision dépend en général du degré de confidentialité des données placées sur le site.
  6. L'application s'exécutera-t-elle sur Internet ? L'application se trouvera-t-elle derrière un pare-feu, où les utilisateurs ne sont pas authentifié par rapport à un domaine, ou bien s'agira-t-il d'une application intranet où les utilisateurs sont peut-être déjà authentifiés sur un domaine ?
  7. Avez-vous besoin de déléguer le contexte de sécurité ? Avez-vous besoin que des composants métier s'exécutent avec l'identité de l'appelant ? Dans la négative, l'emprunt d'identité est nécessaire. En outre, si vous devez accéder à des ressources système, par exemple des files d'attente de messages, des bases de données ou des fichiers système sur des ordinateurs distants, un emprunt d'identité avec délégation est nécessaire.
  8. Les serveurs et les clients s'exécutent-ils uniquement sur Windows 2000 ? Utilisez-vous un environnement homogène d'ordinateurs avec Windows 2000, ou existe-t-il des clients qui fonctionnent avec d'autres systèmes d'exploitation tels que Windows 9x et Windows NT 4.0 ?

Authentification anonyme

Avec l'authentification anonyme, le serveur ne demande pas au client d'envoyer les informations d'identification de l'utilisateur. Cette méthode est idéale si votre site ou votre service est accessible à tous et si vous n'avez pas besoin de connaître l'identité de l'appelant. De plus, il n'existe pas de restrictions liées au navigateur et qui seraient dues à des incompatibilités avec les mécanismes d'authentification pris en charge. Lorsqu'un site est configuré pour une authentification anonyme, tous les utilisateurs peuvent y accéder. Il convient de noter que, même si vous avez configuré IIS pour une authentification anonyme, l'authentification peut se dérouler au niveau de la couche ASP.NET, ce qui n'est pas une véritable authentification anonyme. Dans cette section, nous partons du principe que IIS et l'application n'ont pas besoin de login.

Scénarios d'utilisation classiques

Vous devez envisager l'authentification anonyme dans les cas suivants :

  • Vous n'avez pas besoin de connaître le nom et/ou le mot de passe de l'appelant, que ce soit pour la connexion ou pour les composants de la logique métier.
  • Les informations que vous protégez sont considérées comme étant "publiques".

Vous ne devez pas envisager l'authentification anonyme dans les cas suivants :

  • Vous limitez votre base utilisateurs en exigeant un nom de login et un mot de passe.
Autres considérations

Vous devez également tenir compte des éléments suivants si vous choisissez l'authentification anonyme.

Sites avec un contenu personnalisé seulement

Si vous créez un site offrant exclusivement un contenu personnalisé, l'authentification anonyme peut vous convenir. C'est le cas par exemple d'un site qui diffuse les nouvelles locales en fonction du code postal de l'utilisateur, sans que celui-ci ait besoin d'ouvrir explicitement une session. La fonction de personnalisation peut être mise en œuvre à l'aide de cookies, séparément de l'authentification. Pour plus d'informations sur les cookies, reportez-vous à la section sur les Cookies plus loin dans ce document.

Emprunt d'identité

Dans le cas d'une authentification anonyme, le thread de l'application s'exécute :

  • soit comme compte Internet intégré anonyme, IUSR_MACHINENAME,
  • soit comme compte configuré dans IIS pour l'utilisateur anonyme,
  • soit comme compte système IIS.

Si votre application utilise d'autres ressources, par exemple des composants COM+, des bases de données, des files d'attente de messages ou des partages de fichiers UNC, vous devez définir les autorisations appropriées pour l'utilisateur anonyme. Si c'est le cas, tenez compte des observations suivantes :

  • Configurez un contrôleur de domaines comprenant tous vos serveurs Web et d'applications. Configurez l'utilisateur anonyme afin qu'il s'exécute comme utilisateur de domaine avec les autorisations adéquates pour accéder aux ressources. Cette méthode offre une plus grande souplesse car la gestion des comptes est centralisée.
  • Si vous n'appartenez pas à un domaine, vous pouvez créer un utilisateur ayant les mêmes nom et mot de passe sur chacun des serveurs Web ou d'applications. Toutefois, cette solution est déconseillée en raison des difficultés liées à la gestion de comptes dupliqués.

Performances

Le fait d'avoir un site Web anonyme et de ne pas utiliser l'emprunt d'identité ASP.NET améliore les performances, mais il s'agit là de la configuration d'applications la moins sécurisée.

Mise en œuvre

Pour mettre en œuvre l'authentification anonyme, configurez IIS pour ce type d'authentification et définissez le compte d'utilisateur anonyme approprié. Par ailleurs, configurez ASP.NET à l'aide du fichier Web.config de façon à désactiver l'authentification.

// fichier web.config
<system.web>
 <authentication mode="None" />
</system.web>

Authentification de base

Lorsque IIS est configuré pour l'authentification de base, le navigateur reçoit l'instruction d'envoyer les informations d'identification de l'utilisateur via HTTP. Les mots de passe et noms d'utilisateur sont codés à l'aide du codage Base64. Bien que le mot de passe soit codé, il est jugé peu sûr en raison de la relative facilité avec laquelle il peut être décrypté. Le navigateur présente une boîte de dialogue à l'utilisateur puis il émet de nouveau la requête anonyme d'origine avec les informations d'identification fournies, y compris le nom d'utilisateur et le mot de passe. L'affichage contextuel d'une boîte de connexion peut s'avérer utile ou non, selon les besoins propres à la conception de votre interface utilisateur. La plupart des navigateurs Internet prennent en charge l'authentification.

Scénarios d'utilisation classiques

Vous devez envisager l'authentification de base dans les cas suivants :

  • Vos utilisateurs ont des comptes Windows NT Domain ou Active Directory.
  • Vous devez prendre en charge plusieurs types de navigateurs, y compris Netscape Navigator et toutes les versions d'Internet Explorer (y compris les plates-formes Pocket PC et Windows CE).
  • Vous devez gérer l'authentification sur Internet.
  • Vous devez accéder au mot de passe en clair dans votre code d'application.
  • Vous devez gérer la délégation.

Vous ne devez pas envisager l'authentification de base dans les cas suivants :

  • Vous avez besoin d'une connexion sécurisée et vous n'utilisez pas de canal sécurisé tel qu'en propose SSL (Secure Sockets Layer).
  • Vos utilisateurs sont enregistrés dans une base de données personnalisées et n'ont pas de compte Windows.
  • Vous tenez à ce qu'un formulaire personnalisé soit présenté à l'utilisateur comme page de connexion.
Autres considérations

Vous devez également tenir compte des éléments suivants si vous choisissez l'authentification de base.

Délégation utilisant l'authentification de base

Il est possible d'associer l'authentification de base à un processus de délégation d'un ordinateur à un autre (mais pas au-delà). Dans le cadre de la délégation, le serveur IIS connecte l'utilisateur localement via un appel à l'API Win32 LogonUser. IIS disposant du mot de passe de l'utilisateur en clair, il peut répondre aux sollicitations d'ordinateurs distants, ce qui permet au serveur Web d'agir au nom du client. Si vous avez besoin de déléguer le contexte de sécurité à d'autres ordinateurs (au-delà du premier qui a bénéficié de la délégation), vous devez localement établir des connexions avec les autres ordinateurs de la chaîne d'appel. L'authentification de base autorise cette démarche car vous avez accès au nom d'utilisateur et au mot de passe en clair, et vous pouvez les transmettre à d'autres applications telles que celles basées sur ISAPI ou CGI.

Sécurisation de l'authentification de base

N'oubliez pas que le mot de passe peut facilement être décrypté ; vous devez donc limiter l'authentification de base à des applications non sécurisées ou, tout au plus, à des applications à demi sécurisées.

Vous pouvez sécuriser l'authentification de base en l'associant à SSL. Vous empêchez ainsi le décryptage des mots de passe. Bon nombre d'applications Internet actuelles ont recours à cette association.

Mise en œuvre

Pour mettre en œuvre l'authentification de base, configurez-la dans IIS et vérifiez que vos utilisateurs possèdent l'autorisation "connexion locale" sur le serveur Web. Si votre application ASP.NET doit s'exécuter en tant qu'utilisateur identifié par l'authentification de base, configurez le fichier Web.config comme suit :

// fichier web.config
<system.web>
 <authentication mode="Windows" />
</system.web>

Authentification Digest

Il s'agit d'un nouveau mode d'authentification proposé avec Windows 2000 et IIS 5.0. Il repose sur le cryptage du mot de passe de l'utilisateur et fournit un mécanisme qui empêche certaines attaques de serveur courantes (attaque replay par exemple). Dans l'authentification Digest, les informations d'identification ne sont pas envoyées en clair sur le réseau, comme le fait l'authentification de base. En fait, un système de hachage appelé MD5 et développé par RSA est mis en œuvre. (Pour plus d'informations, reportez-vous à l'article "The MD5 Message-Digest Algorithm" à l'adresse http://www.ietf.org/rfc/rfc1321.txt.) Bien que ce mode d'authentification soit exploitable en environnement Internet, les conditions requises au niveau du serveur et du client limitent sa généralisation. Contrairement à l'authentification de base et à l'instar de NTLM et Kerberos, IIS ne connecte pas l'utilisateur localement au serveur Web, interdisant toute délégation.

Scénarios d'utilisation classiques

Vous devez envisager l'authentification Digest dans les cas suivants :

  • Votre serveur Web exécute Windows 2000 et vos utilisateurs ont des comptes Windows stockés dans Active Directory.
  • Tous vos clients utilisent la plate-forme .NET ou Internet Explorer 5.x.
  • Vous avez besoin de coder les mots de passe de façon plus complexe que dans l'authentification de base.
  • Vous devez gérer l'authentification sur Internet.

Vous ne devez pas envisager l'authentification Digest dans les cas suivants :

  • Certains de vos clients utilisent des plates-formes autres que .NET ou Internet Explorer 5.0 (ou version supérieure).
  • Vos utilisateurs n'ont pas de comptes Windows dans Active Directory.
  • Vous avez besoin de recourir à la délégation.
Autres considérations

Vous devez également tenir compte des éléments suivants si vous choisissez l'authentification Digest.

Sécurisation de l'authentification Digest

L'objectif de l'authentification Digest est d'offrir un mode de connexion plus sûr que l'authentification de base. Cependant, elle n'est pas aussi sûre que l'authentification de base couplée avec SSL, NTLM, Kerberos, ou une authentification par certificat.

L'authentification Digest avec SSL est une solution fiable : toutefois les contraintes liées à son déploiement limitent sa généralisation.

Configuration spécifique de la plate-forme pour l'authentification Digest

L'authentification Digest nécessite que les clients utilisent .NET ou Internet Explorer 5.x. Les comptes d'utilisateur doivent être enregistrés dans Active Directory, configuré pour l'authentification Digest.

Mise en œuvre

Vous devez configurer IIS pour l'authentification Digest. Pour plus d'informations, reportez-vous vous à l'article Q222028 de la Base de connaissances Microsoft, "Setting Up Digest Authentication for Use with Internet Information Services 5.0" Lien non MSDN France Site en anglais.

Si votre application ASP.NET doit s'exécuter en tant qu'utilisateur authentifié par l'authentification Digest IIS, configurez le fichier Web.config comme suit :

// fichier web.config
<system.web>
<authentication mode="Windows" />
</system.web>

Pour utiliser l'authentification Digest dans Windows 2000, le serveur doit avoir accès à un serveur Active Directory configuré pour ce type d'authentification.

Pour plus d'informations sur l'authentification Digest, consultez la spécification RFC 2069 à l'adresse http://www.ietf.org/rfc/rfc2069.txt.

Authentification intégrée à Windows

L'authentification intégrée à Windows (Stimulation/Réponse NTLM ou Kerberos) suppose l'authentification d'un utilisateur ayant un compte Windows NT Domain ou Active Directory. Contrairement aux authentifications de base et Digest, le mot de passe crypté n'est pas envoyé sur le réseau, ce qui rend cette méthode très sûre. Si les services Active Directory sont installés sur le serveur et si le navigateur est compatible avec le protocole d'authentification Kerberos V5, ce dernier ainsi que le protocole Stimulation/Réponse sont utilisés ; sinon, seul le protocole Stimulation/Réponse est employé. Cette solution convient parfaitement à un environnement intranet, où les ordinateurs serveurs Web et les utilisateurs sont dans le même domaine, avec des administrateurs garantissant que chaque machine exécute Microsoft Internet Explorer version 3.01 ou ultérieure.

Scénarios d'utilisation classiques

Vous devez envisager l'authentification intégrée à Windows dans les cas suivants :

  • Vos utilisateurs ont des comptes Windows NT Domain ou Active Directory.
  • Votre application fonctionne sur un intranet (derrière un pare-feu).
  • Tous vos clients utilisent Internet Explorer version 3.01 ou ultérieure.
  • Vous devez recourir à la délégation (dans ce cas, Kerberos est obligatoire).
  • Vous avez besoin d'une procédure de connexion transparente pour les utilisateurs du domaine (par exemple sans affichage de boîte de dialogue pour la connexion).

Vous ne devez pas envisager l'authentification intégrée à Windows dans les cas suivants :

  • Vos comptes utilisateur sont stockés dans une base de données externe et non dans une base Windows NT Domain ou Active Directory.
  • Vous devez gérer l'authentification sur Internet.
  • Vos clients utilisent Netscape Navigator ou d'autres navigateurs non-Microsoft.
  • Vous devez obtenir le mot de passe en clair du client.
Autres considérations

Vous devez également tenir compte des éléments suivants si vous choisissez l'authentification intégrée à Windows.

Niveau de sécurité de NTLM et Kerberos

Ces deux protocoles sont jugés extrêmement sûrs. Avec NTLM et Kerberos, le mot de passe n'est pas envoyé sur le réseau. NTLM utilise un système de type Stimulation/Réponse. Kerberos est jugé plus sûr encore car il gère l'authentification mutuelle (c'est-à-dire que les clients peuvent vérifier le serveur avec lequel ils communiquent).

Problèmes de délégation

Le protocole NTLM ne gère pas la délégation. Une fois que les informations d'identification ont été transmises au serveur IIS, elles ne peuvent pas être transférées à un serveur dorsal pour authentification. Cependant, Kerberos accepte la délégation, ce qui permet de déléguer les informations d'identification du client à d'autres processus sur plusieurs ordinateurs situés en aval. Par exemple, vous pouvez utiliser Kerberos pour présenter les informations d'identification d'un utilisateur Web à un composant COM+ de niveau intermédiaire, jusqu'à une base de données Microsoft SQL Server™, configurée avec la sécurité intégrée Windows. L'authentification Kerberos n'est pas activée dans une configuration Active Directory par défaut. Assurez-vous que votre environnement prend en charge Kerberos si vous voulez choisir ce protocole avec l'intention d'utiliser la délégation.

Utilisation sur Internet

Ni NTLM ni Kerberos ne sont couramment utilisés sur Internet. Le principal problème en cas d'utilisation de Kerberos sur Internet vient de ce que l'autorité de sécurisation doit être centralisée et accessible à tous les utilisateurs. Pour ce faire, il faut que l'infrastructure nécessaire existe. En outre, ces protocoles ne sont pas pris en charge pas des navigateurs non-Microsoft, ce qui peut être un facteur restrictif, selon votre base de clients.

Performances et évolutivité

Kerberos est plus rapide que NTLM. Cependant, ni l'un ni l'autre n'est aussi rapide que l'authentification de base ou que certaines méthodes d'authentification personnalisées. Si vous prévoyez la connexion de nombreux utilisateurs simultanément, vous devez concevoir avec soin votre configuration Active Directory. Lorsque le nombre d'utilisateurs potentiel se compte par millions, envisagez de stocker leurs noms et mots de passe dans une base de données hautement performante, telle que SQL Server. Si vous déléguez le contexte de sécurité dans une application à plusieurs niveaux, vous risquez de rencontrer des problèmes d'évolutivité. En particulier, les solutions de niveau intermédiaire, comme les regroupements de connexion aux bases de données, ne sont pas utilisables.

Mise en œuvre

Pour mettre en œuvre une solution Kerberos ou NTLM, vous devez configurer IIS pour l'authentification intégrée à Windows. Si vous devez gérer des clients qui n'utilisent pas Internet Explorer, vous avez la possibilité de choisir l'authentification de base couplée avec NTLM ou Kerberos.

Lors de la configuration Kerberos, vous devez prendre en compte les éléments spécifiques ci-après :

  • Les ordinateurs clients et serveur doivent tous fonctionner avec Windows 2000 dans un domaine Windows 2000.
  • Le compte utilisateur du client doit être activé pour la délégation.
  • Le compte du service doit être activé pour la délégation.

Si votre application ASP.NET soit s'exécuter comme utilisateur authentifié par IIS avec l'authentification intégrée à Windows, configurez le fichier Web.config comme suit :

// fichier web.config
<system.web>
 <authentication mode="Windows" />
</system.web>

Pour plus d'informations sur l'utilisation de Kerberos, reportez-vous aux articles suivants :

Authentification par certificat

Un certificat est une "clé" numérique installée sur un ordinateur. Lorsque l'ordinateur tente d'accéder à un serveur, la clé est automatiquement présentée pour authentifier l'utilisateur. Il est possible de mapper des certificats clients sur des comptes Windows enregistrés dans un domaine ou dans Active Directory. Si vous utilisez le fournisseur d'authentification Windows dans ASP.NET, le thread d'application va s'exécuter en tant qu'utilisateur sur lequel le certificat est mappé. Vous pouvez aussi mettre en place une authentification personnalisée dans ASP .NET et, par exemple, utiliser l'adresse de messagerie (ou un champ unique) contenue dans le certificat. Du point du vue du client, la sécurité est transparente puisque le client n'a pas à se connecter via une page de connexion. Pour cette raison, l'emploi de certificats constitue une option intéressante pour les processus métier automatisés.

Scénarios d'utilisation classiques

Vous devez envisager l'authentification par certificat dans les cas suivants :

  • Les données que vous protégez sont stratégiques et une solution extrêmement sûre s'impose.
  • Vous avez besoin de recourir à l'authentification mutuelle.
  • Vous souhaitez confier à un tiers la gestion des relations entre le serveur et le détenteur du certificat.
  • Vous recherchez la transparence au niveau de l'interaction avec le client, par exemple dans le cas d'échanges BtoB automatisés.

Vous ne devez pas envisager l'authentification par certificat dans les cas suivants :

  • Le coût d'émission et de gestion des certificats clients est trop élevé par rapport à l'avantage obtenu.
Autres considérations

Vous devez également tenir compte des éléments suivants si vous choisissez l'authentification par certificat.

Déploiement

Vous devez physiquement déployer le certificat client sur le poste de travail client. Pour ce faire, il existe plusieurs méthodes, qui vont du déploiement Web à l'installation du certificat à partir d'un CD-ROM. Les problèmes liés au déploiement expliquent en général que le recours aux certificats ne soit pas aussi courant que les autres modes d'authentification utilisés conjointement avec SSL.

Mappage des certificats sur des comptes Windows

Il est possible de mapper des certificats sur des comptes Domain ou Active Directory. Pour authentifier des utilisateurs individuels, utilisez le mappage un-à-un, qui consiste à mapper un certificat sur un compte individuel. Avec le mappage Active Directory, il n'existe pas de limite à ce type de mappage.

Si vous devez authentifier tous les utilisateurs d'un groupe ou d'une organisation spécifique, vous pouvez utiliser le mappage plusieurs-à-un, dans lequel, par exemple, un certificat contenant le nom d'une entreprise commune est mappé sur un compte unique.

Ainsi, imaginez le scénario BtoB suivant :

  1. L'entreprise A autorise son partenaire, l'entreprise B, à consulter une partie de son site Web interne.
  2. Un certificat est installé sur les ordinateurs de l'entreprise B.
  3. Le mappage plusieurs-à-un permet que l'application ASP.NET s'exécute comme compte Windows générique "CompanyB".

Pour obtenir plus d'informations sur les certificats, consultez l'ouvrage "Designing Secure Web-Based Applications for Microsoft Windows 2000" par Michael Howard.

Mise en œuvre

Vous devez configurer IIS pour l'authentification par certificat. Pour plus d'informations sur le mappage de certificats à clé publique sur des comptes utilisateur Windows 2000, reportez-vous à l'article " Step-by-Step Guide to Mapping Certificates to User Accounts" Lien non MSDN France Site en anglais.

Authentification avec Passport

L'authentification avec Passport est un service centralisé proposé par Microsoft. Lorsque vous utilisez Passport, vous n'avez pas besoin de mettre en œuvre votre propre code d'authentification, la page de connexion, ou, dans certains cas, la table des utilisateurs. Passport utilise les cookies. Si des clients ont déjà été authentifiés par Passport, ils ont accès à votre site. Dans le cas contraire, ils sont automatiquement redirigés vers le site Passport pour authentification.

Passport constitue une bonne solution si vous souhaitez mettre en place un processus de connexion unique sur plusieurs domaines qui prennent en charge aussi Passport. Passport offre des services complémentaires en plus de l'authentification, notamment la gestion de profils et des services d'achat.

Sur la plate-forme Windows 2000, il n'y a pas d'intégration directe de Passport avec les éventuels mécanismes d'authentification et d'autorisation relevant du système d'exploitation. Alors que .NET Framework vérifie s'il existe des cookies Passport, si vous gérez votre propre base utilisateurs, vous devez mettre en œuvre un code spécifique pour mapper l'utilisateur Passport sur votre utilisateur, ainsi qu'un dispositif d'autorisation propre.

Scénarios d'utilisation classiques

Vous devez envisager l'authentification avec Passport dans les cas suivants :

  • Votre site va être utilisé conjointement avec d'autres sites exploitant Passport et vous souhaitez offrir une connexion unique aux utilisateurs qui doivent y accéder.
  • Vous ne voulez pas gérer de base de données des noms et mots de passe utilisateur.

Vous ne devez pas envisager l'authentification avec Passport dans les cas suivants :

  • Vous voulez utiliser les noms d'utilisateur et les mots de passe déjà stockés dans votre base de données ou dans Active Directory. (Bien que, en écrivant un code supplémentaire, vous puissiez mapper un ID Passport sur un compte utilisateur.)
  • Vos clients sont d'autres ordinateurs qui accèdent au site par programmation.
Autres considérations

Vous devez également tenir compte des éléments suivants si vous choisissez l'authentification avec Passport.

Activation de Passport

Pour utiliser l'authentification par Passport, il convient d'inscrire le site avec le service Passport et d'installer le SDK Passport sur le serveur.

Délégation

Sur Windows 2000, il est impossible de déléguer les informations d'identification sécurisées par Passport d'un utilisateur d'un serveur à un autre.

Mappage sur des comptes utilisateur

L'ID utilisateur Passport (PUID) est uniquement une identité. Si vos comptes utilisateur sont définis dans Active Directory ou dans une base personnalisée et si vous devez mapper le PUID sur un utilisateur, implémentez votre propre code personnalisé. Les futures versions de Windows devraient offrir une prise en charge native du mappage des PUID sur des comptes Windows.

Sécurisation du mécanisme Passport

Le cryptage des cookies fait de Passport un moyen sûr lorsqu'il est utilisé comme méthode d'authentification indépendante. Cependant, pour éviter les attaques replay et assurer la meilleure sécurité possible, utilisez Passport en association avec SSL.

Mise en œuvre

Pour mettre en œuvre Passport, vous devez installer le SDK Passport sur le serveur. Vous devez également vous enregistrer auprès de Passport afin d'utiliser le service. Configurez le fichier web.config comme suit :

// fichier web.config
<system.web>
 <authentication mode="Passport" />
</system.web>

Pour plus d'informations sur le service Passport, reportez-vous aux documents anglais suivants :

Authentification par formulaire

L'authentification par formulaire fait référence à un composant personnalisé d'interface utilisateur, qui accepte les informations d'identification de l'utilisateur, par exemple un nom et un mot de passe. Bon nombre d'applications Internet actuelles proposent ce genre de formulaires pour établir une connexion. Le formulaire en lui-même n'effectue pas l'authentification, il sert uniquement à obtenir les informations d'identification de l'utilisateur. Pour permettre l'authentification, l'accès à la base de données des noms et mots de passe d'utilisateur via un code personnalisé est nécessaire.

Lorsque l'utilisateur est authentifié, le serveur fournit au client un moyen d'indiquer, lors des requêtes suivantes, qu'il a déjà été authentifié. Si nécessaire, vous pouvez obliger le client à procéder à une authentification à chaque requête, bien que cette solution affecte les performances et l'évolutivité. Il existe deux approches possibles pour identifier un client qui s'est connecté :

  • Les cookies. Un cookie est un élément d'information initialement présenté par le serveur au client. Ensuite, le client le représente au serveur dans chaque requête HTTP. Ceci permet de savoir si le client a déjà été authentifié. ASP.NET permet l'utilisation des cookies en vue d'une authentification par formulaire dans le module CookieAuthenticationProvider. Les cookies sont reconnus par la plupart des navigateurs Web, y compris Internet Explorer et Netscape Navigator.
  • Solution personnalisée. Vous pouvez aussi développer un mécanisme personnalisé pour identifier le client auprès du serveur. Si vos clients ont désactivé les cookies, stockez un identificateur unique dans chaque chaîne de requête URL. Vous pouvez aussi utiliser des champs de formulaire cachés qui sont enregistrés dans un cadre permanent invisible ou de premier niveau. Dans les deux cas, vous devez vous assurer qu'aucun pirate ne pourra, par programmation, faire croire à votre application qu'il est authentifié.

Les cookies sont largement utilisés par les sites Web qui appliquent l'authentification par formulaire. La version initiale de .NET ne prendra en charge que l'authentification par formulaire utilisant des cookies.

Scénarios d'utilisation classiques

Vous devez envisager l'authentification par formulaire dans les cas suivants :

  • Les noms d'utilisateur et les mots de passe sont stockés ailleurs que dans des comptes Windows. Remarquez qu'il est possible d'utiliser l'authentification par formulaire avec des comptes Windows.
  • Vous déployez votre application sur Internet.
  • Vous devez prendre en charge tous les navigateurs et systèmes d'exploitation des clients.
  • Vous voulez proposer votre propre formulaire d'interface comme page de connexion.

Vous ne devez pas envisager l'authentification par formulaire dans les cas suivants :

  • Vous déployez une application sur un intranet d'entreprise et vous pouvez tirer parti de l'authentification intégrée à Windows.
  • Il vous est impossible de prévoir un accès par programmation pour vérifier le nom et le mot de passe des utilisateurs.
Autres considérations

Vous devez également tenir compte des éléments suivants si vous choisissez l'authentification par formulaire.

Sécurisation de l'authentification par formulaire

Si les utilisateurs entrent des mots de passe via la page de connexion, sécurisez le canal à l'aide de SSL pour éviter qu'ils ne soient détournés. Si vous utilisez des cookies pour gérer l'identité de l'utilisateur entre les requêtes, n'oubliez pas qu'il existe un risque qu'un pirate "détourne" le cookie de l'utilisateur en utilisant un programme de surveillance de réseau. La seule manière de rendre le site entièrement sécurisé en cas d'utilisation de cookies est d'utiliser SSL pour toutes les communications avec le site. Pour la plupart des sites de commerce, cette option est irréalisable en raison de l'impact important sur les performances. Avec ASP.NET, vous pouvez faire en sorte que le serveur régénère les cookies à intervalles réguliers. Cette stratégie, qui introduit la notion de durée de validité des cookies, a pour but d'éviter qu'un autre utilisateur n'accède au site avec un cookie volé.

Performances et évolutivité

Lorsque vous concevez un site Web volumineux, vous devez tenir compte de l'impact que l'authentification des utilisateurs exerce sur les performances. Si vous prévoyez la connexion de très nombreux utilisateurs à la fois, la vérification des informations d'identification doit être aussi rapide que possible.

L'utilisation de SSL affecte de façon notable les performances en raison des étapes supplémentaires de cryptage qui sont requises. Il peut s'avérer nécessaire de séparer les serveurs qui assurent la connexion sécurisée des serveurs de contenus regroupés dans une ferme Web afin de maintenir le niveau de performances requis.

Vérification de l'existence de cookies

Si vous utilisez .NET, la vérification de l'existence d'un cookie se déroule automatiquement. Cependant, en dehors de .NET, deux approches sont possibles :

  • Vous pouvez mettre en œuvre un filtre ISAPI confirmant la présence d'un cookie dans la requête d'un client, ce qui prouve que le client a été authentifié. Si le cookie existe, vous autorisez le traitement de la requête. Si le cookie n'existe pas, vous redirigez le client vers la page de connexion. Un filtre ISAPI conforme à cette description est implémenté par Microsoft® Commerce Server 2000.
  • Vous pouvez écrire un code au début de chaque page Web qui contrôle l'existence du cookie ou de toute autre valeur personnalisée transmise par la page Web. Si le jeton est absent, le code peut rediriger l'utilisateur vers la page de connexion. Il s'agit d'une implémentation simple ; toutefois, vous risquez de ne pas pouvoir protéger d'autres ressources que les pages ASP. Par exemple, les fichiers image restent toujours accessibles.

Si vous utilisez ASP.NET, exploitez éventuellement la fonction intégrée fournie par l'authentification par formulaire.

Utilisation de l'authentification par formulaire avec des comptes Windows

Si vous déployez une application Internet et si vos utilisateurs possèdent des comptes Windows sur le serveur, il est possible d'adopter l'authentification par formulaire, simple ou avec SSL, à la place de l'authentification de base ou Digest.

Mais cette solution n'est peut-être pas idéale si votre application fonctionne sur un intranet et utilise déjà l'authentification intégrée à Windows. Par ailleurs, la politique de sécurité de votre entreprise risque de désapprouver le fait que des utilisateurs entrent leur mot de passe dans un formulaire HTML.

Mise en œuvre

Pour mettre en œuvre l'authentification par formulaire, vous devez créer votre propre page de connexion et rediriger l'URL pour les clients non authentifiés. Vous devez aussi créer votre propre schéma de recherche des comptes. Avec ASP.NET, vous pouvez configurer le fichier Web.config comme suit :

// fichier web.config
<system.web>
 <authentication mode="Forms" />
</system.web>

Puisque vous implémentez votre propre authentification, vous configurez généralement IIS pour une authentification anonyme.

Pour plus d'informations sur la mise en œuvre de SSL, reportez-vous aux articles suivants :

Cookies

Un cookie est une petit fichier texte placé sur votre disque dur par un serveur Web. Son but principal est de permettre au serveur d'identifier un client qui s'est déjà connecté. Vous pouvez utiliser les cookies avec ou sans système d'authentification. Considérez les scénarios d'utilisation suivants :

  • Utilisation en association avec l'authentification par formulaire. Le serveur associe au client un cookie au moment de l'authentification, puis les requêtes suivantes font l'objet d'une vérification sur la base du cookie présenté au serveur.
  • Utilisation en vue d'une personnalisation ; dans ce cas, un contenu personnalisé est fourni à l'utilisateur.

ASP.NET propose un mécanisme pour créer des cookies et vérifie automatiquement s'ils existent dans les requêtes des clients. Il est éventuellement possible de crypter les cookies créés par ASP.NET en utilisant un schéma de codage DES triple, pris en charge par .NET Framework. Vous pouvez aussi implémenter vous-même un fournisseur de cookies et l'utiliser avec l'authentification par formulaire.

Pour plus d'informations sur les cookies, reportez-vous à "Information About Cookies" Lien non MSDN France Site en anglais.

Autres considérations

Selon le type de navigateur, il se peut que des limites de taille soient applicables. La spécification RFC 2019 fait état d'une limite de 4 Ko. Internet Explorer 5 n'impose pas de limite de taille. Pour que les cookies fonctionnent correctement avec les navigateurs, les paramètres de sécurité de ces derniers doivent avoir été configurés.

Sécurité des services Web

Un service Web est une application basée sur l'infrastructure ASP.NET, qu'il est possible d'appeler sur Internet par programmation. Du point de vue de la sécurité, les mêmes problèmes se posent que pour le développement d'un site Web interactif. De plus, pour sécuriser un site Web, vous utilisez les mêmes mécanismes que pour n'importe quelle autre ressource ASP.NET (comme les fournisseurs d'authentification IIS et ASP .NET). Cependant, les facteurs supplémentaires suivants sont à prendre en compte :

  • Interaction des clients. Il se peut que votre service Web n'ait pas à faire à des utilisateurs interactifs qui se connectent et entrent leurs informations d'identification, vos "utilisateurs" étant en fait des applications.
  • Sécurité au niveau méthode. Vous devrez peut-être accorder aux utilisateurs des autorisations qui restreignent l'utilisation de certaines méthodes. Vous procéderez alors comme pour les composants COM+.
  • Délégation. Votre service Web devra parfois appeler d'autres services et gérer le contexte de sécurité de l'appelant d'origine.

Authentification pour un service Web

Les services Web ont à valider, d'une manière ou d'une autre, les informations d'identification des utilisateurs. Si le service n'est pas interactif, il doit obtenir le jeton de sécurité de l'appelant, ou exposer les méthodes appropriées pour permettre la présentation des informations d'identification. Les méthodes d'authentification suivantes, facilement utilisables, n'exigent pas l'identification des utilisateurs, ce qui les rend particulièrement adaptées à des services Web programmables :

  • Authentification de base, Digest, et intégrée à Windows
  • Authentification par mappage de certificats
  • Authentification personnalisée ou spécifique de l'application

Éventuellement, vous pouvez aussi utiliser :

  • La sécurité IPSec (Internet Protocol Security)
  • Passport
Utilisation des comptes Windows et de l'authentification IIS

Les mêmes aspects que ceux évoqués dans la section Méthodes d'authentification de cet article sont à prendre en considération. Cette solution n'exige qu'un minimum de code personnalisé et vous pouvez autoriser l'accès à d'autres ressources à l'aide des listes ACL Windows.

Utilisation de certificats et mappage de certificats

En cas d'authentification par certificat, l'interaction entre le client et le serveur peut être transparente, ce qui signifie que le client n'a pas à fournir, par voie de programme, le nom d'utilisateur et le mot de passe. En outre, il s'agit d'un mécanisme parfaitement sécurisé. Les transactions BtoB, telles que le passage de commandes, offrent un contexte idéal pour l'utilisation des certificats. Si vous utilisez le mappage des certificats pour obtenir des comptes utilisateur Windows, vous pouvez aussi définir des listes de contrôle d'accès (ACL) pour autoriser l'accès aux ressources.

Authentification personnalisée

Vous avez toujours la possibilité de mettre en place des solutions d'authentification personnalisées. Dans ce cas, il n'est plus nécessaire de recourir à des applications pour gérer des comptes utilisateur Windows séparés, ce qui est un avantage par rapport à l'authentification intégrée à Windows. Vous pouvez aussi incorporer votre propre méthode dans le code du service Web et l'optimiser en fonction des besoins spécifiques de l'application.

Les solutions d'authentification personnalisée possibles pour des services Web incluent :

  • Accepter un nom d'utilisateur et un mot de passe comme paramètre dans vos appels de méthodes.
  • Fournir une méthode de connexion qu'il faut appeler avant tout autre méthode. Vous pouvez utiliser la fonctionnalité des cookies de Microsoft .NET Framework pour vérifier que des appels à la méthode de connexion ont eu lieu.
  • Utiliser les éléments SOAP Header (en-tête) ou Body (corps) pour stocker les informations d'identification.
  • Créer un en-tête ou un corps HTTP personnalisé pour y stocker les informations d'identification.
La sécurité IPSec (Internet Protocol Security)

Si vous connaissez l'adresse IP de l'ordinateur client, par exemple si le client est un serveur Web qui appelle une logique métier encapsulée dans des services Web de niveau intermédiaire, la sécurité IPSec (Internet Protocol Security) peut s'avérer intéressante. Cette méthode vous permet de limiter le nombre d'ordinateurs qui se connectent à votre service Web en fonction de leur adresse IP.

Toutefois, cette approche n'est pas viable dans un environnement Internet, lorsque vous ne connaissez pas à l'avance les adresses IP de votre client.

Pour plus d'informations sur IPSec, reportez-vous à l'article MSDN intitulé " IP sécurisé pour Microsoft Windows 2000 Server" Lien non MSDN France Site en anglais.

Utilisation de Passport avec des services Web

Dans certains cas, l'authentification par Passport est applicable à un service Web. Cependant, son utilisation peut être limitée en raison de la nécessité de rediriger des clients non authentifiés vers le site Passport. La redirection peut provoquer des problèmes pour les clients non-interactifs, à moins qu'ils ne soient spécialement programmés pour gérer le processus de redirection sur le serveur Passport.

Autorisation

Après avoir authentifié l'utilisateur, vous pouvez au besoin l'autoriser à accéder au service Web. Il existe plusieurs options d'autorisation :

  • Utilisation des listes ACL de Windows
  • Utilisation de l'autorisation URL
  • Utilisation des objets Principal (entité) .NET
Utilisation des listes ACL de Windows

Avec les listes ACL de Windows, vous pouvez créer des autorisations système sur des fichiers d'application spécifiques. Cette solution fonctionne si votre service Web authentifie des utilisateurs par rapport à des comptes Windows et utilise l'emprunt d'identité.

Utilisation de l'autorisation URL

Le module URLAuthorizationModule mappe des utilisateurs et des rôles sur des éléments dans l'espace de noms URI.Ce module met en œuvre des formulations d'autorisation aussi bien positives que négatives. En pratique, il est utilisable pour autoriser ou empêcher, de façon sélective et pour certains utilisateurs, l'accès à des éléments arbitraires de l'espace de noms (namespace) URI en se basant par exemple sur leur appartenance à un rôle. L'exemple suivant accorde un accès à plusieurs utilisateurs de domaine et le refuse à toute autre personne.

<configuration>
   <system.web>
         <authentication mode="Windows" />
          <authorization>
              <allow users="domain1\user, domain2\user2, domain1\user3 />
              <deny users="*" />
          </authorization>
    </system.web>
</configuration>

Objet Principal de Windows

L'espace de noms System.Security.Principal de la bibliothèque de classe .NET Framework (BCL) propose un objet WindowsPrincipal pour représenter le contexte de sécurité sous lequel le code s'exécute. Cet objet est créé automatiquement lorsque vous utilisez l'authentification Windows dans IIS. Il permet de vérifier l'appartenance à un groupe Windows d'un utilisateur Windows et limite les accès en conséquence.

Objet Principal générique

Il est possible de créer un objet Principal générique sur la base de vos rôles personnalisés. Vous pouvez l'utiliser lorsque vous disposez de votre propre base de données utilisateur/rôle. L'objet Principal reçoit son contenu dans l'événement OnAuthenticate. Vous pouvez avoir une table personnalisée mappée sur des comptes Windows que vous mettez en correspondance dans cet événement. Dans tous les cas, vous pouvez créer un objet Principal personnalisé pour cet utilisateur particulier.

Pour les utilisateurs récurrents qui ont déjà été authentifiés, recréez l'objet Principal à l'aide d'un cookie.

Rôles et sécurité au niveau méthode

Il est parfois nécessaire d'instaurer la sécurité au niveau méthode afin de limiter, pour des objets Principal clients, les appels à certaines méthodes. Il y a plusieurs façons de procéder.

Si vous utilisez des comptes Windows, créez des rôles pour vos utilisateurs sous la forme de groupes Windows. Étant donné que le thread ASP emprunte l'identité du client et que vous disposez d'un objet Windows Principal, utilisez les solutions suivantes :

  • Créez des listes ACL sur des ressources protégées auxquelles accède le thread ASP.NET.
  • Appelez la méthode IsInRole sur l'objet WindowsPrincipal à partir de chaque méthode afin de vérifier que l'appelant possède les autorisations adéquates. Vous pouvez aussi insérer dans le code une instruction logique qui appelle une sous-routine particulière selon que le client appartient à tel ou tel groupe.

Si vous utilisez un objet Generic Principal créé à partir d'utilisateurs et de rôles figurant dans une base de données personnalisée :

  • Vous pouvez contrôler l'appartenance à un rôle par le biais de la programmation, en appelant la méthode IsInRole sur l'objet Principal de la même façon qu'avec l'objet Windows Principal décrit plus haut.

Si vous n'utilisez pas d'objet Principal, vous disposez d'autres options, notamment :

  • Accepter les informations d'identification de l'utilisateur comme paramètres dans l'appel de méthode et effectuer une recherche.
  • Vérifier l'existence d'un cookie au tout début de l'appel de méthode.
  • Créer une méthode de connexion qui renvoie une valeur clé personnalisée, les méthodes suivantes acceptant cette valeur comme paramètre. Ce processus est similaire à l'utilisation des cookies gérés par les navigateurs ; néanmoins, il peut aussi être utilisé lorsque les cookies ne sont pas pris en charge par le client.

Délégation

Concernant la délégation, les questions qui se posent pour les services Web sont les mêmes que pour les sites Web ASP.NET. Pour déléguer le contexte de sécurité à un service Web, vous devez utiliser l'authentification Kerberos, ou transmettre les informations d'identification afin que les services Web s'exécutant sur d'autres ordinateurs puissent appeler la méthode LogonUser s'il s'agit de serveurs Windows, ou l'API d'authentification équivalente s'ils ne sont pas des serveurs Windows.

Accès du client

En cas de connexion à un service Web par programmation, vous pouvez tirer parti des classes .NET pour assurer la connectivité au niveau du client. Les protocoles d'authentification pris en charge par les clients .NET clients sont :

  • Authentification de base
  • Authentification Digest
  • Authentification intégrée à Windows (NTLM et Kerberos)
  • Authentification par certificats
  • Authentification personnalisée

Système CAS (Code Access Security)

Pour protéger les systèmes informatiques contre l'intrusion nuisible de programmes et permettre à un code "portable" de s'exécuter en toute sécurité, .NET Framework propose un mécanisme appelé Code Access Security (CAS). Bien qu'il s'agisse d'une fonction de sécurité .NET, elle s'applique à tous les codes gérés .NET, tels que des applications Web ASP .NET. Malgré cela, vous pouvez toujours écrire un code spécifique lorsque :

  • Vous concevez des contrôles hébergés par des navigateurs.
  • Vous hébergez des applications tierces.
  • Vous hébergez des assembly de différents fournisseurs sur un serveur partagé.
  • Vous souhaitez interdire à certains assembly des fonctions natives, comme les API d'écriture de fichier.

La sécurité CAS permet de sécuriser le code à des degrés divers, en fonction de la politique sécuritaire de l'entreprise, de la provenance du code et d'autres aspects liés à son identité, tel que son nom d'assembly "robuste". Ce système de sécurité minimise le risque d'utilisation abusive de votre code par un autre. Il vous permet de définir spécifiquement les opérations que votre code a le droit d'exécuter ainsi que celles qui lui sont totalement interdites. Notamment, la sécurité CAS offre un système de gestion d'autorisation selon lequel le code peut explicitement demander des autorisations particulières et explicitement en refuser d'autres dont il sait qu'il n'en a pas besoin.

Autorisations d'accès pour le code

La sécurité CAS s'appuie sur la notion d'autorisations d'accès accordées au code. Chaque autorisation correspond au droit pour le code d'accéder à une ressource protégée, par exemple un fichier, un répertoire ou une entrée de registre, ou le droit qu'il a d'exécuter une opération protégée telle que l'appel à un code non géré. Le code peut réclamer des autorisations et la politique de sécurité du runtime détermine les autorisations à accorder. Pour obtenir la liste complète des autorisations, reportez-vous à la section Code Access Permissions Lien non MSDN France Site en anglais.

.NET permet aux administrateurs d'assigner à une application un ensemble prédéfini d'autorisations. Ces ensembles varient en fonction du niveau de confiance accordée à l'application. Par défaut, les applications reçoivent un niveau de confiance qui dépend des "preuves" présentées au niveau de la signature numérique du code, de son origine et de l'emplacement de l'application.

Par exemple, des applications s'exécutant sur un partage UNC (dans la zone de sécurité Intranet) reçoivent le jeu d'autorisations LocalIntranet. Les applications s'exécutant sur la machine locale (dans la zone de sécurité MyComputer) reçoivent l'ensemble FullTrust.

Pour une configuration plus sophistiquée, il est possible d'attribuer aux applications Web ASP.NET des niveaux de confiance. Les niveaux sont définis dans le fichier de configuration, à l'aide de l'élément <trust>.

<trust level="Full | High | Low | None" originUrl="url" />

Chaque niveau détermine les autorisations de l'application, lesquelles sont détaillées dans un fichier XML décrivant la politique de sécurité applicable. Chaque niveau peut être mappé sur un fichier spécifique. Les mappages par défaut pour ASP.NET sont :

  • High : mappage sur web_hightrust.config
    Ce niveau correspond à des autorisations qui accordent aux applications un accès en lecture/écriture au répertoire de l'application (soumis aux autorisations du système d'exploitation) et qui leur permet de remplacer l'objet Principal (entité) de l'authentification. Il restreint par ailleurs le droit des applications à appeler du code non géré.
  • Low : mappage sur web_lowtrust.config
    Ce niveau permet aux applications de lire les données du répertoire d'application et offre une connectivité réseau limitée. Les applications peuvent se reconnecter à leur site hôte, en supposant que l'attribut originUrl de l'élément <trust> soit correctement configuré.
  • None : mappage sur web_notrust.config
    Ce niveau fournit l'autorisation d'exécution de base et permet à l'application d'utiliser le stockage protégé (mécanisme qui permet d'associer le code aux données sauvegardées en toute sécurité).

Notez que le niveau de confiance Full n'est associé à aucun fichier de configuration, puisqu'il autorise les applications à utiliser toutes les ressources (en fonction des autorisations du système d'exploitation), ce qui revient à une exécution sans sécurité CAS (bien que le système CAS ne puisse pas être désactivé pour le code géré). Vous pouvez modifier ces mappages dans l'élément <securityPolicy> du fichier de configuration et personnaliser ou enrichir chaque niveau. Vous pouvez aussi créer vos propres niveaux pour définir des groupes d'autorisation arbitraires. Le mappage par défaut <securityPolicy> est indiqué ci-après.

<securityPolicy>
 <trustLevel name="Full" policyFile="internal" />
 <trustLevel name="High" policyFile="web_hightrust.config" />
 <trustLevel name="Low" policyFile="web_lowtrust.config" />
 <trustLevel name="None" policyFile="web_notrust.config" />
</securityPolicy>

Verrouillage des paramètres de configuration

La configuration ASP.NET est hiérarchique par nature avec, éventuellement, des fichiers de configuration aux niveaux machine, application et sous-application. Les fichiers de configuration de second niveau sont utilisables pour modifier les paramètres définis à un niveau supérieur, ou pour ajouter des informations de configuration. Bien que cette possibilité autorise un grand degré de flexibilité, les administrateurs préfèrent parfois imposer les paramètres de configuration et refusent qu'ils soient modifiés par des applications spécifiques. Ainsi, l'administrateur d'un site Web hébergé peut spécifier le niveau de sécurité d'accès du code et interdire aux applications de le modifier. Pour ce faire, il utilisera l'élément <location> associé à l'attribut allowOverride.

Supposons par exemple qu'un administrateur de site Web hébergé souhaite interdire à toutes les applications l'appel à un code non géré. L'extrait suivant d'un fichier de configuration montre comment l'administrateur peut verrouiller les paramètres de configuration d'accès du code pour tout un site et limiter les applications avec le niveau de confiance High (lequel interdit tout appel à un code non géré) :

<location path="somesitepath" allowOverride="false">
 <trust level="high" originUrl="http://somesite.com" />
</location>

L'attribut path peut faire référence à un site ou à un répertoire virtuel et il s'applique au répertoire nommé et à tous les sous-répertoires. Dans l'exemple précédent, si vous définissez allowOverride à "false", vous empêcher les applications du site de modifier les paramètres de configuration spécifiés dans l'élément <location>. La possibilité de verrouiller les paramètres de configuration s'applique à tous les paramètres, et pas seulement aux paramètres de sécurité tels que les niveaux de confiance.

Pour plus d'informations, reportez-vous aux documents suivants :

Sécurité des canaux

Les canaux transportent des messages au-delà des limites d'une machine, par exemple vers d'autres domaines d'applications, processus ou ordinateurs. .NET Framework fournit deux canaux pour le transport à distance, HTTP et TCP.

Vous devez envisager la sécurisation d'un canal Remoting lorsque vous voulez protéger des données confidentielles ou stratégiques qui sont transmises via ces protocoles. En effet, à l'aide d'un logiciel de surveillance du réseau, ces informations peuvent facilement être interceptées et lues, à moins qu'elles ne soient cryptées.

Voici quelques éléments importants concernant la sécurité des canaux :

  • Le canal HTTP utilisé dans IIS avec ASP.NET gère la transmission et la réception de données sécurisées avec SSL. SSL est le système le plus courant pour configurer un canal d'échanges sécurisé et il peut être configuré dans IIS.
  • Si vous voulez utiliser un canal non sécurisé tel que HTTP/Port 80 ou TCP, vous pouvez toujours crypter les données manuellement à l'aide de l'API de cryptographie.
  • Il est possible de mettre en œuvre un dispositif de sécurité des canaux sous la couche transport. Dans Windows 2000, vous pouvez adopter la sécurité IPSec (Internet Protocol Security) pour sécuriser la transmission des données tout en étant transparent par rapport à l'application.
  • Si vous utilisez ASP.NET avec des composants COM ou DCOM et si vous utilisez DCOM comme protocole Remoting, pensez au niveau d'authentification DCOM Packet Privacy pour crypter vos transmissions DCOM.

Pour plus d'informations, reportez-vous aux documents suivants :

Informations complémentaires

Pour de plus amples informations sur les questions de sécurité abordées dans cet article, consultez les documents suivants :

Pour plus d'informations sur la sécurisation des services Web, consultez les références suivantes :

Pour des informations générales sur la sécurité, reportez-vous à :

ANNEXE A

http://msdn.microsoft.com/fr-fr/library/ms978378.authaspdotnet03(l=fr-fr).gif figure 1. Diagramme


figure 3. Diagramme permettant de déterminer la méthode d'authentification la plus appropriée (cliquez sur l'image pour l'agrandir)

Collaborateurs

Merci aux réviseurs et à tous ceux qui ont permis la rédaction de cet article, notamment :

Rob Howard, Erik Olson, Venkat Chilakala, Michael Monteiro (Sapient), Suresh Kandula (Sapient), Chris Brooks, Edward Jezierski, Alex Mackman, Mike Jenne, David Mowers, Amitabh Srivastava, Steve Busby, Kenny Jones.



Dernière mise à jour le lundi 12 novembre 2001



Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2015 Microsoft