RBAC challenges

In my last post I described Roles-Based Access Control (RBAC) and its benefits as a basic pattern for developing flexible and maintainable applications in a corporate enterprise environment. As with most things in life, RBAC is not a panacea. There are a variety of situations where it either becomes so unwieldy as to be useless or it just breaks outright. Unfortunately, this is most often in larger, more complex applications where the benefits described are most critically needed. We should not be quick to throw the baby out with the bathwater however - for the vast majority of applications, RBAC is a great solution that supports comprehensive enterprise auditing, identity and access management, rapid secure application development and other aspects of risk management in an Enterprise Architecture. I will attempt to define several of the application scenarios where RBAC begins to degrade or fails so we can begin seeking a more comprehensive solution. I don't get into solutions for the failure modalities since by definition we will need tools other than RBAC to solve them.

1. Row-level security - Applications that have clear business requirements for highly granular security are not great candidates for RBAC. The problem manifests itself as an explosion of roles and/or realms. We need to be careful to challenge our business partners up front in the SDLC - an application security model should be as coarsely-grained as possible while still meeting concrete business or regulatory requirements.
2. Logical AND security - When multiple role criteria are required to make a security decision, we can run into a similar role/realm explosion. For instance, if we have five different job code roles and thirty field offices that we need to take into account in our security model (e.g. a permission granted to "Sales Managers in the Boston sales office") we can run into implementation issues. We create our set of job code roles (5) and a set of location roles (30) - so far so good. But now what realms to we create? Let's say we create 150 realms representing all combinations of job code and location. With this many realms already there should be red flags being raised, but it gets worse. What roles do we put in our realms. We cannot place the "Sales Manager" role and the "Boston" role in the "Boston Sales Managers" realm, because realm implementations in LDAP-based infrastructures are logical ORs not logical ANDs. The result of the above would be that all Sales Managers across the company and everyone in the Boston sales office would have access to the permissions granted by "Boston Sales Managers" - clearly not what we were after.
3. Rules-Based security - Sometimes we run across security models that require the execution of some algorithm to evaluate the authorization of particular request. For instance, "a insurance claims specialist may only approve claims up to a dollar amount generated dynamically by a business rules engine". Here we are out of luck with RBAC.

There are other scenarios we come across where RBAC is not a good fit, but the point remains:

"First try to create an RBAC-based security model for your application, if you run into problems that cannot be worked out with your business partners you will have to move on to other options"