I’m working on a internal web application (only employees can log in) and need some help figuring out a good approach to handling an individual users permissions to the system.
The system itself is in C# / ASP.NET (4.0 / Webforms / Forms Authentication) / SQL Server 2008 and has several different areas which will have varying sets of permissions. You can think of it in a basic crud scenario (create, view, update, delete) though those would apply to different aspects of the system.
(I do want to mention this isn’t a type of CMS system, so I can’t pick an Open Source Project like DotNetNuke or anything. This is being developed from scratch. I can use open source libraries if they are available though.)
What would be a good approach to designing the User Permission system for a complex system with probably 5-6 different sections that have a good 10-15 different view/update/deletes contained in each section?
The goal here is to make it:
- Understandable for Users (Admins) to use / set up.
- Easy to Maintain Code Wise.
- Easy to adapt as new permissions are needed (different types or in different spots).
There are two approaches that come to mind:
Approach 1:
Try to use the built in ASP.NET Roles system to define the different permissions and manage it from there. I could build custom pages to handle the different areas and assign permission sets to users. I believe that would also allow me to use the current session object by default to contain all of the permissions in the system for a user. (HttpContext.User.IsInRole() etc…).
Now, while I think that method would work, I’m not sure it’s going to be easy to maintain or adapt to future needs. It seems like it’d be the quicker way to get it up off the ground and working but not the best long term.
Approach 2:
Roll my own. In this scenerio, I’d set up database tables to store true/false style permissions for each section of the application. Then I’d retrieve that information and place it in the session and basically access it anytime I need to check if someone has permissions to do something. I’d then build the custom pages to manage the lists, etc..
It seems this approach might be the more maintainable long term solution. It gives me more power in the set up and how it is handled. However, I’m basically still doing the work that the Roles system abstracts away for me in approach 1. I favor this over approach 1 still however.
In the end, I’m not sure if either approach is the best way to handle this. Can anyone help explain to me why either of the above would be good / bad? Or even to suggest a different alternative as to the “best” way to handle it in general would actually be. This is my first major undertaking in this area, so I don’t have a great deal of experience in trying to “secure” an application like this by permissions. Any and all help is appreciated!
Use the built in approach, unless you’ve a specific architectural need not to. If you don’t use the built in one, you can choose to roll your own provider implementations, but you should follow the same templates as the build in system, as it covers a lot of the security caveats that you should think about.
There’s even the built in configuration page for quick and dirty user maintenance.