PrincipalPermissionAttribute Class (System.Security.Permissions)

<SerializableAttribute> _
<ComVisibleAttribute(True)> _
<AttributeUsageAttribute(AttributeTargets.Class Or AttributeTargets.Method, AllowMultiple := True,  _
    Inherited := False)> _
Public NotInheritable Class PrincipalPermissionAttribute _
    Inherits CodeAccessSecurityAttribute

Visual Basic (Usage)

Dim instance As PrincipalPermissionAttribute

[SerializableAttribute]
[ComVisibleAttribute(true)]
[AttributeUsageAttribute(AttributeTargets.Class|AttributeTargets.Method, AllowMultiple = true, 
    Inherited = false)]
public sealed class PrincipalPermissionAttribute : CodeAccessSecurityAttribute

Visual C++

[SerializableAttribute]
[ComVisibleAttribute(true)]
[AttributeUsageAttribute(AttributeTargets::Class|AttributeTargets::Method, AllowMultiple = true, 
    Inherited = false)]
public ref class PrincipalPermissionAttribute sealed : public CodeAccessSecurityAttribute

JScript

public final class PrincipalPermissionAttribute extends CodeAccessSecurityAttribute

Remarks

PrincipalPermissionAttribute can be used to declaratively demand that users running your code belong to a specified role or have been authenticated. Use of Unrestricted creates a PrincipalPermission with Authenticated set to true and Name and Role set to nullNothingnullptra null reference (Nothing in Visual Basic).

The scope of the declaration that is allowed depends on the SecurityAction that is used. PrincipalPermissionAttribute cannot be applied at the assembly level.

The security information declared by a security attribute is stored in the metadata of the attribute target and is accessed by the system at run time. Security attributes are used only for declarative security. For imperative security, use the corresponding permission class.

Important Note:
Before you use this class to demand principal permission, you must 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).

Important Note:

Before you use this class to demand principal permission, you must 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).

Examples

The following example demonstrates how the PrincipalPermissionAttribute class is used declaratively to demand that the current user be an administrator.

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.

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.

Visual Basic

<PrincipalPermissionAttribute(SecurityAction.Demand, _
 Name := "Bob", Role := "Supervisor")> Public Class SampleClass

[PrincipalPermissionAttribute(SecurityAction.Demand, Name="Bob",
Role="Supervisor")]

Visual C++

[PrincipalPermissionAttribute(SecurityAction::Demand,Name="Bob",
Role="Supervisor")]

Inheritance Hierarchy

System..::.Object
  System..::.Attribute
    System.Security.Permissions..::.SecurityAttribute
      System.Security.Permissions..::.CodeAccessSecurityAttribute
        System.Security.Permissions..::.PrincipalPermissionAttribute

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.

Platforms

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

The .NET Framework and .NET Compact Framework do not support all versions of every platform. For a list of the supported versions, see .NET Framework System Requirements.

Version Information

.NET Framework

Supported in: 3.5, 3.0, 2.0, 1.1, 1.0

Reference

PrincipalPermissionAttribute Members

System.Security.Permissions Namespace

PrincipalPermission

Other Resources

Extending Metadata Using Attributes

Principal

Change History

Date	History	Reason
September 2008	Updated the example.	Customer feedback.

Date

History

Reason

September 2008

Updated the example.

Customer feedback.

Tags :

Community Content

HashKeyLime

Change in behavior between 1.1 and 2.0 frameworks

It should be noted that there was a significant change in behavior between the 1.1 and the 2.0 framework versions of the PrincipalPermissionAttribute. The change has the possibility to open security holes in existing code that is migrated from 1.1. See link https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=95127

PrincipalPermissionAttributes can be applied at both the class and method level. Consider the following code of a simple class requiring either a role of "RoleOne" OR "RoleTwo" to instantiate the class. Then, the method DoSomething() requires a role of "RoleTwo".

[

PrincipalPermission(SecurityAction.Demand, Role="RoleOne"),
PrincipalPermission(SecurityAction.Demand, Role="RoleTwo")]
publicclassWidget
{
public Widget()
{
// TODO:
}

[

PrincipalPermission(SecurityAction.Demand, Role="RoleTwo")]
publicvoid DoSomething()
{
// TODO:
}
}

Now, consider a user who has ONLY "RoleOne" and NOT "RoleTwo".

In the 1.1 Framework, the user could instantiate the class because he belongs to one of the required roles. The user could NOT call DoSomething(), however because he does not have "RoleTwo".

In the 2.0 Framework, the user could instantiate the class because he belongs to one of the required roles. The user could then ALSO call DoSomething(), even though he does not have "RoleTwo" because the method attribute is not exclusive and the class attributes let in the user.

It seems to work like, "Is the user in RoleOne OR RoleTwo OR RoleTwo(from the method)". Since the user is in RoleOne, he is in. This can break existing code. Also, the developer needs to keep this in mind for future development.

Tags :