Roles versus Rules

Visited a great Sun partner to get them up to speed on some of our new releases (Identity Manager 8.0, etc.) and some of the great technology in Sun Role Manager, the former RBACx from our Vaau acquisition. Had a really good question from one of the participants - "So just what is a role and how does it differ from a rule?". It was followed up by "how many roles are just right for an organization"?

Both are excellent questions and I am not sure I am the definitive soothsayer on these answers. But, as I say, information is worth what you pay for it (and you are reading this public blog, so you've just set the value of it).

Rules vs. roles comes up often. As the identity management space continues to mature, this question is being asked more and more. Over the years, most access control has been done via rules. Only recently have roles been a viable alternative (heres a good discussion dated from 2003). Many role based projects have ended up in the weeds when it is found how difficult it is to try and wrestle all of the roles/entitlements/people into an organized logical process. Rules begat more rules.

As the old joke goes, there are two types of two types of people in the world. Those who think there are two kinds of people in the world and those who do not. A kind of Zen joke, but it really points out the problems with rules and roles.

Its gotten to the point that one of our competitors (as pointed out by our partner) is espousing you don't need roles, its just rules. Roles are just nebulous embodiments of rules, therefore not really roles. Kinda of a Koan if I ever heard of one.

So here is my take; roles are real and they contain one or more rules that help to dynamically define them. But roles can also have attributes of their own that are inherited by the assigning of a role. And they can have other roles in them.

Yes, lets clarify. I can build rules to help define access. "If a user has job code = 42, then assign them read/write access to the shipping system". There you have a basic rule that clearly assigns user access. If it helps you define a shipping employee (who always works with that job code), you could say the rule defines the role "shipping employee". Thus the rule and the role are one (have we reached "role nirvana"? Ooohhhmmm).

So thus one could say the rule is the role and thus who really needs roles? Just call it the "shipping employee rule" and everyone gets properly assigned with no roles.

But that is a base use case and if we extend it, we can prove the existence of roles. First, roles can have other rules (AND clause) so a role could be defined as a collection of one or more rules. This has the benefit of abstracting the complexity of the rules (if you have ever written complex joins in SQL, you know where I am coming from). Its easier to say "assign the role of loading dock manager if the employee is a shipping employee determined by the rule, is certified to drive a forklift (check for certification), and has the role of shipping clerk" than it is to go on and write out the gory rules. I get more detailed information from a rules only approach, but quickly get lost as things get more complex. Roles are easier to manage and, more importantly, for non involved users to understand. This means my business teams will understand the role more than a complex set of rules.

The other difference is roles can have attributes of their own that get inherited by the assignment. I may test your user status and qualify you by rules to have a role, but once you qualify for the role, you can get additional assignments. For example, using the above, if you do get assigned as a a forklift operator you get a hardhat and safety glasses. And if you also qualify as the loading dock manager, you also get a bullhorn as well. Additional assignments that are not based on rules, but by qualifying for a roles through rules. Make sense?

Thus, its not rules versus roles, but rules and roles working together.

As to the last point then, how many roles are enough? I can keep decomposing the organization into smaller and smaller roles until roles start to get out of hand (role explosion). So what is the right number? The answer is its up to the customer/enterprise. Its what they feel comfortable with. Credit card companies may be absolutely fine with 100M's credit card users that are separated solely into Green, Blue, Gold, Platinum, and Black card holders. Or they may want to get more granular.

But instead of leaving you with a circular answer again, lets just say I have heard more than one role engineering expert say that as a rule of thumb (I love rules of thumb) if you are getting more that 30% the number of roles versus number of users, you are getting role explosion and you need to drop back ten and punt. That means if you have 10,000 users, if you start designing your 3,000th role, you are probably in trouble and need to rethink your approach. Koyaanisquatsi.

Ideally, you want the fewest roles as possible that meet the needs of the business. Not too many, not too few. Its an iterative process, defining roles and rules, combining old ones, discovering new ones. It will never end. Its a long road to "role Nirvana".

Ooohhmmmmm.
Comments:

Hey Sean, Thanks for writing this note. Being an Instructor for IDM in this part of the world, I have faced this questions from the "Sun Learners" several times:-) I hope you would post more and more information on the Sun Identity Manager 8.0 and more so about the RBAC integrated with it. -Rajesh

Posted by R Rajesh on May 30, 2008 at 04:16 PM EDT #

Interesting article thank you for the post...keep up the great work guys...

Posted by Sesli Chat on May 30, 2008 at 05:00 PM EDT #

Interesting. My understanding was that role is something determined by who only cares about SoD, SOX, auditability, etc. While the rule is something 'Business Analyst' determines. Maybe my understanding was shallow.

Also, thanks for bringing back memory of great movie, Koyaanisquatsi :)

Posted by Katsumi INOUE on June 01, 2008 at 09:56 PM EDT #

Post a Comment:
Comments are closed for this entry.
About

Sean ONeill

Search

Categories
Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today