Remarque
L’accès à cette page requiert une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page requiert 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 ASP.NET Sécurité principale.
Le code managé peut découvrir l’identité ou le rôle d’un principal via un IPrincipal objet, qui contient une référence à un IIdentity objet. Il peut être utile de comparer des objets d’identité et de principal à des concepts familiers tels que les comptes d’utilisateur et de groupe. Dans la plupart des environnements réseau, les comptes d’utilisateur représentent des personnes ou des programmes, tandis que les comptes de groupe représentent certaines catégories d’utilisateurs et les droits qu’ils possèdent. De même, les objets d’identité .NET représentent les utilisateurs, tandis que les rôles représentent des appartenances et des contextes de sécurité. Dans .NET, l’objet principal encapsule un objet d’identité et un rôle. Les applications .NET accordent des droits au principal en fonction de son identité ou, plus souvent, de son appartenance au rôle.
Objets d’identité
L’objet d’identité encapsule des informations sur l’utilisateur ou l’entité en cours de validation. Au niveau le plus simple, les objets d’identité contiennent un nom et un type d’authentification. Le nom peut être le nom d’un utilisateur ou le nom d’un compte Windows, tandis que le type d’authentification peut être un protocole d’ouverture de session pris en charge, tel que Kerberos V5 ou une valeur personnalisée. .NET définit un GenericIdentity objet qui peut être utilisé pour la plupart des scénarios d’ouverture de session personnalisés et un objet plus spécialisé WindowsIdentity qui peut être utilisé lorsque 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 permettant d’accéder à un nom et à un type d’authentification, comme Kerberos V5 ou NTLM. Toutes les classes Identity implémentent l’interface IIdentity . Il n’existe aucune relation 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 principaux
L’objet principal représente le contexte de sécurité sous lequel le code est en cours d’exécution. Applications qui implémentent des droits d’octroi de sécurité en fonction du rôle associé à un objet principal. Comme pour les objets d’identité, .NET fournit un GenericPrincipal objet et un WindowsPrincipal objet. Vous pouvez également définir vos propres classes principales personnalisées.
L’interface IPrincipal définit une propriété pour accéder à un objet Identity associé, ainsi qu’une méthode pour déterminer si l’utilisateur identifié par l’objet Principal est membre d’un rôle donné. Toutes les classes principal implémentent l’interface IPrincipal , ainsi que toutes 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 aux rôles.
Un objet Principal est lié à un objet de contexte d’appel (CallContext) au sein d’un domaine d’application (AppDomain). Un contexte d’appel par défaut est toujours créé avec chaque nouveau AppDomain. Il existe donc toujours un contexte d’appel disponible pour accepter l’objet Principal . Lorsqu’un thread est créé, un objet CallContext est également créé pour le thread. La référence d’objet Principal est automatiquement copiée à partir du thread de création vers le 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 pour la création d’objets Principal et Identity .
Une stratégie configurable spécifique au domaine d’application définit les règles permettant de déterminer le type d’objet Principal à associer à un nouveau domaine d’application. Là où la stratégie de sécurité est autorisée, le runtime peut créer des objets Principal et Identity qui reflètent le jeton du système d’exploitation associé au thread actuel 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 de les accéder.
Le code approuvé qui crée un domaine d’application peut définir la stratégie de domaine d’application qui contrôle la construction des objets Principal et Identity par défaut. Cette stratégie spécifique au domaine d’application s’applique à tous les threads d’exécution de ce domaine d’application. Un hôte non managé et approuvé a intrinsèquement la possibilité de définir cette stratégie, mais le code managé qui définit cette stratégie doit avoir la possibilité de contrôler la System.Security.Permissions.SecurityPermission stratégie de domaine.
Lors de la transmission d’un objet Principal entre les domaines d’application, mais dans le même processus (et par conséquent sur le même ordinateur), l’infrastructure de communication à distance copie une référence à l’objet Principal associé au contexte de l’appelant dans le contexte de l’appelant.
Voir aussi
Collaborer avec nous sur GitHub
La source de ce contenu se trouve sur GitHub, où vous pouvez également créer et examiner des problèmes et des demandes de tirage (pull requests). Pour plus d’informations, consultez notre guide du contributeur.
