The truth about Roles, what people won’t tell you about RBAC

I have been at three separate companies as of late that all strive to have the “perfect role model” for their enterprise. This desire is usually coupled with the desire to have some irrational number of roles to show that their role model was successful.

Let’s say your company has 100,000 people worldwide, how on earth could you believe that you’re going to end up with 10 roles?

The answer to the number of roles is generally a product of how you want to create enterprise roles (this includes Business and/or IT roles). There are few options when it comes to designing roles, to list a few:

  1. Bottom-up, Top-down and Intersection Analysis (yawn, that’s so 2009)… and the result being a set of IT roles that map to resources, and business roles that map to the IT roles.
  2. Allow Supervisors to control # of roles, they decide what goes in their roles, and your systems make sure that they haven’t put any “toxic combinations” in their roles.
  3. Use #1 & #2 with a standard set of entitlements that everybody gets based on some organizational data.
  4. Allow a product to analyze your data and suggest candidate roles.
    (All of these mean nothing unless your roles are “in-context”… to be covered in my next post.)

Now comes the part where I give my prescriptive advice on which of the 4 options to use.

The answer: RBAC is art, not science, you should try all of the above, at least see if they pass the litmus test for your organization (better yet, call IDMWorks and we can help you figure it out).

Once you’ve figured out what direction you are going with roles, the next step is to stuff all of that in a product. Might I suggest Aveksa as it is the one of the best products in the industry, and use it to manage your roles, entitlements, segregation of duties rules and certifications.