Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Remarque
Cet article s’applique à Windows.
Pour plus d’informations sur ASP.NET Core, consultez Vue d’ensemble de la sécurité ASP.NET Core.
.NET offre une sécurité basée sur les rôles pour aider à résoudre les problèmes de sécurité liés au code mobile et à fournir une prise en charge qui permet aux composants de déterminer ce que les utilisateurs sont autorisés à faire.
Sécurité des types et sûreté
Le code de type sécurisé accède uniquement aux emplacements de mémoire qu’il est autorisé à accéder. (Pour cette discussion, la sécurité des types fait spécifiquement référence à la sécurité des types de mémoire et ne doit pas être confondue avec la sécurité de type dans un respect plus large.) Par exemple, le code de type sécurisé ne peut pas lire les valeurs des champs privés d’un autre objet. Il accède aux types uniquement de manières bien définies et autorisées.
Pendant la compilation juste-à-temps (JIT), un processus de vérification facultatif examine les métadonnées et le langage intermédiaire commun (CIL) d’une méthode qui doit être compilée JIT en code machine natif afin de vérifier qu’elles sont sûres par rapport aux types. Ce processus est ignoré si le code est autorisé à contourner la vérification. Pour plus d’informations sur la vérification, consultez Le processus d’exécution managée.
Bien que la vérification de la sécurité des types ne soit pas obligatoire pour exécuter du code managé, la sécurité des types joue un rôle crucial dans l’isolation des assemblages et l’application de la sécurité. Lorsque le code est sécurisé, le Common Language Runtime peut isoler complètement les assemblys les uns des autres. Cette isolation permet de s'assurer que les assemblages ne peuvent pas se nuire mutuellement et augmente la fiabilité de l'application. Les composants de type sécurisé peuvent s’exécuter en toute sécurité dans le même processus, même s’ils sont approuvés à différents niveaux. Lorsque le code n’est pas de type sécurisé, les effets secondaires indésirables peuvent se produire. Par exemple, le runtime ne peut pas empêcher le code managé d’appeler du code natif (non managé) et d’effectuer des opérations malveillantes. Lorsque le code est sécurisé, le mécanisme d’application de la sécurité du runtime garantit qu’il n’accède pas au code natif, sauf s’il est autorisé à le faire. Tout le code qui n’est pas de type sécurisé doit avoir été accordé SecurityPermission avec le membre d’énumération SkipVerification passé à exécuter.
Remarque
La sécurité de l’accès au code (CAS) a été déconseillée dans toutes les versions de .NET Framework et .NET. Les versions récentes de .NET n’honorent pas les annotations CAS et produisent des erreurs si les API associées à CAS sont utilisées. Les développeurs doivent rechercher d’autres moyens d’accomplir des tâches de sécurité.
Principal
Un principal représente l’identité et le rôle d’un utilisateur et agit au nom de l’utilisateur. La sécurité basée sur les rôles dans .NET prend en charge trois types de principaux :
Les principaux génériques représentent les utilisateurs et les rôles qui existent indépendamment des utilisateurs et des rôles Windows.
Les principes Windows représentent les utilisateurs Windows et leurs fonctions (ou leurs groupes Windows). Un principal Windows peut se faire passer pour un autre utilisateur, ce qui signifie que le principal peut accéder à une ressource au nom d’un utilisateur tout en présentant l’identité qui appartient à cet utilisateur-là.
Les principaux personnalisés peuvent être définis par une application de n’importe quelle façon nécessaire pour cette application particulière. Ils peuvent étendre la notion de base de l’identité et des rôles du principal.
Pour plus d’informations, consultez Principaux et Objets d’identité.
Authentification
L’authentification est le processus de découverte et de vérification de l’identité d’un principal en examinant les informations d’identification de l’utilisateur et en validant ces informations d’identification par rapport à une autorité. Les informations obtenues pendant l’authentification sont directement utilisables par votre code. Vous pouvez également utiliser la sécurité basée sur les rôles .NET pour authentifier l’utilisateur actuel et déterminer s’il faut autoriser ce principal à accéder à votre code. Consultez les surcharges de la WindowsPrincipal.IsInRole méthode pour obtenir des exemples d’authentification du principal pour des rôles spécifiques. Par exemple, vous pouvez utiliser la WindowsPrincipal.IsInRole(String) surcharge pour déterminer si l’utilisateur actuel est membre du groupe des Administrateurs.
De nombreux mécanismes d’authentification sont utilisés aujourd’hui, dont beaucoup peuvent être utilisés avec la sécurité basée sur les rôles .NET. Certains des mécanismes les plus couramment utilisés sont des mécanismes de base, digest, Passport, système d’exploitation (par exemple, NTLM ou Kerberos) ou des mécanismes définis par l’application.
Exemple :
L’exemple suivant nécessite que le principal actif soit un administrateur. Le name paramètre est null, ce qui permet à tout utilisateur qui est administrateur de passer la demande.
Remarque
Dans Windows Vista, le contrôle de compte d’utilisateur (UAC) détermine les privilèges d’un utilisateur. Si vous êtes membre du groupe Administrateurs intégrés, vous disposez de deux jetons d’accès au runtime : un jeton d’accès utilisateur standard et un jeton d’accès administrateur. Par défaut, vous êtes dans le rôle d’utilisateur standard. Pour exécuter le code qui vous oblige à être administrateur, vous devez d’abord élever vos privilèges de l’utilisateur standard à l’administrateur. Pour ce faire, lorsque vous démarrez une application, cliquez avec le bouton droit sur l’icône de l’application et indiquez que vous souhaitez exécuter en tant qu’administrateur.
using System;
using System.Threading;
using System.Security.Permissions;
using System.Security.Principal;
class SecurityPrincipalDemo
{
public static void Main()
{
AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
PrincipalPermission principalPerm = new PrincipalPermission(null, "Administrators");
principalPerm.Demand();
Console.WriteLine("Demand succeeded.");
}
}
Imports System.Threading
Imports System.Security.Permissions
Imports System.Security.Principal
Class SecurityPrincipalDemo
Public Shared Sub Main()
AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal)
Dim principalPerm As New PrincipalPermission(Nothing, "Administrators")
principalPerm.Demand()
Console.WriteLine("Demand succeeded.")
End Sub
End Class
L’exemple suivant montre comment déterminer l’identité du principal et les rôles disponibles pour le principal. Une application de cet exemple peut être de confirmer que l’utilisateur actuel est dans un rôle que vous autorisez à utiliser votre application.
using System;
using System.Threading;
using System.Security.Permissions;
using System.Security.Principal;
class SecurityPrincipalDemo
{
public static void DemonstrateWindowsBuiltInRoleEnum()
{
AppDomain myDomain = Thread.GetDomain();
myDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
WindowsPrincipal myPrincipal = (WindowsPrincipal)Thread.CurrentPrincipal;
Console.WriteLine($"{myPrincipal.Identity.Name.ToString()} belongs to: ");
Array wbirFields = Enum.GetValues(typeof(WindowsBuiltInRole));
foreach (object roleName in wbirFields)
{
try
{
// Cast the role name to a RID represented by the WindowsBuildInRole value.
Console.WriteLine($"{roleName}? {myPrincipal.IsInRole((WindowsBuiltInRole)roleName)}.");
Console.WriteLine("The RID for this role is: " + ((int)roleName).ToString());
}
catch (Exception)
{
Console.WriteLine($"{roleName}: Could not obtain role for this RID.");
}
}
// Get the role using the string value of the role.
Console.WriteLine($"'Administrators'? {myPrincipal.IsInRole("BUILTIN\\" + "Administrators")}.");
Console.WriteLine($"'Users'? {myPrincipal.IsInRole("BUILTIN\\" + "Users")}.");
// Get the role using the WindowsBuiltInRole enumeration value.
Console.WriteLine($"{WindowsBuiltInRole.Administrator}? {myPrincipal.IsInRole(WindowsBuiltInRole.Administrator)}.");
// Get the role using the WellKnownSidType.
SecurityIdentifier sid = new SecurityIdentifier(WellKnownSidType.BuiltinAdministratorsSid, null);
Console.WriteLine($"WellKnownSidType BuiltinAdministratorsSid {sid.Value}? {myPrincipal.IsInRole(sid)}.");
}
public static void Main()
{
DemonstrateWindowsBuiltInRoleEnum();
}
}
Imports System.Threading
Imports System.Security.Permissions
Imports System.Security.Principal
Class SecurityPrincipalDemo
Public Shared Sub DemonstrateWindowsBuiltInRoleEnum()
Dim myDomain As AppDomain = Thread.GetDomain()
myDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal)
Dim myPrincipal As WindowsPrincipal = CType(Thread.CurrentPrincipal, WindowsPrincipal)
Console.WriteLine("{0} belongs to: ", myPrincipal.Identity.Name.ToString())
Dim wbirFields As Array = [Enum].GetValues(GetType(WindowsBuiltInRole))
Dim roleName As Object
For Each roleName In wbirFields
Try
' Cast the role name to a RID represented by the WindowsBuildInRole value.
Console.WriteLine("{0}? {1}.", roleName, myPrincipal.IsInRole(CType(roleName, WindowsBuiltInRole)))
Console.WriteLine("The RID for this role is: " + Fix(roleName).ToString())
Catch
Console.WriteLine("{0}: Could not obtain role for this RID.", roleName)
End Try
Next roleName
' Get the role using the string value of the role.
Console.WriteLine("{0}? {1}.", "Administrators", myPrincipal.IsInRole("BUILTIN\" + "Administrators"))
Console.WriteLine("{0}? {1}.", "Users", myPrincipal.IsInRole("BUILTIN\" + "Users"))
' Get the role using the WindowsBuiltInRole enumeration value.
Console.WriteLine("{0}? {1}.", WindowsBuiltInRole.Administrator, myPrincipal.IsInRole(WindowsBuiltInRole.Administrator))
' Get the role using the WellKnownSidType.
Dim sid As New SecurityIdentifier(WellKnownSidType.BuiltinAdministratorsSid, Nothing)
Console.WriteLine("WellKnownSidType BuiltinAdministratorsSid {0}? {1}.", sid.Value, myPrincipal.IsInRole(sid))
End Sub
Public Shared Sub Main()
DemonstrateWindowsBuiltInRoleEnum()
End Sub
End Class
Autorisation
L’autorisation est le processus permettant de déterminer si un principal est autorisé à effectuer une action demandée. L’autorisation se produit après l’authentification et utilise des informations sur l’identité et les rôles du principal pour déterminer les ressources auxquelles le principal peut accéder. Vous pouvez utiliser la sécurité basée sur les rôles .NET pour implémenter l’autorisation.