Role-based security allows the programmer to specify that a class or member can be called only if the user making the call has a specific username or role. Products such as HTTP and application servers will implement custom models for identifying users, but the .NET Framework provides default support for identifying Windows Users and Groups, which is the topic of this section. Unlike the Code Access Security model, role-based restrictions can be applied to classes and any class member, including properties and events.

The following fragment shows how to make a declarative statement to ensure that only the MyDomainMyUser user account can invoke a method:

using System;
using System.Security.Permissions;
using System.Security.Principal;

class RoleBasedDemo {

    RoleBasedDemo() {
        AppDomain.CurrentDomain.SetPrincipalPolicy(
            PrincipalPolicy.WindowsPrincipal);
    }

    [PrincipalPermission(SecurityAction.Demand, Name=@"MyDomainMyUser")]
    private void MyMethod() {
        // statements
    }
}

The statement marked in boldface determines that Windows accounts should be used to identify users; this call should be made only once and should not be made when using applications that provide custom identification systems. The declarative statement prior to the MyMethod definition applies the role-based security policy in a manner similar to CAS statements. Roles can also be enforced using imperative statements, as shown in the following example:

using System;
using System.Security.Permissions;
using System.Security.Principal;

class RoleBasedDemo {

    RoleBasedDemo() {
        AppDomain.CurrentDomain.SetPrincipalPolicy(
            PrincipalPolicy.WindowsPrincipal);
    }

    private void MyMethod() {
        PrincipalPermission x_perm =
            new PrincipalPermission("MyUser", "Administrator");
        x_perm.Demand();

        // statements
    }
}

The statements in boldface create a new PrincipalPermission that specifies the account name MyUser, who is an administrator. The PrincipalPermission class is used in the same way as the permissions described previously in the Code Access Security section of this chapter. Unlike CAS permissions, user identities can also be obtained without using the permissions class; the following example demonstrates how to obtain the identity of the current user and ensure that the user is part of the Administrators group:

using System;
using System.Security.Permissions;
using System.Security.Principal;
using System.Threading;

class RoleBasedDemo {

    RoleBasedDemo() {
        AppDomain.CurrentDomain.SetPrincipalPolicy(
            PrincipalPolicy.WindowsPrincipal);
    }

    private void MyMethod() {
        WindowsPrincipal x_principle
            = (WindowsPrincipal)Thread.CurrentPrincipal;
        if (x_principle.IsInRole(WindowsBuiltInRole.Administrator)) {
            // user can execute code
        } else {
            // user cannot execute code
        }
    }
}

The first statement marked in boldface obtains the identity of the current user from the System.Threading.Thread class, casting the result to an instance of WindowsPrincipal. The second statement checks to see that the user is an administrator. The WindowsBuiltInRole enumeration provides values representing the default Windows groups, as listed in Table 17-4.