ASP.NET Roles Authentication - Using Roles as Activities?

Question

I want to go one step further than simple roles based authorisation (Admin, User, Super User etc)

and instead do Activity based authorisation .

My thinking was to assign activities to logged in users which related to whether or not they could perform a action.

For example

CreateUser

ReadUser

UpdateUser

DeleteUser

I would create pages that relate to the above activities

i.e

CreateUser.aspx

on each page i would do a check to see if the authenticated user does in fact have rights to access the activity.

i would do this by making use of Roles.

for example

IsInRole("CreateUser")

Previous to this i could assign the Activities (Roles) to the authenticated user after successful login

My only real concern with this is that by doing this when i authenticate the user and build the authentication cookie it will include alot (potentially) of Roles for each user.

for example i currently have 60 activities in my system (but this could increase as we add more features - each feature is in itselve a new activity)

If the authentication cookie has to carry approx 60+ roles (activities) would that cause any known issues?

Can anyone suggest an alternative approach ?

Answer 1

You may want to look into IdentityModel framework. It has the base class for building a custom Authorize module to verify permissions based on Resource-Action pattern. But this is built for .NET 4.5, not sure what your platform is.

.NET 4.5 also includes SessionAuthenticationModule (SAM) for web authentication. SAM can cache the roles between user calls, so that you don't have to send them back and forth in a cookie. Here is some more information on how it works.

Answer 2

Use Operations and Permissions, as described in Ayende's blog. He has lots of articles on the topic.

http://ayende.com/blog/3109/rhino-security-overview-part-i

http://ayende.com/blog/tags/rhino-security

Answer 3

What you want is a capability list approach.

The solution to this is a mapping of roles to capabilities, similar to this:

>Online             Anon      User       Admin
Article             ReadOnly  ReadWrite  ReadWrite
Article.List        ReadOnly  ReadOnly   ReadOnly
Article.Edit        Hidden    ReadWrite  ReadWrite
Article.Delete      Hidden    ReadOnly   ReadWrite
Article.Title.Edit  *         *          ReadWrite

In practice, these will be your coordinates:

>(system state)

The system may be "Online, Offline, Maintenance" and maybe more. Use the initial > to find the start of your matrix in the file (you'll have many of these). In C# you'll have an enum.

On the same line are the roles:

Anon    User    Admin

Then on the left side you'll have the capabilities scoped into namespaces and actions:

<item>
<item>.<action>
<item>.<field>.<action>
<item>.<field>.<value>.<action>

The cells will contain one of these values:

Hidden, ReadOnly, ReadWrite or *

The * will mean "inherit" from the parent item or field.

This way you'll be able to fine-tune the permissions based on items, actions, roles and the current system state.

A simple parser translating the list into an in-memory structure will do. Don't put this on a DB, it will be a pain. Keeping it on the text-file/in-memory level is better. Add a FileSystemWatcher to read that file whenever it is changed for additional functionality and leverage lazy loading. Also, store it in Application state memory, not in a session.

Remember: the default will be Hidden (not even read access, the item/action will be completely inaccessible to that role.

Your real concern will then be which roles you'll really need (in my experience a role pretty much maps to an UML actor, maybe with some slight variances), and what the items/fields/values and actions really are. When you write an item you can really mean a group of items. There is no need to map the capability list directly unto a database/entity or code structure. The capability list is on a higher language level, it is semantic and bound to the domain, not to the code (I want to stress this because it's the real power behind this approach).

Once you have implemented this approach with a simple parser and helper object (Information Expert Principle is well advised, avoid Singletons) you'll be able to reuse it in many applications.