When it Comes to Roles, KISS*
*Keep it Simple, Stupid
The National Institute of Standards and Technology (NIST) model on Role Based Access Control is a fascinating document (http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf). It is loaded with explanations of many important basic RBAC concepts such as Separation of Duties, “permission-role review” that is effectively comparable to user-role review, non-specificity of revocation rules in the standard, etc. Additionally, the standard offers a flat model, a hierarchical model, and a symmetric model with both arbitrary hierarchies and limited hierarchies along with all the charts and diagrams you could possibly want. However, it seems to this IAM professional that the authors have never been down in the trenches and implemented in the real world an Access Governance solution that relies on roles.
Many professionals have given up on roles. Due to the complexity of the standards and the difficulty of applying them in the real world, many projects that sought to implement an optimal RBAC compliant solution across the enterprise have failed. And they have been expensive failures.
In fact, in my experience successful Access Governance implementations need not be excessively complicated in order to succeed. In fact, the more conceptually complicated the proposed solution, the more likely it is that the implementation will not be successful. Additionally, even if the solution does ‘go live’, the end users won’t understand it and the business-buy-in won’t be there to maintain it.
I believe that a simple paradigm works best and is effective even in large organizations. Scientific, non-flexible, highly-detailed rules based expectations for soup-to-nuts automatic provisioning and deprovisioning are, in my experience, doomed to fail. It is this lesson that has driven me and many others to Access Governance solutions combined with a simple, yet effective roles schema.
The schema that I have used is not complicated and has two main layers of roles: Business Roles and Application Roles. Business Roles represent the groupings of users that the “business” uses as reference points to gauge what type of access that group of users should have, for example “Users in Accounting”, “Users on the 3rd Floor”, “Vice-Presidents and Above in Sales”. Technically speaking, these types of roles are defined by Identity attributes such as job title, geographic location, department, cost center, etc. Often these types of roles are referred to as Job Roles, Job Functions, Functional Roles, Geographic roles, etc. What you call these roles doesn’t matter. The important part is that they are defined by user attributes. These roles can be flagged for use as Birthright Roles or Requestable Roles or both.
The second type of roles, Application Roles, are also commonly referred to by a zillion different names. Entitlement roles, IT roles, Resource roles are all commonly and interchangeably used. Some organizations differentiate these terms and have them refer to different types of grouping of entitlements. The important part is that they are defined by groups of entitlements. These roles are then assigned to appropriate Business Roles. Additionally, Application Roles can be flagged as “requestable” as needed.
This paradigm is also espoused by the leading Access Governance products though all acknowledge that riffs on this pattern can be accommodated.
I am incredibly curious to know: has anyone out there really succeeded using a radically different approach? Have you had success assigning both identity attributes and entitlements together in a single role? This has not worked out well for me!
Have you used a hierarchical approach and nested Business Roles inside Business Roles or Application Roles inside Applications Roles? Have you used inheritance to simplify your life? This has also not worked out well for me!
Keeping it simple, easy to explain, easy to maintain and easy to enforce has made all the difference in my projects. What has worked for you?