Migrating from RBAC to ABAC, part 2: Access control fundamentals

Down with the role! That's actually been my motto for quite a while. But getting rid of the role cannot be done overnight. Especially since we are rolling out roles in great numbers. And that, by itself, is not all wrong. Just the pursuit of greater control of authorizations is good. However, as explained in my previous blog, a role is not the most logical, most efficient or most flexible way of managing authorizations. A role is basically just a concept developed to make a translation of business functions to technical permissions. And that requires some quantum leaps.

One of the leaps is that we look at what a person must do and not what authorizations a person needs: When someone has the position of an ‘accounts receivable administrator’, he or she gets the authorization to manage debtors. But that's really a huge mental leap. Actually you should argue just in the opposite way: what tasks have to be done, and then evaluate what access is needed: both for a person and an authorization. That seems trivial, but it is a fundamental reversal of the authorization model.

Access Control in Reverse

Access should really work out this way:

Records of Accounts Receivable should be managed within the finances process. The process owner of this process is accountable for managing this process. The requirements for performing a certain task in that process, as defined by the process owner, are: relevant education, experience, organization (department), location, time of day, device. And perhaps even some extra quality requirements defined by the process owner to ensure that the processing is carried out correctly. For example: that the person executing a task cannot manage his own customer records and that no two critical consecutive tasks in the same process may be performed by the same person. And the process owner defines these rules to prevent fraude and misuse of controls. Yes, this is Separation of Duties. This is where SoD comes from!

If a process owner already captures such a lot of quality criteria, for the process owner it is completely irrelevant to define who may perform the task, provided that the person performing the task meets all criteria. A process owner doesn’t have to define who should receive the authorization, he just needs to be able to verify that someone who performs the job meets all the criteria defined.

Fundamentally different

This in fact is a fundamentally different way of thinking about authorizations. We no longer assume that the user of an information system has the correct role, but that he has to meet the defined criteria, competences and context. And those are the attributes of a person's identity or context. If those attributes correspond to the required quality standard that have been defined in the form of measurable criteria, then there is a match and only then this person may perform the task. And as a bonus… the calculated access permissions can even differ per session, or moment, based on context or whatever dynamic criteria were defined…

So, yes, it looks very logical to adopt such a model. But then other questions emerge:

Where do these attributes come from? And how do we know if these attributes are correct? We will discuss this matter in a future post. And it will imply some serious changes to migrate from RBAC to ABAC. But based on the old Role Model we can imagine a migration scenario from RBAC to ABAC.

As I wrote in the first blog, RBAC is aimed at providing authorizations to people to perform certain tasks. If we can assume that the person who has to perform the tasks effectively meets the quality criteria as defined by the process owner, then we *could* say that this person’s role *implicitly* has the right attributes. That means that we could consider this role as all required attributes… And if so, migration of RBAC to ABAC only is a technical migration:

Instead of logging into the application with a username and password, the user now just connects to a business function through a federated protocol, using a SAML message containing an indication of the identity and the role in the form of attributes. One does, of course, need to adapt the application to allow for access using a federative SAML protocol…

The migration of an application from traditional RBAC (=through provisioning of account and authorizations) means that we just need to change the login facility, because the authorization model in itself does not change. The application needs an interface to be able to parse the SAML message and to map the attributes to the RBAC model of the application. That’s all: Since we still use the Role metaphor, the authorization model and the permissions don’t change.

And of course we need to add an 'Identity Provider', because such specific component must generate the SAML message that contains the ‘traditional’ user identity (account) and role (as an attribute). In a future blog I will expand on this, since this may be the most important migration aspect.

Hybrid ABAC model

The new access control model, using a traditional Role in the form of an Attribute, can be regarded as a hybrid ABAC model. Hybrid in the sense that authorizations are still linked to roles, but that modern federation technology is applied. Hybrid means that an RBAC authorization model is used, but that the underlying technology for ABAC, ie federation, is deployed. We no longer provide accounts and authorizations to target applications, we use federation techniques. Real ABAC would mean that we no longer use Roles but just rely on attributes. But this full (dynamic) ABAC model requires some more fundamental changes to access management and ICT infrastructure, ABAC requires a new architecture.

The hybrid model is a pragmatic solution to switch from the traditional IAM technology to the modern technology.

In the next part in this series I will explore more about attributes and information security.