Définition d'entités de sécurité et d'une stratégie de sécurité basées sur les rôles
La sécurité basée sur les rôles permet à un composant d'identifier les utilisateurs en cours et les rôles qui y sont associés au moment de l'exécution. Ces informations sont ensuite mappées à l'aide d'une stratégie de sécurité d'accès du code pour déterminer l'ensemble des autorisations accordées au moment de l'exécution. Pour un domaine d'application donné, l'hôte peut modifier la stratégie de sécurité basée sur les rôles par défaut et définir une entité de sécurité par défaut. Une entité de sécurité représente un utilisateur et les rôles associés à cet utilisateur.
La sécurité basée sur les rôles est fréquemment utilisée pour implémenter des schémas d'authentification personnalisés. Par exemple, l'hôte ASP.NET utilise la sécurité basée sur les rôles pour implémenter un schéma d'authentification en fonction des informations utilisateur qu'il obtient à partir de services IIS (Internet Information Services).
La définition à la fois de l'utilisateur et des rôles de l'utilisateur est spécifique à l'application. Une application peut avoir un concept différent de l'utilisateur que celui de Windows. Par exemple, une application peut demander à l'utilisateur de fournir un nom d'utilisateur et un mot de passe lors de la connexion à l'application. Ce nom d'utilisateur/mot de passe est indépendant du nom d'utilisateur/mot de passe avec lequel l'utilisateur ouvre une session Windows.
Définition explicite de l'entité de sécurité pour un thread
Si l'entité de sécurité d'un thread a été définie, l'entité de sécurité par défaut et la stratégie du domaine d'application sont ignorées. Par exemple, le thread a pu définir sa propre entité de sécurité en utilisant la propriété statique CurrentPrincipal (propriété Shared dans Visual Basic) de la classe Thread. Le thread a également pu acquérir son entité de sécurité du thread qui l'a démarré.
Notes
Dans le .NET Framework version 2.0, lorsqu'un thread démarre un autre thread ou met en file d'attente un élément de travail en vue d'une exécution par le pool de threads, le contexte du thread (notamment l'entité de sécurité) transite automatiquement vers le thread enfant ou le thread de pool de thread. Dans les versions 1.0 et 1.1 du .NET Framework, le contexte n'a transité que vers les threads démarrés par un thread, et non vers les threads du pool de threads.
Si un thread ne disposant d'aucune entité de sécurité prend une mesure nécessitant une entité de sécurité, cette dernière est fournie selon la stratégie de sécurité du domaine d'application et l'entité de sécurité par défaut en cours.
Notes
Lorsqu'un thread ne disposant d'aucune entité de sécurité utilise la propriété statique CurrentPrincipal pour interroger son entité, les valeurs par défaut du domaine d'application sont utilisées pour définir l'entité. Autrement dit, CurrentPrincipal ne retourne jamais la valeur null.
Stratégie et entité de sécurité par défaut pour un domaine d'application
Un hôte peut définir une entité de sécurité par défaut pour un domaine d'application en appelant la méthode SetThreadPrincipal. Si une entité de sécurité par défaut a été fournie, elle est assignée à tout thread s'exécutant dans le domaine d'application, requérant une entité de sécurité et ne disposant pas déjà d'une d'entité de sécurité.
Notes
L'entité de sécurité par défaut n'est pas automatiquement appliquée au thread qui appelle SetThreadPrincipal, même si ce thread n'a pas d'entité de sécurité. Si, par la suite, le thread requiert une entité de sécurité (sans l'avoir acquise entre-temps), une entité de sécurité lui est assignée selon l'entité de sécurité par défaut et la stratégie du domaine d'application dans lequel il s'exécute au même moment.
Si aucune entité de sécurité par défaut n'a été définie pour le domaine d'application, une entité de sécurité est assignée au thread selon la stratégie du domaine d'application. Par défaut, la stratégie d'un domaine d'application est d'assigner une entité de sécurité générique non authentifiée au thread. Un hôte peut modifier cette stratégie de domaine d'application en appelant la méthode SetPrincipalPolicy. Par exemple, le code managé suivant crée un domaine d'application et définit sa stratégie pour qu'elle utilise l'entité de sécurité Windows en cours.
Dim ad As AppDomain = AppDomain.CreateDomain("Child")
ad.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal)
AppDomain ad = AppDomain.CreateDomain("Child");
ad.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
AppDomain^ ad = AppDomain::CreateDomain("Child");
ad->SetPrincipalPolicy(PrincipalPolicy::WindowsPrincipal);
Un hôte non managé peut accéder aux domaines d'application à l'aide de l'interface _AppDomain qui conserve l'ordre vtable dans les versions du .NET Framework.
Voir aussi
Référence
Autres ressources
Hébergement du Common Language Runtime
Sécurité basée sur les rôles
Concepts fondamentaux sur la sécurité