If you’re keeping a close eye on developing trends in Identity and Access Management (IAM), you might have started to hear more about Relationship Based Access Control (ReBAC). Is ReBAC important? Could it have benefits for your organisation? Let’s explore a little further.

 

What is ReBAC?

If you are connected with the identity space you will likely be familiar with Role Based Access Control (RBAC), and Attribute Based Access Control (ABAC). These are both mechanisms that allow you to specify how authorisation changes depending on certain criteria – for example roles you are assigned or attributes (values) you might possess. Maybe you are in the ‘Administrator’ or ‘Manager’ group allowing roles to influence the authorisation policy, or maybe you have an attribute ‘type=permanent’ or ‘type=temp’ allowing the attribute to influence the authorisation policy.

Relationship Based Access Control allows the relationships ‘you’ have to influence the authorisation policy and grant access to protected resources.

 

How does Relationship Based Access Control work? Role Based Access Control vs Relationship Based Access Control

ReBAC - Facebook example screenshot

A simple example of Role Based Access Control vs Relationship Based Access Control is one we are likely to all be familiar with; let’s take Facebook as the example. When you make a post or share a picture, you set who can see that post. As examples: closed group (share post within group or to certain friends ‘lists’), friends, friends of friends, or everyone (‘public’).

Role Based Access Control (RBAC)

The ‘closed group’ and ‘everyone’ cases are basic examples of Role Based Access Control (RBAC) – you have a role through group membership (or simply membership) and that grants you access to the post; all users have the ‘Users’ role and so can access a public post. In both cases the subject has a (reasonably) static association with the role. A subject is added to a group, that’s a static definition that can be applied directly to the subject and correlated to the resource (the post in this case).

Relationship Based Access Control (ReBAC)

‘Friends’ is a very different scenario, and is in fact a relationship definition. Much has been discussed about the Facebook graph – this is the mechanism that stores the relationships between items, and consequently defines the relationships that exist.

It’s this relationship mechanism that allows Facebook to share your posts with friends and ‘friends of friends’. Access is granted based on the relationship. The relationship is not defined on the subject or resource object, but on a separate store that provides the semantics required for the relationships involved.

 

Benefits of Relationship Based Access Control

Defining access controls based on Roles (RBAC) and Attributes (ABAC) is well understood, but carries a significant overhead as numbers and complexity increase. Imaging trying to define a set of roles to define ‘friends of friends’ without using a graph structure. Now imagine trying to maintain it!

Defining relationships is very straight forward. Allowing relationships to inform and direct authorisation policies significantly reduces the workload in managing complex interdependencies.

We haven’t yet considered verifying relationships. Defining relationships is quite simple, verifying the actual existence of a relationship between two parties is somewhat more challenging. At a low assurance level, those relationships can be self-declared or mutually confirmed. These are the underlying mechanisms for Facebooks ‘follow’ and ‘friend request’ features. At a higher assurance level, such self-declarations are unlikely to be sufficient in the context of the authorisations that are being granted.

 

A real-world example of Relationship Based Access Control

Let’s bring ReBAC into the business world and look at how we can really deliver significant returns through using relationships.

Suomi.FI is a great example – the Finnish online portal for public services (version 2 of the Katso platform). Here, organisations can use relationships as the mechanism to delegate activities and responsibilities. The starting point is always a trust anchor, and in this case they come from PRH, the Finnish business registry, where the CEO is coupled to the organisation. From this starting point authorisations can be passed, in the form of Mandates, to related parties, with each party identified at a high level of assurance, be they individuals or organisations. The relationships are typically ‘director’, ‘employee’, ‘customer’, ‘partner’ or ‘supplier’.

Suomi.fi example ReBAC diagram

Using an identity class agnostic approach (it doesn’t matter if the subject is an employee, a consumer, or an organisation) coupled with a broad relationship definition set allows rights and responsibilities to be delegated in a manner that would be totally unmanageable using Role Based Access Control (RBAC) or Attribute Based Access Control (ABAC) approaches.

Indeed, in the example above, the Finnish Tax Office reduced average transaction costs from €30 per transaction to €0.20 in the space of 10 years. This saving was driven by the simplification possible from using mandate-based delegation between individuals and organisations in a self-service model.

 

Is ReBAC new?

In short, no! These techniques have been in commercial use since 2008. We are now seeing a broader awareness of the power of Relationship Based Access Control and the savings that can be realised, but this is an established capability that is well proven in commercial deployment.

Ubisecure provides the Identity Platform leveraged by the Finnish Tax Office in the above example, showing the value of Relationship Based Access Control even since 2008. If you would like to see how Relationship Based Access Control could simplify your interactions and significantly reduce operating costs, please get in contact with us.