Using Role Based Access Control in the .NET Framework - Part 2
Vineet Batta here again..
In my last blog I discussed how to use role based access control (RBAC) and described how we can restrict access to the method based on the declarative method. In today's blog I will explain how to use Imperative role based demands. The end effect is the same, but using an imperative demand we can restrict access to a portion of code on a much more granular basis. Essentially, imperative roles based access control allows you to restrict portions of the method,where as declarative demands allow you to restrict the entire method.
To implement Imperative RBAC demands, do the following four steps:
- Add System.AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal) in the code.
- A Try/Catch block to catch underprivileged access attempts and to report errors.
- Create PrinicpalPermission object, with properties set which reflect the restrictions you want to impose.
- A call to PrinicpalPermission.Demand() method.
The first two steps are exactly same as the declarative style, explained in my previous blog but the use of PrinicpalPermission class is very different here. First you create new PrincipalPermission object. There are three overloaded constructors listed below.
- PrincipalPermission(Name, Role)
- PrinicpalPermission(PermissionState)
- PrincipalPermission(Name, Role, Authenticated)
Lets see all this in action in the example below (relate this to steps defined above);
1: void main()
2: {
3: //Step 1
4: System.AppDomain.CuurentDomain.SetPrincipalPolicy(PrinicpalPolicy.WindowsPrincipal);
5:
6: //Step2
7: try
8: {
9: MyApplication app = new MyApplication();
10: app.UpdateUserProfile(334353);
11: }
12: catch(Exception error)
13: {
14: // Have your own robust error handling.
15: MessageBox.Show("You do not have access to execute this method");
16: }
17: }
18:
19: public class MyApplication
20: {
21: public MyApplication(){};
22:
23: public void UpdateUserProfile(int empId)
24: {
25: //Step 3
26: PrincipalPermission myperm = new PrincipalPermission(null,@"domain\SuperUsers");
27: //Step 4
28: myperm.Demand();
29:
30: // Code to implement the feature here.
31: MessageBox.Show("You have access");
32: }
33: }
Let me explain step 3 and step 4 from the above code.
Step3 - The first argument to PrincipalPermission constructor is null, which indicates that no particular name is required. The second parameter specifies the role to which the users should be part of, so that the runtime can execute the code. In this example the user should belong to "domain\SuperUsers".
Step 4 - The call to Demand() method will check for permissions as set in PrincipalPermission constructor. If the user does not have permission, the runtime will throw security exception. It's that simple to use Imperative RBAC to restrict access to code.
Another scenario..
What if you want to branch execution of code based on the user's group membership? In this case you should use System.Security.WindowsPrincipal class. The code snippet below demonstrates its use.
1: //Create a WindowsIdentity object representing current user.
2: WindowsIdentity currentIdentity = WindowsIdentity.GetCurrent();
3:
4: //Create a WindowsPrincipal object representing current user.
5: WindowsPrincipal currentprincipal = new WindowsPrincipal(currentIdentity ;
6:
7: if(currentPrincipal.IsInRole(@"domain\SuperUser"))
8: {
9: // If the user belongs to "domain\SuperUser" group then execute this code.
10: }
11: else
12: {
13: // else execute this code.
14: }
When Would You Use the Different RBAC Techniques?
Each technique ultimately accomplishes the same goal but each should be used in different circumstances.
| Condition | Preferred Technique |
| Restrict access to an entire method. | Declarative RBAC |
| Restrict access to all or portion of the code. | Imperative RBAC |
| Branching code based users group membership. | WindowsPrincipal.IsInRole |
Back in a few days with more on securing the applications. Stay tuned.....