Emprunt d'identité ASP.NET
Mise à jour : novembre 2007
Lors de l'utilisation de l'emprunt d'identité, les applications ASP.NET peuvent s'exécuter avec l'identité Windows (compte d'utilisateur) de l'utilisateur qui fait la requête. L'emprunt d'identité est utilisé couramment dans les applications qui s'appuient sur Microsoft Internet Information Services (IIS) pour authentifier l'utilisateur.
L'emprunt d'identité ASP.NET est désactivé par défaut. Si l'emprunt d'identité est activé pour une application ASP.NET donnée, celle-ci s'exécute dans le contexte de l'identité dont le jeton d'accès passé par IIS à ASP.NET. Ce jeton peut être un jeton utilisateur authentifié, tel qu'un jeton pour un utilisateur Windows connecté, ou le jeton fourni par IIS aux utilisateurs anonymes (en général, l'identité IUSR_MACHINENAME).
Lorsque l'emprunt d'identité est activé, seul votre code d'application s'exécute sous le contexte de l'utilisateur représenté. Les applications sont compilées et les informations de configuration sont chargées à l'aide de l'identité du processus ASP.NET. Pour plus d'informations, consultez Configuration de l'identité de processus ASP.NET. L'application compilée est mise dans le répertoire de fichiers Temporary ASP.NET. L'identité de l'application représentée a besoin d'avoir un accès en lecture/écriture à ce répertoire. L'identité de l'application représentée requiert aussi au moins l'accès en lecture aux fichiers du répertoire et des sous-répertoires de votre application. Pour plus d'informations, consultez Listes de contrôle d'accès requis par ASP.NET.
.gif "Remarque") Remarque : |
|---|
Comme ASP.NET utilise l'identité Windows du processus ASP.NET lors de la compilation des applications et du chargement des informations de configuration, le code de l'application et les informations de configuration doivent rester privés d'une application à l'autre sur un serveur hébergeant plusieurs applications. Sous Windows Server 2003, vous pouvez créer plusieurs pools d'applications et spécifier une identité unique pour chaque pool d'applications. Vous pouvez restreindre ensuite l'accès aux fichiers d'application à l'aide des listes de contrôle d'accès (ACL) (si le système de fichiers est formaté NTFS) et de ces identités. Par exemple, imaginons deux applications, App1 et App2, où les informations de chaque application doivent demeurer privées. Vous pouvez placer App1 dans le pool d'applications ApplicationPool1 qui a l'identité ID_ApplicationPool1. Vous pouvez placer App2 dans le pool d'applications ApplicationPool2 qui a l'identité ID_ApplicationPool2. Le compte ID_ApplicationPool1 peut accéder aux fichiers d'App1, mais se voit refuser l'accès aux fichiers d'App2. ID_ApplicationPool2 peut accéder aux fichiers d'App2, mais se voit refuser l'accès aux fichiers d'App1. Notez que vous ne pouvez pas effectuer cette séparation sous Windows 2000 ou Windows XP Professionnel, parce que, sous ces systèmes d'exploitation, l'identité de processus de toutes les applications ASP.NET est une identité unique. |
Vous contrôlez l'emprunt d'identité à l'aide de l'élément de configuration identity. Comme pour d'autres directives de configuration, celle-ci s'applique de façon hiérarchique. Un fichier de configuration minimale permettant d'activer l'emprunt d'identité pour une application peut s'apparenter à l'exemple suivant :
<configuration>
<system.web>
<identity impersonate="true"/>
</system.web>
</configuration>
Vous pouvez aussi ajouter la prise en charge des noms spécifiques pour exécuter une application comme identité configurable, comme illustré dans l'exemple suivant :
<identity impersonate="true"
userName="contoso\Jane"
password="********" />
Remplacez la valeur répertoriée dans l'exemple précédent par le mot de passe correct.
| Remarque : |
|---|
Dans l'exemple précédent, le nom d'utilisateur et le mot de passe sont stockés en texte clair dans le fichier de configuration. Pour améliorer la sécurité de votre application, il est recommandé que vous restreigniez l'accès à votre fichier Web.config à l'aide d'une liste de contrôle d'accès et que vous chiffriez l'élément de configuration identity de votre fichier Web.config à l'aide de la configuration protégée. Pour plus d'informations, consultez Chiffrement des informations de configuration à l'aide de la configuration protégée. |
La configuration illustrée dans l'exemple permet à l'application complète de s'exécuter à l'aide de l'identité contoso\Jane, indépendamment de l'identité de la requête. Ce type d'emprunt d'identité peut être délégué à un autre ordinateur. Autrement dit, si vous spécifiez le nom d'utilisateur et le mot de passe de l'utilisateur représenté, vous pouvez vous connecter à un autre ordinateur du réseau et demander des ressources (fichiers ou accès à SQL Server) utilisant la sécurité intégrée. Si vous activez l'emprunt d'identité et ne spécifiez pas de compte de domaine comme identité, vous ne serez pas en mesure de vous connecter à un autre ordinateur du réseau, à moins que votre application IIS ne soit configurée pour utiliser l'authentification de base.
| Remarque : |
|---|
Sous Windows 2000, il n'est pas possible d'emprunter une identité à l'aide d'informations d'identification utilisateur spécifiques pour l'identité du processus de travail ASP.NET. Cependant, vous pouvez activer l'emprunt d'identité sans informations d'identification utilisateur spécifiques afin que votre application emprunte l'identité déterminée par IIS. Pour plus d'informations, consultez l'article 810204, « Problème par demande emprunt d'identité ne fonctionne pas sur Windows 2000 avec ASP.NET », dans la Base de connaissances Microsoft, à l'adresse https://www.microsoft.com/france/support. |
Lecture de l'identité empruntée
L'exemple de code suivant montre comment lire par programme l'identité de l'utilisateur représenté :
Dim username As String = _
System.Security.Principal.WindowsIdentity.GetCurrent().Name
String username =
System.Security.Principal.WindowsIdentity.GetCurrent().Name;