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.