| After your application has authenticated users, you can authorize their access to resources. But there's a question to answer first: Just who is the user you are granting access to? It turns out that there are different answers to that question, depending on whether you implement impersonation. With impersonation, the ASP.NET process can actually take on the identity of the authenticated user. Impersonation applies only to applications that use ASP.NET to communicate with the server. For other server applications (such as services and serviced components), impersonation doesn't come into the picture. Implementing Impersonation ASP.NET impersonation is controlled by entries in the applicable web.config file. The default setting is no impersonation. You can also explicitly specify this setting by including this element in the file: <identity impersonate="false"/> With this setting, ASP.NET does not perform user impersonation. This means that ASP.NET will always run with its own privileges. By default, ASP.NET runs as an unprivileged account named ASPNET. You can change this by making a setting in the <processModel> element of machine.config. This setting can be changed only in machine.config, so any change automatically applies to every site on the server (and no site can have a setting different from that of the server) when the ASP.NET worker process is restarted. To use a high-privilege system account instead of a low-privilege account, set the userName attribute of the <processModel> element to SYSTEM. So when impersonation is disabled, all requests will run in the context of the account running ASP.NET either the ASPNET account or the SYSTEM account. This is true whether you're using anonymous access or authenticating users in some fashion. The second possible setting is to turn on impersonation: <identity impersonate="true"/> In this case, ASP.NET takes on the identity passed to it by IIS. If you're allowing anonymous access in IIS, it means that ASP.NET impersonates the IUSR_ComputerName account that IIS itself uses. If you're not allowing anonymous access, ASP.NET takes on the credentials of the authenticated user and makes requests for resources as if it were that user. Finally, you can specify a particular identity to use for all authenticated requests: <identity impersonate="true" userName="DOMAIN\username" password="password"/> With this setting, all requests are made as the specified user (assuming that the password is correct in the configuration file). Using Role-Based Authorization Within a Visual C# .NET application, authorization is handled by the role-based security system. But you can also control access to resources directly in your .NET code using role-based security. Role-based security revolves around two interfaces: IIdentity and IPrincipal. For applications that use Windows accounts in role-based security, these interfaces are implemented by the WindowsIdentity and WindowsPrincipal objects, respectively. The WindowsIdentity object represents the Windows user who is running the current code. The properties of this object enable you to retrieve information such as the username and the user's authentication method. The WindowsPrincipal object adds functionality to the WindowsIdentity object. The WindowsPrincipal object represents the entire security context of the user who is running the current code, including any roles to which the user belongs. When the CLR decides which role-based permissions to assign to your code, it inspects the WindowsPrincipal object. One way to manage role-based security is to use the IsInRole() method of the WindowsPrincipal object to determine whether the current user is in a specific Windows group. The results of this method call can be used to modify your application's user interface or perform other tasks. For example, the following code segment verfies the role membership in the administrators group: // Tell the CLR to use Windows security AppDomain.CurrentDomain.SetPrincipalPolicy (PrincipalPolicy.WindowsPrincipal); // Get the current principal object WindowsPrincipal prin = (WindowsPrincipal)Thread.CurrentPrincipal; // Determine whether the user is an admin Boolean admin = prin.IsInRole(WindowsBuiltInRole.Administrator); // Display the results on the UI if(admin) lblMembership.Text = "You are in the Administrators group"; else lblMembership.Text = "You are not in the Administrators group"; The IsInRole() method can be invoked in the following three ways: IsInRole(WindowsBuiltInRole) Uses one of the WindowsBuiltInRole constants to check for membership in the standard Windows groups. IsInRole(String) Checks for membership in a group with the specified name. IsInRole(Integer) Checks for membership in a group by using the specified role identifier (RID). RIDs are assigned by the operating system and provide a language-independent way to identify groups.
An alternative way to manage identities is to perform imperative or declarative security checking with role-based security by using the PrincipalPermission class or the PrincipalPermissionAttribute attribute. For example, the following code segment verfies the role membership in the Developers group using the PrincipalPermission object: // Tell the CLR to use Windows security AppDomain.CurrentDomain.SetPrincipalPolicy( PrincipalPolicy.WindowsPrincipal); // Create a new PrincipalPermission object // This object matches any user in the Developers group PrincipalPermission pp = new PrincipalPermission(null, "Developers"); // See whether the user is in the group try { pp.Demand(); MessageBox.Show("You are in the Developers group"); } catch (Exception ex) { MessageBox.Show("Exception: " + ex.Message); } Checking permissions by using role-based security is very similar to checking permissions by using code access security. The difference lies in what you are checking. The constructor for the PrincipalPermission class accepts both a name and a group name, so you can also use it to check whether a specific user is running the code. | 
