Role Based Security In .NET
By Vijay Patil

.NET Framework offers code access security and role-based security to help address security concerns about mobile code. This article covers some of the features available in role-based Security in the .NET Framework. Before getting into further details of .NET security features, lets walk through some of the key concepts in .NET security.

Permissions

The common language runtime (CLR) allows code to perform only those operations that the code has permission to perform. CLR enforces restrictions on managed code through permission objects. Code can demand that its callers have specific permissions. If we place a demand for certain permission on our code, all codes that use our code must have that permission to run

Code can request the permissions it needs for the execution. The runtime grants permission to code based on characteristics of the code's identity and on how much the code is trusted. The level of Trust is determined by security policy set by an administrator.

.NET has provided the following kinds of permissions:

1. Code access permissions represent access to a protected resource (e.g. HDD) or the ability to perform a protected operation. Some of the code access permissions are:

WebPermission: The ability to make/accept connection to/from the web.
OleDbPermission: The ability to access databases with OLEDB.
SQLClientPermission: The ability to access SQL databases.
UIPermission: The ability to use User Interface.
PrintingPermission: The ability to print.
FileIOPermission: The ability to work with files.
SocketPermission: The ability to make/accept TCP/IP connections on a transport address.
SecurityPermission: The ability to execute, assert permissions, call into unmanaged code, skip verification and other rights.

2. Identity permissions indicate that code has credentials that support a particular kind of user identity. Some of the identity permissions provided by CLR are listed below.

PublisherIdentityPermission: Software publisher's digital signature
StrongNameIdentityPermission: Assembly's strong Name
URLIdentityPermission: URL from which the code is originated
ZoneIdentityPermission: Zone from which the assembly is originated
SiteIdentityPermission: Location of web site from which the code is originated

3. Role-based security permissions provide a mechanism for discovering whether a user has a particular identity or is a member of a specified role. PrincipalPermission is the only role-based security permission.

Type safety and security

Type-safe code accesses only the memory locations it is authorized to access. During just-in-time (JIT) compilation, an optional verification process examines the metadata and MSIL (Microsoft intermediate language) of a method to verify that they are type safe. This process is skipped if the code has permission to bypass verification. Verification plays a crucial role in assembly isolation and security enforcement.

When code is not type safe, the runtime cannot prevent unsafe code from calling into native (unmanaged) code and performing malicious operations. When code is type safe, the runtime's security enforcement mechanism ensures that it does not access native code unless it has permission to do so. To run code that is not type safe, SecurityPermission with passed member SkipVerification should be granted.

Security Policy

Security policy is the configurable set of rules that is set by the Administrators and enforced by the runtime. While determining the permissions to grant to the code, the runtime examines the code's identity (e.g.- Web site or zone where the code originated, etc…) to determine the access that code can have to resources. During execution, it ensures that code accesses only the resources that it has been granted permission to access. Security policy defines several code groups and associates each of them with a set of permissions.

Security Policy levels

The security policy levels exist in parallel and are independently managed.

1. Effective permission is the intersection of permissions from different levels. If we want to apply FullTrust to code group we will have to assign this permission on each of the levels.
2. Each of the three levels has the ability to ban the permission allowed by the another
3. By default, user level and enterprise level are configured to allow FullTrust for the single code group All Code. Machine level policy is the default policy. These settings place no restrictions at the enterprise or user level.

ROLE BASED SECURITY

Code access security gives the CLR the ability to make the decisions. In role-based security, the code can perform actions based on evidence about the user and his role. Role based security is especially useful in situations where the access to resources is an important issue. Role based security is ideal for use in conjunction with windows 2000 accounts.

Principal

The principal is at the core of the role-based security. It represents the identity and role of a user. Through Principal, we can access the user Identity from 1) user account types as windows account 2) passport and 3) ASP.NET cookie authenticated user. A Role is a collection of users who have same security permissions. Role is a unit of administration for user.

Role-based security in the .NET Framework supports three kinds of principals:

1. Windows principals represent Windows users and their roles. 2. Generic principals represent users and roles that exist independent of Windows NT and Windows 2000 users and roles. 3. Custom principals can be defined by an application that is needed for that particular application. They can extend the basic notion of the principal's identity and roles.

All Identity classes implement the IIdentity interface. The IIdentity interface defines properties for accessing a name and an authentication type, such as Kerberos V5 or NTLM.

All Principal classes implement the IPrincipal interface as well as any additional properties and methods that are necessary

The principal object represents the security context under which code is running. Applications that implement role-based security grant rights based on the role associated with a principal object. Similar to identity objects, the .

Authentication

Authentication is the process of discovering and verifying the identity of a principal. Once the identity of the principal is discovered, we can use role-based security to determine whether to allow that principal to access our code. Digest, Passport, operating system (such as NTLM or Kerberos), or application-defined mechanisms are some of the commonly used authentication mechanisms.

Authorization

Authorization follows authentication. It is the process of determining whether a principal is allowed to perform a requested action. Information about the principal's identity and roles is used to determine what resources the principal can access. We can use .NET Framework role-based security to implement an authorization scheme.

Creating GenericPrincipal and GenericIdentity classes and objects

We can use the GenericIdentity class in conjunction with the GenericPrincipal class to create an authorization scheme that exists independent of a Windows NT or Windows 2000 domain. For example, an application that uses these two objects might prompt a user for a name and password, check them against a database entry, and create identity and principal objects based on the values in the database.

A GenericIdentity object can be used for most custom logon scenarios. We can define our own identity class that encapsulates custom user information.

Example6

In this example we are creating generic identity and generic principal and apply them to our current thread. The results are displayed on console. This code can be used to create an authorization scheme for a particular application.

The output of the program is given below.

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

public class Class1
{
     public static int Main(string[] args)
     {

Create instances of generic identity and generic principal class.

       GenericIdentity myIdentity = new GenericIdentity("VijayIdentity");
       String[] myStringArray = {"Manager", "Professor"};
       GenericPrincipal myPrincipal = new GenericPrincipal(myIdentity, myStringArray);

Attach the principal to the current thread.

       Thread.CurrentPrincipal = myPrincipal;
       String strName =  myPrincipal.Identity.Name;
       bool blnAuth =  myPrincipal.Identity.IsAuthenticated;
       bool blnIsInRole =  myPrincipal.IsInRole("Manager");
       Console.WriteLine("The Identity is: {0}", strName);
       Console.WriteLine("The IsAuthenticated is: {0}", blnAuth);
       Console.WriteLine("Is this a Manager? {0}", blnIsInRole);
       return 0;
       }
}