Role Based Security In .NET

[admin]

.NET Framework offers code access security androle-based security to help address security concerns about mobilecode. This article covers some of the features available in role-basedSecurity 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 codeto perform only those operations that the code has permission toperform. CLR enforces restrictions on managed code through permissionobjects. Code can demand that its callers have specific permissions. Ifwe place a demand for certain permission on our code, all codes thatuse our code must have that permission to run
Code can request the permissions it needs forthe execution. The runtime grants permission to code based oncharacteristics of the code's identity and on how much the code istrusted. The level of Trust is determined by security policy set by anadministrator.
.NET has provided the following kinds of permissions:
1. Code access permissions represent access toa protected resource (e.g. HDD) or the ability to perform a protectedoperation. 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 hascredentials that support a particular kind of user identity. Some ofthe 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 amechanism for discovering whether a user has a particular identity oris a member of a specified role. PrincipalPermission is the onlyrole-based security permission.
Type safety and security
Type-safe code accesses only the memorylocations it is authorized to access. During just-in-time (JIT)compilation, an optional verification process examines the metadata andMSIL (Microsoft intermediate language) of a method to verify that theyare type safe. This process is skipped if the code has permission tobypass verification. Verification plays a crucial role in assemblyisolation and security enforcement.
When code is not type safe, the runtime cannotprevent unsafe code from calling into native (unmanaged) code andperforming malicious operations. When code is type safe, the runtime'ssecurity enforcement mechanism ensures that it does not access nativecode unless it has permission to do so. To run code that is not typesafe, SecurityPermission with passed member SkipVerification should begranted.
Security Policy
Security policy is the configurable set ofrules that is set by the Administrators and enforced by the runtime.While determining the permissions to grant to the code, the runtimeexamines the code's identity (e.g.- Web site or zone where the codeoriginated, etc�) to determine the access that code can have toresources. During execution, it ensures that code accesses only theresources that it has been granted permission to access. Securitypolicy defines several code groups and associates each of them with aset of permissions.
Security Policy levels
The security policy levels exist in parallel and are independently managed.

1. Effective permission is the intersection ofpermissions from different levels. If we want to apply FullTrust tocode 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 allowFullTrust for the single code group All Code. Machine level policy isthe default policy. These settings place no restrictions at theenterprise or user level.
ROLE BASED SECURITY
Code access security gives the CLR the abilityto make the decisions. In role-based security, the code can performactions based on evidence about the user and his role. Role basedsecurity is especially useful in situations where the access toresources is an important issue. Role based security is ideal for usein conjunction with windows 2000 accounts.
Principal
The principal is at the core of the role-basedsecurity. It represents the identity and role of a user. ThroughPrincipal, we can access the user Identity from 1) user account typesas windows account 2) passport and 3) ASP.NET cookie authenticateduser. A Role is a collection of users who have same securitypermissions. 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 usersand their roles.2. Generic principals represent users and roles that exist independentof Windows NT and Windows 2000 users and roles. 3. Custom principalscan be defined by an application that is needed for that particularapplication. They can extend the basic notion of the principal'sidentity and roles.
All Identity classes implement the IIdentityinterface. The IIdentity interface defines properties for accessing aname 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 securitycontext under which code is running. Applications that implementrole-based security grant rights based on the role associated with aprincipal object. Similar to identity objects, the .
Authentication
Authentication is the process of discoveringand verifying the identity of a principal. Once the identity of theprincipal is discovered, we can use role-based security to determinewhether to allow that principal to access our code. Digest, Passport,operating system (such as NTLM or Kerberos), or application-definedmechanisms are some of the commonly used authentication mechanisms.
Authorization
Authorization follows authentication. It isthe process of determining whether
a principal is allowed to perform arequested action. Information about the principal's identity and rolesis used to determine what resources the principal can access. We canuse .NET Framework role-based security to implement an authorizationscheme.
Creating GenericPrincipal and GenericIdentity classes and objects
We can use the GenericIdentity class inconjunction with the GenericPrincipal class to create an authorizationscheme that exists independent of a Windows NT or Windows 2000 domain.For example, an application that uses these two objects might prompt auser for a name and password, check them against a database entry, andcreate identity and principal objects based on the values in thedatabase.
A GenericIdentity object can be used for mostcustom logon scenarios. We can define our own identity class thatencapsulates custom user information.
Example6
In this example we are creating genericidentity and generic principal and apply them to our current thread.The results are displayed on console. This code can be used to createan 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;
}
}
REFERENCES1. Professional C# by Simon Robinson et al.
2. MSDN Documentation from http://msdn.microsoft.com/net.
3. http://www.c-sharpcorner.com/Security/ViewPermissions.asp
4. http://support.softartisans.com/docs/safileupdocs/prog_ref_archive_signcode.htm