This documentation is archived and is not being maintained.

PrincipalPermission Class

Allows checks against the active principal (see IPrincipal) using the language constructs defined for both declarative and imperative security actions. This class cannot be inherited.

For a list of all members of this type, see PrincipalPermission Members.


[Visual Basic]
NotInheritable Public Class PrincipalPermission
   Implements IPermission, ISecurityEncodable, _
public sealed class PrincipalPermission : IPermission,
   ISecurityEncodable, IUnrestrictedPermission
public __gc __sealed class PrincipalPermission : public
   IPermission, ISecurityEncodable, IUnrestrictedPermission
class PrincipalPermission implements IPermission,
   ISecurityEncodable, IUnrestrictedPermission

Thread Safety

Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.


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 a null reference (Nothing in Visual Basic) identity string is used, it is interpreted as a request to match any identity. Use of a null reference (Nothing) role string will match any role. By implication, passing a null reference (Nothing) 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.


[Visual Basic, C#, C++] The following example creates two PrincipalPermission objects representing two different administrative users, forms the union of the two, and makes a demand. Demand will succeed only if the active implementation of IPrincipal represents either user Bob in the role of Manager or user Louise in the role of Supervisor.

[Visual Basic] 
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)

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

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


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

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


[JScript] No example is available for JScript. To view a Visual Basic, C#, or C++ example, click the Language Filter button Language Filter in the upper-left corner of the page.


Namespace: System.Security.Permissions

Platforms: Windows 98, Windows NT 4.0, Windows Millennium Edition, Windows 2000, Windows XP Home Edition, Windows XP Professional, Windows Server 2003 family

Assembly: Mscorlib (in Mscorlib.dll)

See Also

PrincipalPermission Members | System.Security.Permissions Namespace | Permissions | Requesting Permissions | Principal | PrincipalPermissionAttribute