Comments on: Don’t Do Role-Based Authorization Checks; Do Activity-Based Checks

By: Jason Dang

Jason Dang — Tue, 07 May 2013 12:54:00 +0000

I dont agree with the author since the Enterprise Library has Unity block which allows us to inject the Authorization mechanism into the biz classes. That make our security mechanism very clear, loose-couple and easy to add custom roles. Your code seems to be outdated.

By: Jeff Shurts

Jeff Shurts — Sat, 09 Feb 2013 20:33:00 +0000

Software development is one of those disciplines where there always tend to be a thousand ways to solve a particular problem. Of those thousand, 990 are usually pretty bad, and any of the remaining ten will serve you pretty well.

Authorization (access to features) in an application, whether it’s a web, desktop, or mobile app, is one of those problems that clearly has one best solution – tackling the problem any other way represents a compromise that you’ll regret somewhere down the road.

That one best solution is the one Derick describes above. Just do this. If you don’t, you (or those who have to maintain your code after you move on) will be forever frustrated.

For those of you wanting a more elaborate example, just go watch the Railscast on the CanCan gem (which is referenced above, and incidentally, was authored by Ryan Bates, the man who brings you Railscasts). Even if you’re not a Rails person, you’ll get the concept. It is, after all, quite simple:

NEVER INQUIRE ABOUT THE CURRENT USER’S ROLE IN APPLICATION CODE. EVER.

Do not let complex and tedious authorization rules (“who gets to do what?”) become scattered throughout your code base, never again to be understood in their entirety. Because one day a new product owner will ask you for a list of said rules. You don’t want to be scanning your code base looking for calls to User.getRole() or some such. There are far more entertaining ways to waste time.

By: Chris Nevill

Chris Nevill — Mon, 04 Feb 2013 16:58:00 +0000

Excellent article. Would love to see a working solution.

In my ideal world at the moment I’m looking for something that allows me to have it such that all actions are not authorized until a combination of an activity has been defined for that action, a role has been given access to that activity. A user assigned that role would then be authorized for that activity.

I’d like control of where the users credentials are stored, so that they can be stored in my database. I’d also like the database to tie the activity’s and the rolls, so that I could simply change the database to change where users with a certain role can and can’t go.

I’m sure there must be a nice ‘simple’ solution for this somewhere. I’m not feeling confident about rolling my own yet.

By: kkkk

kkkk — Mon, 31 Dec 2012 10:02:00 +0000

In the end that is what RBAC is all about. http://csrc.nist.gov/rbac/rbac-std-ncits.pdf

By: likethesky

likethesky — Tue, 30 Oct 2012 22:44:00 +0000

Sorry to resurrect a year-old thread, but YES! I am about to implement a system similar to what @ttutko:disqus describes here, which is that Administrators are able to assign to new users what I call a “sub-admin” role (with that name being a role which is semantically the same or–most probably–*less* than “Administrator”, with a corresponding set of the same or less [data] items [as available to Administrator] and with the same or less permissions on those items–jointly, these last two [items & permissions on them] define an “activity” [as @derickbailey:disqus defines it in the original post here--I think!] that then either can -or- can’t be performed by that [sub-admin] user).

Then–in my system–this sub-admin user should be able to further sub-assign other sub-admins or sub-users (the only distinction between sub-admins & sub-users being whether they can further assign users; sub-admins can assign *the same or less* rights they have to other users, sub-users cannot–it’s really just another permission that is strictly on the User model/resource). Anyway, I digress…

Anyone know of any GitHub projects that do something similar (or @ttutko, have you open-sourced any of your system–or do you plan to? Or could share some snippets of code for it)? I’d be most interested in anything done using CanCan/Rolify in Ruby/Rails, but am open to any solutions that implement some form of this nested system, with sub-admins able to further delegate the same or ‘tighter’ permissions for resources (uh, I mean ‘items’) that they have those (or greater) permissions to already.

One question I have is–let’s say there are a dozen ‘items’ with the four main CRUD actions on them (defining 48 possible activities) and of course we will be adding more ‘items’ to these dozen all the time. Should I just create a ‘custom role’ (hash into the 4 x 12 table of ‘checkmarks’) in Rolify for whatever permissions any particular user is given by a sub-admin (meaning, create a new ‘custom’ role each time some combination of those 48 ‘checkmarks’ are checked by a sub-admin for one of their sub-users/admins–we would share a combination that reoccurs, of course)? Or better to just keep adding the ‘items’ x 4 into a separate table linked to from the User table itself? IOW, not use custom roles at all for these sub-permissions/activity-based authorizations, but simply make that ‘hash of permissions on items’ a part of the identity of that user?

Thanks all!

By: Manfred Lange

Manfred Lange — Sun, 09 Sep 2012 02:24:00 +0000

Derick, I like in particular your approach of thinking in terms of activities as opposed to roles. I gave it a try and it is driving the design of systems in a much better direction. Thank you for sharing!

By: Shurller

Shurller — Sat, 18 Aug 2012 18:35:00 +0000

Can you explain further how you achieve this? Or better still if you can share your sample code.

By: Spamme

Spamme — Thu, 16 Aug 2012 12:47:00 +0000

Nice article, alas you don’t give any sample project from where people can begin, it would be very useful.

By: rbac_abac

rbac_abac — Sun, 24 Jun 2012 00:10:00 +0000

Modern authorization architecture is based on XACML processing model (where the authorisation system provides distributed, embeddable PDP — policy decision engine).
That engine must be consulted by the application before the end user gets to access a protected resouce:
checkAuthorisationAccess(user, activity, target_resource, application-context-attributes) would return allow or deny
The application must not even be aware of the roles that a user has (storing the roles, and interpreting them is the job of PIP and PDP). PDP engine also implements what’ is caled ABAC (attribute based access control, typically by embedding a light weight rules engine).

By: Anonymous

Anonymous — Tue, 29 May 2012 13:06:00 +0000

I share your sentiment here, we realized this problem years ago. Indeed I’m very surprised that you didn’t mention the biggest paing we had with role based security, what about dynamic roles?

What happens when the client wants to change dynamically roles and assign then different permissions overtime? The whole role based security fails when dynamic roles appear.

So, in essence we did the same as you, as we allowed dynamic roles to be created, we needed to check some other fixed point, so we decided to check directly for permissions.

As you did, our permissions represented activities in the systems, so we are doing the same here.

I still think that the whole role based security is broken, and only works for very simple scenarios that do not change over time. But what scenario does not change over time?