Introduction

DAC, RBAC, OrBAC, ABAC or GraphBAC? Flagship authorization models evolve regularly and each one brings its share of challenges, promises, and complexity.

Over the last twenty years or so, during which the RBAC/OrBAC models seem to have prevailed, the difficulties of designing, implementing and maintaining an authorization model have remained the same, and there are few examples of perfectly satisfactory achievements.

There are many questions about designing or redesigning one’s authorization model. In these two articles, we try to answer the most frequent ones.

Before we do that, let’s go back to some basic notions about authorization models.

What is an authorization model?

A layer of abstraction…

An authorization model is a layer of abstraction that comes above technical entitlements (application rights, transactions, groups, etc.). It is made up of carefully defined objects (roles, profiles, etc.), with a name in natural language, and often organized hierarchically.

… which simplifies the management of authorizations…

This layer of abstraction makes it possible to rationalize the number of objects to handle.

For the business, it becomes easier to understand the available authorizations and to request or validate the appropriate rights.

For IT and support teams, the burden of allocating authorizations is reduced overall. The implementation of automation tools can support a large part of the daily requests, allowing specific requests to be processed more carefully.

… and improves security

Beyond the regulatory and normative dimensions of authorization management, often highlighted by Auditors during their work, the lack of control of authorizations is an open door to intrusions and misuse of the information system.

Knowing one’s authorizations is a prerequisite for securing them, and the implementation of a model makes it possible to simplify the controls, particularly during review campaigns. It is indeed much easier for a manager to validate the allocation of a meaningful business role, rather than of a transaction with a very technical name.

Overview of possible models

DAC: Discretionary Access Control, aka no model at all!

What if the best model was the absence of a model? In some limited cases, especially if the number of authorizations or users is very limited, one can very well do without designing a model that would add an unnecessary layer of complexity. This implies, however, that the authorizations are sufficiently meaningful.

RBAC: Role-Based Access Control

The RBAC model allows to group the authorizations required to perform a function within a company (business, mission, project…) in “roles”. These roles are then assigned in lieu of discretionary authorizations. They can be organized hierarchically, for example by subdividing “business roles” into “application roles”.

OrBAC: Organization-Based Access Control

The OrBAC model is a variant of the RBAC model in which the entities that make up a company are one of the modeling dimensions. Each user then has one or more roles depending on which team(s) they belong to.

ABAC: Attribute-Based Access Control

The allocation of authorizations via the ABAC model is handled through a set of rules based on attributes related to users, resources themselves, or the environment. This allocation is often “dynamic”, meaning that the authorization to access an application or part of an application is evaluated at the moment the user tries to access it. In practice, it is possible to set up an ABAC model that takes advantage of user’s roles, as in the RBAC model.

GraphBAC: Graph-Based Access Control

The GraphBAC or GBAC model is based on the representation of authorizations using a graph linking objects (file, user account…) through various relationships (link between collaborator and manager, belonging to a structure, possession of a file…). The authorizations are then the result of queries on this graph, which allows to give access to a resource according to its relationship with other objects.

Market vision

The table below compares in a very synthetic way the different authorization models that we have just seen.

Authorization model	Ease of implementation and management of the model	Possibilities	Market presence	Trend
No model	n/a	—	Marginal	à
RBAC	+	+	Very common	Ú
OrBAC	+	+	Frequent	Ú
ABAC	–	++	Rare	Þ
GraphBAC	–	++	Very rare	Þ

The most common questions about authorization models

What should my empowerment model be used for?

Setting up an authorization model can be complex, costly, and time-consuming. Therefore, it is crucial to study the needs in depth and to clearly define expectations. As mentioned in the introduction, the implementation of an authorization model can help address access security issues, meet regulatory objectives, but also simplify the user experience and improve the efficiency of Identity & Access Management (IAM) processes. One of the key success factors for an authorization modeling project is the ability to express the expectations precisely, using KPIs if necessary: reducing the time required for a manager to grant accesses when an new employee joins to 15 minutes, mitigating 90% of risks considered critical, etc.

Who should I involve to build, instantiate, and keep my model alive?

Given the cross-cutting nature and scale of the transformation induced by a change or creation of an authorization model, a strong governance is necessary.

It is preferable to involve a sponsor with high visibility from the EXCOM, who will be able to provide support, and obtain strong engagement from the business, the first concerned by the changes, and from application managers, who will be heavily involved during the design and implementation phases. Key contacts can also be identified, so that they can help different teams within the organization (HR, IT, Internal Control…).

Beyond the project phase, it is also necessary to identify the actors who will be in charge of keeping the model alive. A key success factor in the implementation of an authorization model is the identification of role owners. If each role includes only authorizations from a single application, one can easily to turn to the application manager, but in most cases, each role is made up of authorizations from various applications.

The ideal is to find someone who has both knowledge of business processes, company organization, applications, and an understanding of security rules: it’s a difficult exercise! Otherwise, a small team combining the different area of expertise should be able to perform this function.

Do I have to include “fine-grained authorizations”? The “perimeters”? How granular should my model be?

The world of entitlements is as vast as the multitude of existing applications, and the use cases that an authorization model must cover are numerous.

The topic of fine-grained authorizations and perimeter management regularly comes up during the design phase: should they be included in the model or not? There is no predefined answer.

It is perfectly conceivable, in some cases, to restrict the model only to the binary access to the application (yes/no), and to leave the management of the fine-grained authorizations and perimeters in the hands of the application manager and their team. The request form may then provide a text field to provide additional information. This results in less auditability, but the management of requests is simplified.

If we decide to include the concept of perimeter, we must choose between a cross-implementation, in which we create as many roles as there are combinations between authorizations and perimeters (possibly increasing significantly the number of roles), and a separate implementation, where the authorizations are created on one hand and the perimeters on the other.

It is probably best to deal with this issue separately, even if it means creating roles combined with their perimeter in the future, depending on the real use cases: the resulting model thus has a more reasonable size.

What should I include in my model? What about physical accesses and physical assets?

Including all the authorizations within one’s model is extremely difficult, if not impossible given the wide variety of cases, and for the sake of project efficiency.

The goal of the model must always be kept in sight. For example, if the goal is to improve the user experience when requesting rights, it is better to prioritize the processing of business-oriented authorizations, which are likely to be allocated frequently, over little-used technical authorizations.

In addition, it may be tempting to include physical access (premises, specific rooms, etc.) or physical assets (badges, PCs, telephones, etc.) in its authorization model, as they are part of the means that employees must have to work, just like logical accesses.

Again, there are no major prohibitions, and some companies may well manage access to their premises within their authorization model, but as a general rule, physical access and assets are rarely part of it.

An IAM solution may however help manage them properly:

By centralizing requests, sent to different actors or systems upon arrival of a collaborator. This “arrival package” then includes both logical accesses (accounts and default rights) as well as physical resources.
By providing a reference source for data and events related to a person. This information, especially arrival/departure dates, is shared with badge management systems to manage the badge lifecycle.

We have just addressed four initial questions to carry out a project to overhaul an authorization model. Other questions will be detailed in a second article, to be published shortly.