5 Reasons RBAC Projects Go Wrong

We were discussing the main causes of RBAC projects failing this week at Oxford. The discussion is sure to go on, as there are probably as many reasons for failure as there are roles in most organizations (which is many), but I offer here five of my personal favourites. Before I elaborate though, we should first perhaps clarify what I’m talking about when I mean “an RBAC project” (as others may have different definitions or mental models)

I’m assuming here we are talking about enabling or facilitating enterprise RBAC and that our architecture comprises some or all of the following:

• Some applications that have an internal security model that uses roles for managing access to resources (like SAP or other ERP applications)
• One or more enterprise directory (Active Directory or LDAP, or both) that stores users in groups that are then used for authorization purposes by applications that don’t have internal roles
• The applications that use the above directories (and there are plenty of them now) for authorization data
• An authoritative source of identity data: perhaps (but not exclusively) HR for employees, an enterprise directory, or an IAM application or portal

Into this we are looking to deploy a roles management system that will:

• Define, keep and maintain representations of roles
• Automatically decide who gets what roles (and their associated permissions) in some cases, and allow manual administration in others
• Have some kind of workflow for approvals and notifications
• Provide feedback in the form of audit logs, reports, and (possibly) some kind of dashboard

Our aim, in our project, is to deploy this system and almost certainly hook it up to some form of provisioning or identity synchronization service to automatically deploy and manage user accounts and permissions in our enterprise applications and directories. By doing so we aim to reduce the administrative effort associated with managing our application roles and to provide an enterprise-wide view of permissions, thus enhancing security and helping us to comply with regulations such as SOX. We might perhaps also create enterprise roles that comprise many application roles, groups or other permission sets (listen and watch my webinar on pragmatic roles for more about this).

In my experience, the main reasons that roles projects fail are as follows:

1. For the same reasons other IAM projects fail: lack of executive buy-in, trying to do too much in one go without a clear set of prioritised requirements, and poor project management. See my trainwreck article for more details on these.
2. Not allowing enough time and resources for role mining. You need to allow lots of time to extract all your various application roles from their applications, and you will need support in the form of a business analyst and some technology (either a role-mining app like Eurekify, or do it yourself with ILM and SQL). Armed with these, you then need to probe your key applications and winkle out the roles and permissions buried within.
3. Not grouping application roles into enterprise roles. If you don’t group application roles into the logical wrapper of an enterprise role, you probably will end up in the apocryphal state of having more roles than people. It’s inevitable that you have lots of application roles, but the aim is to make these manageable by normalizing them into one enterprise role per organizational role (if such a thing exists).
4. Worrying too much about NIST-compliant RBAC. Whilst NIST-compliant RBAC remains a worthy goal, I believe that it can sometimes act as an inhibitor for people who should really just crack on and make a start with a few enterprise roles, or just enabling some simple role-based provisioning. If your roles management tool doesn’t support inheritance or segregation of duty, so be it. Just get on with it anyway.
5. Getting bogged down trying to define organizational roles. Again, these are nice to have. If our HR system contained a list of the 300 company-approved roles and every user entry in the system had one (and only one) of these roles, it would be easy to deploy a data-driven provisioning system that could read and act on them. But life is rarely that simple and if you work in a dynamic (dare I say chaotic) organization that changes often and re-engineers itself on a regular basis, you may never get to this stage. As with NIST-compliance, waiting for HR (or those very expensive BPR consultants they have hired) to define every possible role every employee might ever have before starting with some role-based provisioning is a bit like waiting for Godot. And he never comes.

Bear in mind here that I’m a pragmatist rather than a visionary. I don’t believe in waiting until things are perfect before I act. I like to roll up my sleeves and crack on to try and make things better, even if it’s just small incremental improvements, it’s better than nothing. Sometimes this means I discover halfway through that I need to stop, take stock and then reappraise, or even do some rework. But in my opinion that’s still better than waiting for perfect conditions to appear before starting: they seldom do.