Cette documentation est archivée et n’est pas conservée.

PrincipalPermission, classe

Mise à jour : novembre 2007

Autorise les vérifications par rapport à l'entité de sécurité active (consultez IPrincipal) à l'aide des constructions du langage définies pour les actions de sécurité déclarative et impérative. Cette classe ne peut pas être héritée.

Espace de noms :  System.Security.Permissions
Assembly :  mscorlib (dans mscorlib.dll)

[SerializableAttribute]
[ComVisibleAttribute(true)]
public sealed class PrincipalPermission : IPermission, 
	IUnrestrictedPermission, ISecurityEncodable
/** @attribute SerializableAttribute */ 
/** @attribute ComVisibleAttribute(true) */
public final class PrincipalPermission implements IPermission, 
	IUnrestrictedPermission, ISecurityEncodable
public final class PrincipalPermission implements IPermission, IUnrestrictedPermission, ISecurityEncodable

En passant les informations d'identité (nom d'utilisateur et rôle) au constructeur, PrincipalPermission peut être utilisé pour exiger que l'identité de l'entité de sécurité active corresponde à ces informations.

Pour qu'il y ait correspondance avec le IPrincipal actif et le IIdentity associé, il faut que l'identité et le rôle spécifiés correspondent. Si une chaîne d'identité null est utilisée, elle est interprétée comme une demande de correspondance avec n'importe quelle identité. Une chaîne de rôle null correspond à n'importe quel rôle. Il s'ensuit qu'en passant le paramètre null comme name ou role à PrincipalPermission, vous recherchez la correspondance avec l'identité et les rôles de n'importe quel IPrincipal. Il est également possible de construire un PrincipalPermission qui détermine seulement si IIdentity représente une entité authentifiée ou non authentifiée. Dans ce cas, name et role sont ignorés.

À la différence de la plupart des autres autorisations, PrincipalPermission n'étend pas CodeAccessPermission. En revanche, cet objet implémente l'interface IPermission. Ceci est dû au fait que PrincipalPermission n'est pas une autorisation d'accès au code, c'est-à-dire qu'elle n'est pas accordée en fonction de l'identité de l'assembly en cours d'exécution. Cet objet permet plutôt au code d'effectuer des actions (Demand, Union, Intersect, etc.) par rapport à l'identité de l'utilisateur en cours, d'une manière cohérente avec celle dont ces actions sont effectuées pour les autorisations d'accès et d'identité au code.

Remarque importante :

Avant une demande d'autorisation principale, il est nécessaire de définir la stratégie principale du domaine d'application actuel sur la valeur d'énumération WindowsPrincipal. Par défaut, la stratégie principale est UnauthenticatedPrincipal. Si vous ne définissez pas la stratégie principale sur WindowsPrincipal, la demande d'autorisation principale échouera. Le code suivant doit être exécuté avant la demande de l'autorisation principale :

AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal).

L'exemple de code suivant crée deux objets PrincipalPermission représentant deux utilisateurs administratifs différents, construit l'union des deux objets et effectue une demande. Demand réussit uniquement si l'implémentation active de IPrincipal représente l'utilisateur Bob dans le rôle de Manager ou l'utilisateur Louise dans le rôle de Superviseur.

String id1 = "Bob";
String role1 = "Manager";
PrincipalPermission PrincipalPerm1 = new PrincipalPermission(id1, role1);

String id2 = "Louise";
String role2 = "Supervisor";
PrincipalPermission PrincipalPerm2 = new PrincipalPermission(id2, role2);

(PrincipalPerm1.Union(PrincipalPerm2)).Demand();


String id1 = "Bob";
String role1 = "Manager";
PrincipalPermission principalPerm1 = new PrincipalPermission(id1,
    role1);
String id2 = "Louise";
String role2 = "Supervisor";
PrincipalPermission principalPerm2 = new PrincipalPermission(id2,
    role2);
principalPerm1.Union(principalPerm2).Demand();


System.Object
  System.Security.Permissions.PrincipalPermission

Tous les membres static (Shared en Visual Basic) publics de ce type sont thread-safe. Il n'est pas garanti que les membres d'instance soient thread-safe.

Windows Vista, Windows XP SP2, Windows XP Media Center Edition, Windows XP Professionnel Édition x64, Windows XP Starter Edition, Windows Server 2003, Windows Server 2000 SP4, Windows Millennium Edition, Windows 98

Le .NET Framework et le .NET Compact Framework ne prennent pas en charge toutes les versions de chaque plateforme. Pour obtenir la liste des versions prises en charge, consultez Configuration requise du .NET Framework.

.NET Framework

Pris en charge dans : 3.5, 3.0, 2.0, 1.1, 1.0
Afficher: