ASP.NET: Permission/authentication architecture

Question

I looking into building authentication in my ASP.NET application with the following requirements.

• A user has exactly one Role (i.e. Admin, SalesManager, Sales, ....)
• A role has a set of permissions to CRUD access a subset of existing objects. I.e. "Sales has CREAD, READ, WRITE permission on object type "Products" but not DELETE"
• Somehow I like the permissions to be in a hierarchy with inheritance so that I for i.e. Admin don't need to specify all available objects.
• The system must quickly be able to answer the question "Does user X have permission to do Y to object Z"
• All database managed (MSSQL), implemented in C#/ASP.NET

I lite to get feedback on these requirements? Ideas how to implement this using as much as possible of the ASP.NET framework? (but I'm also interested in how this can be achieved without Memberships)

Answer 1

The membership API provided since ASP.NET 2.0 should suit your requirements well. The only thing I'm afraid it doesn't directly support is hierarchical roles. However you can easily use normal role based security with another manually written hierarchical roles table to achieve the required things.

Answer 2

You can read on how to set up ASP.NET Membership here: http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx

It allows you to group folders / pages etc into Groups / Users. I think you will find this sufficient!

The hiarchy is easily managed by extending the generated databases and procedures.

Answer 3

I think what you need to do here is implement a set of permissions query methods in either your business objects or your controller. Examples: CanRead(), CanEdit(), CanDelete()

When the page renders, it needs to query the business object and determine the users authorized capabilities and enable or disable functionality based on this information. The business object can, in turn, use Roles or additional database queries to determine the active user's permissions.

I can't think of a way to declaratively define these permissions centrally. They need to be distributed into the implementation of the functions. If you want do improve the design, however, you could use dependency injection to insert authorizers into your business objects and thus keep the implementations separate.

There's some code that uses this model in Rocky Lhotka's book. The new version isn't in Google yet.

Answer 4

I think one of the best implementations that I think will fulfill your requirements is documented here. The only issue is that this hooks into NHibernate, but you can use this as a template to create your own permissions implementation and simply hook into your own event model rather than that of NHibernates Interceptors.

I am working on such a system myself and will blog it once I am happy with it.

Answer 5

I've create a project on CodePlex that makes want you want : http://www.michaelalbaladejo.com/Projects/ASP-Net-Permission-Management-Part-1

Answer 6

I would build the user/role relationship so users can have more than 1 role. I see a 1-1 relationship and I get nervous because I know that even if we don't see a need for it now, someone is someday going to want someone to be both a Sales user and a Customer Service user.

In our customer system, we use roles to layer on stuff like "delinquentCustomer." That way, the original permissions are still valid--as soon as they pay their bill. Worth considering this approach.