System.Security.Permissions.PrincipalPermission Class

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

See Also: PrincipalPermission Members

Syntax

[System.Runtime.InteropServices.ComVisible(true)]
public sealed class PrincipalPermission : System.Security.IPermission, IBuiltInPermission, IUnrestrictedPermission

Remarks

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

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

Unlike most other permissions, System.Security.Permissions.PrincipalPermission does not extend System.Security.CodeAccessPermission. It does, however, implement the System.Security.IPermission interface. This is because System.Security.Permissions.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 (PrincipalPermission.Demand, PrincipalPermission.Union(System.Security.IPermission), PrincipalPermission.Intersect(System.Security.IPermission), 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.

Note:

Prior to a demand for principal permission it is necessary to set the current application domain's principal policy to the enumeration value System.Security.Principal.PrincipalPolicy.WindowsPrincipal. By default, the principal policy is set to System.Security.Principal.PrincipalPolicy.UnauthenticatedPrincipal. If you do not set the principal policy to System.Security.Principal.PrincipalPolicy.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).

Requirements

Namespace: System.Security.Permissions
Assembly: mscorlib (in mscorlib.dll)
Assembly Versions: 1.0.5000.0, 2.0.0.0, 4.0.0.0