PrincipalPermissionAttribute Class (System.Security.Permissions)

Collapse All

Language Filter

This page is specific to

Microsoft Visual Studio 2008/.NET Framework 3.5

Other versions are also available for the following:

.NET Framework Class Library

PrincipalPermissionAttribute Class

Updated: November 2007

Allows security actions for PrincipalPermission to be applied to code using declarative security. This class cannot be inherited.

Namespace: System.Security.Permissions
Assembly: mscorlib (in mscorlib.dll)

Syntax

Visual Basic (Declaration)

<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

/** @attribute SerializableAttribute */ 
/** @attribute ComVisibleAttribute(true) */
/** @attribute AttributeUsageAttribute(AttributeTargets.Class|AttributeTargets.Method, AllowMultiple = true, Inherited = false) */
public final class PrincipalPermissionAttribute extends 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 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).

Examples

The following example demonstrates how PrincipalPermission can be used declaratively to demand that the current user is Bob and belongs to the Supervisor role.

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")]

/** @attribute PrincipalPermissionAttribute(SecurityAction.Demand,
    Name = "Bob", Role = "Supervisor")
 */

The following example demonstrates how to demand that the current user's identity is Bob, regardless of role membership.

Visual Basic

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

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

Visual C++

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

/** @attribute PrincipalPermissionAttribute(SecurityAction.Demand, Name = "Bob")
 */

The following example demonstrates how to demand only that the user is authenticated.

Visual Basic

<PrincipalPermissionAttribute(SecurityAction.Demand, _
 Authenticated := True)> Public Class SampleClass

[PrincipalPermissionAttribute(SecurityAction.Demand, Authenticated=true)]

Visual C++

[PrincipalPermissionAttribute(SecurityAction::Demand,Authenticated=true)]

/** @attribute PrincipalPermissionAttribute(SecurityAction.Demand, 
    Authenticated = true)
 */

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 Vista, Windows XP SP2, Windows XP Media Center Edition, Windows XP Professional x64 Edition, Windows XP Starter Edition, 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

Tags

: Add a tag

Community Content

Add new content

Annotations

Change in behavior between 1.1 and 2.0 frameworks

HashKeyLime | Edit |

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.

Product Families

Resources

About Microsoft

Popular Places

Popular Searches

Popular Downloads

.NET Framework

Reference

Other Resources