test

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"

Roles-Based Access Control

Roles-based Access Control (RBAC) is the most basic pattern for an Enterprise Application Security Architecture. It addresses some of the more basic challenges in an Identity & Access Management strategy and, while it breaks down in more complex scenarios, it is a great place to start for companies with application portfolios looking to stop the madness of user provisioning on a per application basis.

Without going into implementation details, the development of an RBAC-compliant security model can be broken down into three steps:

1. Group the users of the application into Roles.
2. Groups the permissions to functionality in the application into Realms.
3. Map the roles to the realms -- giving sets of people access to the appropriate sets of application functionality.

The primary benefit of an RBAC-compliant security model is that it is able to absorb change gracefully. When we consider the dynamic nature of corporate IT systems, having a security model that remains static under many conditions is huge. When you look at it across a large application portfolio, it becomes critical.

HR events are the single largest source of change in IT systems. If you have an application with a set of User and User Permissions tables that need to be updated when an employee or contractor is hired, let go, promoted or transferred you have a heavy drag on your baseline support costs. By expressing application security in terms of roles instead of individuals we allow ourselves a level of insulation from HR events.

A second source of change is ongoing application development and refinement. As new functionality is implemented, we seek to re-use our realms such that the scope of the existing security model is expanded while the model itself remains static.

An important aspect of building out RBAC infrastructure is to clearly define role criteria and ownership. Role membership should ideally be based on objective criteria. A job code from PeopleSoft is a good criteria for a role. "People that Bob says can have access" is a poor defining criteria for a role.

Ownership of roles is also important to have defined clearly. The owner(s) of a role is the person or persons who are responsible for evaluating the criteria for group membership and adding and removing individuals from the role. In the case of roles that are dynamically driven from attributes in an HR or Identity store, role ownership is equivalent to ownership of the attributes or attribute values that underpin the role criteria.

In an enterprise, the business side of the house (not IT) should manage role ownership.

Similarly with realms, ownership is a critical success factor. In essence the realms protect data so data stewards make the best choice for realm owners. Realm membership is often more subjective, but the membership decisions are often only made during a development cycle so more analysis can be applied. A realm owner has two questions to answer in deciding whether to grant a role access to the permissions granted by their realm:

1. Is the criteria for role membership sufficiently objective and, if so, is it appropriate for these people to be granted this access?
2. Given the owner(s) of the role, how comfortable am I that the role owners will maintain the role membership in compliance with the stated criteria?

Where realm ownership resides is usually dependent on corporate culture and structure. It could be the business owner of the data, the data stewards in IT or a centralized architecture governance organization. Given that realm membership changes can have significant impacts that are not always immediately apparent I find that having IT ownership of realms to be the most appropriate, and that realm membership be updated only within the application development process such that IT is able to present to their business partners the potential impact of proposed changes.

The change of realm membership described above is a change in an application's security model that is one of the more radical types that can be elegantly absorbed. The actual usage of realms to secure application functionality is less radical and requires less analysis. For instance, an application's security model has a role "Customer Service Rep I" that has access to the realm "View Customer Data" which provides access to the customer's name, address and phone number. The application is updated to provide access to a customer's account activity. The "View Customer Data" might be simply applied to the new functionality, requiring no change at all to the roles or realms securing the application.

RBAC is a security pattern that provides application architects with a powerful tool for partnering with business architects to describe and implement application security models that absorb change and react to many of the common dynamic aspects of a corporate environment.