Role-based Security in .NET

The .NET Framework security sub system exposes different ways and means for managed code to implement security as part of the application design. It not only allows you to have control of the access to the various parts of your application, based upon who you are, but also allows you to control who can access your code and how. The former is called Role-based Security, while the latter is called CAS (Code Access Security). In this article, we'll look at what Role-based Security is ? How does .NET Framework support it? And how can you use it in an application? We'll talk about CAS in our subsequent article.

Understanding role-based security



The principle on which Role-based Security works upon is something that you would be aware of. If you log on to your Windows NT 4/2000/XP/Server 2003 based machine, then you would know that your user account is actually a member of one of the user groups on the machine or on the domain. Examples of such groups include the Administrators, Power Users, Users, Domain Users, Domain Administrators and Backup Operators.

Depending upon the group that your user account belongs to, you are capable of doing different tasks such as: a member of the Administrators user group can create or delete users, while a membership of the Users group will not allow you to do that.

The screenshot above lists some of the built-in user groups that are there on a Windows XP machine. 

The same fundamental that governs Role-based Security is also present in component-based programming, from the days of MTS (Microsoft Transaction Server) to today's COM+. The developers can define roles for code execution and then invoke the IsCallerInRole method against the component implementing IObjectContext interface, to programmatically control

whether the security context of the caller is allowed to access a part of component's functionality or not.

Thus, Role-based Security, in a single line, can be defined as the capability of doing a particular task depending upon what your security context is-it's a functional resource access control. 

How .NET Framework supports role-based security



In the .NET Framework, Role-based Security is based upon the fundamental of Identity and Principal, which is based on the System.Security.Principal namespace. 

Identity defines who you are-and typically, your login credentials (the username and password). When the group to which you belong is conjoined with Identity, it constitutes the Principal. So, Principal = Identity + User's Group of membership



Role-based Security revolves around creating permission objects around the user's Principal object and then requiring that permission object to be validated, that is, ensuring that the caller is what the permission object expects it to be.

The built-in user groups on Win XP machine

When working with the built-in users and groups of the Windows 2000/XP/Server 2003, .NET Framework has classes under the System.Security.Principal namespace that allows you to identify the caller's security context and the Principal. 

The WindowsIdentity class has the GetCurrent static method that returns a WindowsIdentity object containing security context of the caller (generally, the logged in user)

WindowsIdentity MyIdentity = WindowsIdentity.GetCurrent();



string strWindowsUsername = MyIdentity.Name;

The above-mentioned snippet shows how to get the currently logged on user's username, and below is shown the output from the source code that comes with this article.

Similarly, if you wish to enumerate the built-in security roles (that is, user groups) of the OS, you can do so using the WindowsBuiltInRole enumeration.

string<> arrRoles = Enum.GetNames(typeof(WindowsBuiltInRole));



foreach (string strRole in arrRoles)


Console.WriteLine("{0}", strRole);

And this is how the output looks like.

Using role-based security in applications



Now that we've seen the basics of Role-based Security, let's have a look at how to use it.

Retrieving identity under which application is running

Suppose, you were to allow an administrator of a machine to access a part of your application, then using Role-based Security, implementing this controlled scenario would be as simple as writing the following code.

WindowsPrincipal wpMe = new WindowsPrincipal(wiMe);



if (wpMe.IsInRole(WindowsBuiltInRole.Administrator) == true)


{


// do something that admin should do


}


else


{


// throw a security exception here


}

In the above snippet, wiMe is the WindowsIdentity object representing the security context of the caller. We create a WindowsPrincipal object around the WindowsIdentity object and invoke the IsInRole method to check if the caller's security context is that of an administrator or not. This is followed by a conditional activity which is done depending upon the user's security context.

The screenshot shows the output upon enumerating the built-in user groups

Similarly, for permissions we can create PrincipalPermission objects (based in System.Security.Permissions namespace), which we can demand depending upon the authenticated state of the current security context and their security role.

Conclusion



The .NET Framework role-based security helps in implementing secure access of your application's design. .NET Framework Class Libraries have built-in classes to leverage the security sub system of the underlying Windows OS. 

In this article, we saw how to utilize and leverage Windows security sub system. However, there are also scenarios when you need roles and users specific to your application, and control access based upon your application's security sub system. In our next article, we will look at how to create such custom application security entities and use them to secure our applications.

Gaurav Khanna www.wintoolzone.com