Objets Principal et Identity
Notes
Cet article s’applique à Windows.
Pour plus d’informations sur ASP.NET Core, consultez Sécurité ASP.NET Core.
Le code managé peut découvrir l’identité ou le rôle d’un principal par le biais d’un objet IPrincipal, qui contient une référence à un objet IIdentity. Il peut être utile de comparer des objets identity et principal à des concepts familiers comme les comptes des utilisateurs et des groupes. Dans la plupart des environnements de réseau, les comptes d’utilisateur représentent des personnes ou des programmes, tandis que les comptes de groupe représentent des catégories d’utilisateurs et les droits qu’ils possèdent. De même, les objets identity .NET représentent des utilisateurs, tandis que les rôles représentent des appartenances et des contextes de sécurité. Dans .NET, l’objet principal encapsule un objet identity et un rôle. Les applications .NET accordent des droits au principal en fonction de son identité ou, plus fréquemment, de son appartenance au rôle.
Objets Identity
L’objet identity encapsule des informations sur l’utilisateur ou l’une entité en cours de validation. Au niveau de base, les objets identity contiennent un nom et un type d’authentification. Le nom peut être un nom d’utilisateur ou le nom d’un compte Windows, tandis que le type d’authentification peut être un protocole de connexion pris en charge, tel que Kerberos V5, ou une valeur personnalisée. .NET définit un objet GenericIdentity qui peut être utilisé pour la plupart des scénarios d’ouverture de session personnalisés et un objet WindowsIdentity plus spécialisé qui peut être utilisé quand vous souhaitez que votre application s’appuie sur l’authentification Windows. En outre, vous pouvez définir votre propre classe d’identité qui encapsule des informations utilisateur personnalisées.
L’interface IIdentity définit les propriétés pour accéder à un nom et un type d’authentification tel que Kerberos V5 ou NTLM. Toutes les classes Identity implémentent l’interface IIdentity. Aucune relation n’est requise entre un objet Identity et le jeton de processus Windows sous lequel un thread est en cours d’exécution. Toutefois, si l’objet Identity est un objet WindowsIdentity, l’identité est supposée représenter un jeton de sécurité Windows.
Objets Principal
L’objet principal représente le contexte de sécurité dans lequel le code est exécuté. Les applications qui implémentent une sécurité basée sur les rôles accordent des droits en fonction du rôle associé à un objet principal. Comme pour les objets identity, .NET fournit un objet GenericPrincipal et un objet WindowsPrincipal. Vous pouvez également définir vos propres classes principal personnalisées.
L’interface IPrincipal définit une propriété permettant d’accéder à un objet Identity associé ainsi qu’une méthode permettant de déterminer si l’utilisateur identifié par l’objet Principal est un membre d’un rôle donné. Toutes les classes Principal implémentent l’interface IPrincipal ainsi que les propriétés et méthodes supplémentaires nécessaires. Par exemple, le common language runtime fournit la classe WindowsPrincipal qui implémente des fonctionnalités supplémentaires pour mapper l’appartenance au groupe avec des rôles.
Un objet Principal est lié à un objet de contexte d’appel (CallContext) dans un domaine d’application (AppDomain). Un contexte d’appel par défaut est toujours créé avec chaque nouveau AppDomain. Un contexte d’appel est donc toujours disponible pour accepter l’objet Principal. Lorsqu’un nouveau thread est créé, un objet CallContext est également créé pour le thread. La référence de l’objet Principal est automatiquement copiée du thread de création dans l’objet CallContext du nouveau thread. Si le runtime ne peut pas déterminer quel objet Principal appartient au créateur du thread, il suit la stratégie par défaut de création d’un objet Principal et Identity.
Une stratégie spécifique de domaine d’application configurable définit les règles permettant de déterminer le type d’objet Principal à associer à un nouveau domaine d’application. Si la stratégie de sécurité le permet, le runtime peut créer des objets Principal et Identity qui correspondent au jeton de système d’exploitation associé au thread en cours d’exécution. Par défaut, le runtime utilise des objets Principal et Identity qui représentent des utilisateurs non authentifiés. Le runtime ne crée pas ces objets Principal et Identity par défaut tant que le code ne tente pas d’y accéder.
Le code approuvé créant un domaine d’application peut définir la stratégie de domaine d’application qui régit la construction des objets Principal et Identity par défaut. Cette stratégie spécifique du domaine d’application s’applique à tous les threads d’exécution dans ce domaine d’application. De manière intrinsèque, un hôte approuvé non managé a la possibilité de définir cette stratégie, mais le code managé qui définit cette stratégie doit inclure System.Security.Permissions.SecurityPermission pour contrôler la stratégie de domaine.
Lors de la transmission d’un objet Principal entre des domaines d’application, mais dans le même processus (et donc sur le même ordinateur), l’infrastructure distante copie une référence à l’objet Principal associé au contexte de l’appelant dans le contexte de l’appelé.
