By passing identity information (user name and role) to the constructor, PrincipalPermission can be used to demand that the identity of the active principal matches this information.

To match the active IPrincipal and associated IIdentity, both the specified identity and role must match. If nullNothingnullptra null reference (Nothing in Visual Basic) identity string is used, it is interpreted as a request to match any identity. Use of nullNothingnullptra null reference (Nothing in Visual Basic) role string will match any role. By implication, passing nullNothingnullptra null reference (Nothing in Visual Basic) parameter for name or role to PrincipalPermission will match the identity and roles in any IPrincipal. It is also possible to construct a PrincipalPermission that only determines whether the IIdentity represents an authenticated or unauthenticated entity. In this case, name and role are ignored.

Unlike most other permissions, PrincipalPermission does not extend CodeAccessPermission. It does, however, implement the IPermission interface. This is because PrincipalPermission is not a code access permission; that is, it is not granted based on the identity of the executing assembly. Instead, it allows code to perform actions (Demand, Union, Intersect, and so on) against the current user identity in a manner consistent with the way those actions are performed for code access and code identity permissions.

Important Note:

Prior to a demand for principal permission it is necessary to set the current application domain's principal policy to the enumeration value WindowsPrincipal. By default, the principal policy is set to UnauthenticatedPrincipal. If you do not set the principal policy to WindowsPrincipal, a demand for principal permission will fail. The following code should be executed before the principal permission is demanded: AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal).

The following example requires the active principal to be an administrator. The name parameter is nullNothingnullptra null reference (Nothing in Visual Basic), which enables any user who is an administrator to pass the demand.

Note:

In Windows Vista, User Account Control (UAC) determines the privileges of a user. If you are a member of the Built-in Administrators group, you are assigned two run-time access tokens: a standard user access token and an administrator access token. By default, you are in the standard user role. To execute the code that requires you to be an administrator, you must first elevate your privileges from standard user to administrator. You can do this when you start an application by right-clicking the application icon and indicating that you want to run as an administrator.

Dim id1 As String = "Bob"
Dim role1 As String = "Manager"
Dim PrincipalPerm1 As New PrincipalPermission(id1, role1)

Dim id2 As String = "Louise"
Dim role2 As String = "Supervisor"
Dim PrincipalPerm2 As 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();

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

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

(PrincipalPerm1->Union( PrincipalPerm2 ))->Demand();

Windows 7, Windows Vista, Windows XP SP2, Windows XP Media Center Edition, Windows XP Professional x64 Edition, Windows XP Starter Edition, Windows Server 2008 R2, Windows Server 2008, Windows Server 2003, Windows Server 2000 SP4, Windows Millennium Edition, Windows 98

.NET Framework

Reference

Other Resources