How to cope with digital identities - Migrating from RBAC to ABAC (part 3)

This is the third blog in the series on the migration of Role Based Access Control to Attribute Based Access Control. In Part 1, I described that in my view RBAC should be considered end-of-life and in Part 2, I described that migration can take place in phases, by first applying a form of hybrid ABAC. Hybrid in the sense that we use the ‘federated’ ABAC technology to access resources, but that the authorization model used is still RBAC.

We need more dynamics

We just pretend that the role is the premier attribute. And if the target system applies the RBAC model internally, implementing hybrid ABAC doesn’t change anything on the internal workings of the application. There is a slight change: you actually do not need a log-in facility: because of the federation mechanism you automatically get the single sign-on feature. And because of the federation mechanism you don’t need to manage accounts in the application anymore. And so there is no passwords or password recovery feature. The application simply receives the identity related data from the "Identity Provider".

Instead of having to log in, a user can simply access a resource, without a user account. That takes some getting used to: a user has no user account in a target system, a user is not a "subject" (an actor), but an object (managed by other subjects in the system). This not only takes getting used to for the users, but also for developers (hey, I there is no user table ...?) And auditors (hey, I have no transaction log per user). No, you have no users any more ... (don’t worry, we'll come back to this later ...!)

But back to the role. As described in the previous blogs, the role basically is a very unnatural concept. A role seems a simple principle from the perspective of managing authorizations, but actually it is a management monstrosity. There are organizations where 'role owners' and 'role management’ teams of many FTEs are engaged in all kinds of operational authorization management tasks. These teams occupy themselves by interpreting business tasks and employee assignment and with all kinds of atomic permissions in information systems, platforms and operating systems. And virtually no-one understands what actually is going on. In the majority of cases a 'Role Owner' simply accepts authorization adjustments proposed by the role administrators, without knowing the implications of the change. And the same is true for auditors. Tip for organizations where supervisors are critical about authorization management: tell the auditor that you implemented RBAC and chances are you are safe for the next audit schedule.

If we forget about the role and just ask the basic question of why authorizations are granted, we can see that a process owner actually doesn’t care about roles or authorized persons. A process owner just wants to define quality requirements, such as:

• Required educational level or grades
• Required Certifications
• Certificate of Good Conduct
• Working experience
• Location and time of day
• Device type
• Fraud and abuse prevention controls

Some of these features, we also use in the traditional RBAC world. Someone may have a role if he or she has a certain level of education and a good conduct certificate. But how does the person who gives the role to an employee know about these criteria? It must be recorded somewhere. A registration of these attributes must exist somewhere in the organization.

Such registrations do exist in most organizations. Think of the HR systems. In these environments it is established that a person has submitted a certificate of good conduct during the recruitment phase. And of course diplomas and certifications can be registered too. And sometimes they are.

We have to tackle a problem here. There are various sources of attributes. But the question is whether these attributes are used and if these attributes are used in time in the existing processes in organizations. I'm afraid that we don’t properly manage these attributes in order to use the assertions with confidence.

If this is the case, how sure can we be that we deploy the right capabilities to achieve the quality requirements defined by the process owner? If an attribute is not valid anymore, how sure can we be that the person who received authorizations based on a specific capability, loses the authorizations if the attribute has expired? Is the authorization mechanism dynamic enough to make ad hoc changes automatically?

The answer is that we can’t be sure. Traditional authorization management processes don’t guarantee this level of control. And that makes sense, the existing authorization management processes are not adapted to use managed attributes. HR / HRM deals with personnel data, reviews, salary payments. But HR doesn’t deal with trainings or certifications. Only when an employee reports that he received a certificate that grants a higher salary, than the registration of this specific attribute will happen. And it happens only if the employee so requests, so at best it is a passive process. That’s not suitable for authorization processes. So if we want to meet the objectified quality requirements of the process owner, we need to get these relevant attributes from someplace else. Why would we not take these attributes from the process where they are managed in the first place? Could training badges and certifications be received from the training institute? If the process owner requests that someone who wants to perform an auditing task needs a CISM certification, then you would need to look at ISACA whether that person is a certified security manager? You can’t get a more dynamic authorization management process.

For our migration from RBAC to ABAC this may not be the highest priority problem, but it does give direction to the migration. We're going to use the silly roles as attributes, but later we're going to decompose the roles into smaller objects. Objects that have real meaning, for which we can find attributes and attribute owners. First within our organization, but perhaps later we can find attribute stores outside of our organization. The first iteration of the hybrid ABAC model is to use the current RBAC role and use that as an attribute. Perhaps we can even use an HR managed attribute, like 'date of employment', that we could use to deduce the experience of the user.

The grand idea is to convert access control through various iterations from roles to attributes. And in that way to move from a static to a dynamic authorization model. A small question pops up: Where do these attributes come from in these first iterations?

In next blog we are going to discuss about managing attributes in an RBAC environment in order to benefit of them in an ABAC environment. Yes, exciting!