Last Updated: Wednesday, 24th July, 2013
Author: Varun Khosla
In the context of this paper, activity is defined as an action that a web application exposes and its users can execute. According to this definition, in ASP.NET Mvc, each public action method can be thought of as a distinct activity. Activity based authorization, which is also known as permission based authorization, proposes that every activity that an application exposes must have a corresponding permission code (unique) for that action. Further, there must be a permission set associated with every authenticated user of the application. This permission set is nothing but a list of permission codes that identifies all the activities the associated user can carry out.
When it comes to authorization – validating whether a user is allowed to perform a specific action – You often see that the default inbuilt approach in ASP.NET is to do a role check. “Are you admin? Sorry, but this action is for administrators only! Access denied!” You must be wondering what’s wrong with this way of putting authorization checks. After all, the privilege level of a user determines the kind of actions he can perform, isn’t it? Absolutely! But if you hardwire privilege level (roles) with actions, you are at a significant disadvantage.
If you carefully observe you would realize that roles are actually a higher-level abstraction. A role is a way to group a set of activities to permit users possessing that role to carry out all those activities. In this, activity is at the lower level in the abstraction hierarchy and by design, the lower layers shall never have knowledge about the higher layer. By associating role with the action method, you are actually breaking this important software design rule.
"So what is the right way to do it?" Glad you asked! The right way is to do the inverse of what you are doing; that is, associate activities with roles and not the other way round.
First, remove role checks from your code, completely. Instead, put an activity check for each action. For doing this,
Note, you can actually live without roles in this approach – you would use roles as a grouping construct, so as to be able to quickly assign the same set of permissions to multiple users.
ASP Security Kit gives you the ultimate flexibility of choosing either of the approaches by introducing a new concept called Implied Permissions.
Remember, while learning how to do activity-based authorization checks you had to make a design choice – either directly assign permission codes to users or, first associate permission codes with roles and then assign roles to users. However, with ASP Security Kit you aren’t restricted with this limitation. This is because ASP Security Kit introduces a new concept called implied permissions. In this design, you don’t have roles as a separate construct. Rather, you have permissions aggregating other permissions. For example, in a real-world scenario, if a user has a right to delete an entity record, he should also be able to edit it. Similarly, if he can edit it, he can also read it. SO you see, there’s a hierarchy in actions – existence of an action implies other less-privileged actions, and that’s the essence of implied permissions.
With ASP Security Kit, you dynamically define what permissions implied by a given permission, and by doing so, you just need to assign the higher-level permissions to users and all the implied permissions are loaded recursively. So, for example, you can create‘Admin’ permission and make every other permission implied by it. As you can see, this eliminates a need for separate role construct while at the same time, gives you more flexibility that is difficult, if not impossible, to achieve if you had roles as a separate construct.
In how to do activity-based authorization checks section above we learnt that to build a unique permission code we can use entity type name and action name. Often we create separate controller for each entity in our domain models and name that controller accordingly. Based on this assumption, ASP Security Kit can automatically infer permission code. This means you don't have to type the permission code and clutter your code with more attributes. Of course, you can completely override this behavior, for a controller, for action(s) or for both.
Note – Inbuilt role based authorization in ASP.NET has no concept of instance awareness.
Any authorization system is not complete in and of itself until you could make it independently work on entity instances (records). Let’s go back to our example of an entity blog post. Suppose you want to assign permissions to users to perform CRUD operations on blog posts. In a real-world scenario, you’d need to do something like this:
So now you need a way to associate permission codes not just with an action, but only if that action is being performed for a specific entity instance.
ASP Security Kit has strong inbuilt support for instance awareness. If you use ASP Security Kit, you can create two kinds of permission codes:
ASP Security Kit gives you this feature built upon existing implied permissions feature. You got it right! If you permit a user to delete an entity instance, he is also authorized to perform less privileged, implied activities (like edit/read) on that same entity instance! Since you specify implied permissions for a given permission, both of these features (implied permissions and instance awareness) together give you the ultimate flexibility of managing who can do what, down to individual entity records.
ASP.NET provides you with basic inbuilt role-based authorization system which is good enough to create simple, small and personal websites. However, SaaS, productivity or line of business (LOB) based web applications demand much more granular control on user activities than inbuilt role-based authorization could offer. Web applications run in a dynamic business environment and must be flexible to accommodate frequently changing organization structures and needs.
Activity-based authorization gives this flexibility by deferring the need to create roles until run time and doesn’t require you to modify your source code just because you need to change role/permission structure. Managing permissions is the job of administrators and not of the developers and activity-based authorization insures that this holds in reality.
Instance awareness is absolutely essential in a multiuser environment in order to make sure that users can only access and modify data that belong to them. It shouldn’t be an afterthought; rather it must be inbuilt with activity-based authorization infrastructure to insure granularity and security.
ASP Security Kit is a complete solution to do activity-based, instance-aware checks for your ASP.NET Mvc applications. Additionally it has many other useful related features that give you complete control of authentication and authorization for your ASP.NET web application that you would never want to turn back to the old way of doing things.