Implementing Role Based Security using C# - Design Principles to Implement Role Based Security
(Page 4 of 4 )
In this article I covered three different ways to access code based on a user’s membership in a group. These ways were 1) WindowsPrincipal.IsInRole(), 2) using declarative demands and 3) using imperative security. Each method serves a purpose and should be used in specific scenarios.
If you need to restrict access to an entire method, you should use Declarative security. If you need to restrict access to an entire method or portions of a method, you should use Imperative security because it gives you finer granularity. If you need to perform different actions based on a user's role, or you need to restrict portions of code, you should use WindowsPrincipal.IsInRole().
There is one more point to consider: maintenance. Declarative security is slightly more secure because it protects you when changes are made to the code in the future. Since the scope is for the entire method, any changes to the method will continue to be restricted by the security declarations. If you’re using imperative security you run the risk of code changes being made in sections of the method where unauthorized users could execute code. This typically occurs when changes are made to code outside of a try block.
The GenericPrincipal and GenericIdentity Classes
There is one more set of classes that need to be mentioned – the GenericPrincipal and GenericIdentity classes. These classes are based on the IIdentity and iPrincipal interfaces and implement only the basic functionality of those interfaces. GenericPrincipal and GenericIdentity are used to create custom identities and attach them to the current thread (remember that each thread runs as a user with its own security context).
The primary use of these classes is to assign group membership to users when you are using Forms Authentication, and not relying on users to have Windows domain accounts (typically used on Web applications where your user base is people outside of your company). In this scenario you have user ids and passwords stored in a database. When users log in they authenticate with the data in the database. But this does not give your running application the security information it needs for these users. To get around this problem you create an identity object for the user with the GenericIdentity class and specify the groups to which the user belongs. The next step is to create a GenericPrincipal object and assign the user’s access rights to the current thread. Then the rest of your application can execute using the security context you established for the user.
Conclusion
In this article I covered the basics of implementing Role Based Security (RBS) in your applications. RBS is the ability to limit application access based on a user’s role and is an example of applying the principle of Defense in Depth – implementing multiple levels of security to provide the maximum amount of protection to your application. During design you’ll have to decide which method you’re going to use to implement RBS (WindowsPrinciple, Declarative or Imperative). The GenericPrincipal class is used to associate identity rights to users when Forms authentication is used. Whatever your scenario, the .NET framework has the tools you need to secure your applications.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
/ 17 
