Objets Principal et Identity

Un code managé peut découvrir l'identité ou le rôle d'une entité de sécurité par le biais d'un objet Principal ; ce dernier contient une référence à un objet Identity. Il peut être utile d'établir un parallèle entre les objets Identity et Principal et des concepts plus familiers tels que les comptes d'utilisateurs et de groupes. Dans la majorité des environnements de réseau, les comptes d'utilisateurs représentent des personnes ou des programmes, tandis que les comptes de groupes représentent diverses catégories d'utilisateurs et les droits qu'ils possèdent. De la même façon, les objets Identity de .NET Framework représentent des utilisateurs tandis que les rôles correspondent à des appartenances et à des contextes de sécurité. Dans .NET Framework, l'objet Principal encapsule à la fois un objet Identity et un rôle. Les applications .NET Framework octroient des droits à l'entité de sécurité en fonction de son identité ou, plus fréquemment, de son appartenance à un rôle.

Objets Identity

Un objet Identity encapsule des informations sur l'utilisateur ou sur l'entité en cours de validation. À la base, les objets Identity contiennent un nom et un type d'authentification. Le nom peut être celui d'un utilisateur ou 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 Framework définit un objet GenericIdentity convenant à la majorité des scénarios de connexion personnalisés et un objet WindowsIdentity plus spécifique, que vous pouvez utiliser lorsque votre application doit avoir recours à l'authentification Windows. En outre, vous pouvez définir votre propre classe d'identité qui encapsule des informations personnalisées sur les utilisateurs.   

L'interface IIdentity définit les propriétés permettant d'accéder à un nom ou à un type d'authentification, tel que Kerberos V5 ou NTLM. Toutes les classes Identity implémentent l'interface IIdentity. Aucune relation n'est obligatoire entre un objet Identity et le jeton de traitement Windows NT sous lequel un thread est actuellement exécuté. Toutefois, si l'objet Identity est un objet WindowsIdentity, il est supposé que l'identité représente un jeton de sécurité Windows NT.

Objets Principal

L'objet principal représente le contexte de sécurité dans lequel le code est exécuté. Les applications qui implémentent la sécurité basée sur les rôles accordent des droits en fonction du rôle associé à un objet Principal. À l'instar des objets Identity, .NET Framework utilise un objet GenericPrincipal et un objet WindowsPrincipal. Vous pouvez aussi définir des 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 servant à déterminer si l'utilisateur désigné par l'objet Principal est membre d'un rôle donné. Toutes les classes Principal implémentent l'interface IPrincipal, de même que toutes les autres propriétés et méthodes supplémentaires requises. Par exemple, le Common Language Runtime fournit la classe WindowsPrincipal qui implémente des fonctionnalités supplémentaires pour le mappage à des rôles de l'appartenance à des groupes Windows NT ou Windows 2000.

Un objet Principal est lié à un objet contexte d'appel (CallContext) dans un domaine d'application (AppDomain). Un contexte d'appel par défaut est toujours créé avec chaque nouveau AppDomain et il existe donc toujours un contexte d'appel en mesure d'accepter l'objet Principal. Lorsqu'un nouveau thread est créé, un objet CallContext est également créé pour celui-ci. La référence de l'objet Principal est automatiquement copiée du thread en cours de création vers l'objet CallContext du nouveau thread. Si le runtime n'est pas en mesure de déterminer l'objet Principal correspondant au créateur du thread, il se conforme à la stratégie par défaut applicable à la création des objets Principal et Identity.

Une stratégie paramétrable, propre au domaine d'application, définit les règles qui déterminent 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 reflètent le jeton de système d'exploitation associé au thread d'exécution en cours. Par défaut, le runtime utilise des objets Principal et Identity qui représentent des utilisateurs non authentifiés. Ces objets Principal et Identity par défaut ne sont pas créés tant que le code ne tente pas d'y accéder.

Le code de confiance qui crée un domaine d'application peut définir la stratégie du domaine d'application qui gouverne la construction des objets Principal et Identity par défaut. Cette stratégie spécifique au domaine d'application est applicable à tous les threads d'exécution dudit domaine d'application. Un hôte de confiance, non managé, peut intrinsèquement définir cette stratégie. Toutefois, lorsqu'elle est définie par un code managé, ce code doit avoir l'autorisation System.Security.Permissions.SecurityPermission lui permettant de contrôler la stratégie du domaine.

Lors de la transmission d'un objet Principal vers plusieurs domaines d'application au cours d'un même traitement (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é.

Voir aussi

Tâches

Comment : créer un objet WindowsPrincipal
Comment : créer des objets GenericPrincipal et GenericIdentity

Concepts

Remplacement d'un objet Principal
Emprunt et restauration d'identité

Autres ressources

Sécurité basée sur les rôles
Concepts fondamentaux sur la sécurité