Last post

December 20, 2007

This will be the last post. I’ve moved over to now



5 Reasons RBAC Projects Go Wrong

December 7, 2007

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.

My new site

December 5, 2007

I registered my own name as a .com domain recently. I was amazed it was still available, but I imagine there aren’t that many Dave Nesbitts in the world – or at least none vain enough to register their own .com domain. I was tempted to register some for my kids too, but unfortunately, only two out of three could have .coms and the other would have to make do with a Talk about modern dilemmas… Do I register the .coms and the or do I get them all so that no-one is favoured?

Anyway, I’ve been moving my content over from here to there slowly and playing around with formats and other content. Take a look – it’s

I’ll probably move over there permanently fairly shortly, so the many thousands of you who are subscribed to my feeds will need to adjust your settings and come on over.

The DIM Report Lives Again

December 4, 2007

Not my temporary Blogspot blog, the original DIM Report is back in all its tawdry glory (real or imagined)!

I’ve recently registered my own name as a domain ( and whilst I’m still fiddling about with themes and trying to decide whether to use WordPress or Drupal as my CMS, I thought it might be fun to put the old DIM Report html up there. All the links seem to still work, and the content is quite an eye-opener. It’s amazing how much has changed in just 3 years, and how much is still the same. Some companies have fallen by the wayside (Critical Path) some have been acquired (Abridean, Waveset, Business Layers, OpenNetwork, RadiantLogic, Netegrity, Oblix, Maxware etc), and some are still going strong on their own, but the basic message has remained the same.

The best way to view it is to click on the “Report” link from the top menu, then select a report at random from the left hand menu.