Future-Ready Access Control: Modernizing IT Security at Rabobank

Customer Identity and Access Management (CIAM) is a complex problem to solve for authorizations. We can’t solve it with a simple Role Based Access Control (RBAC), since customers don’t have a role in their online banking environment. Their authorizations are often derived from product ownership and legal representatives. Sometimes authorizations are also given via user attributes.

Enhancing CIAM with PBAC and ReBAC

To meet the requirements from both customers and EU legislation, Rabobank focuses its CIAM efforts on further enhancing its two main activities:

• Policy Based Access Control (PBAC): Uses policy evaluation based on active policies to provide access to a resource. The policies can combine roles, attributes and environment to create fine grained access control.
• Relationship Based Access Control (ReBAC): Using a graph model, we store all authorizations as relationships between subjects and their resources. This model is extremely powerful in deriving relationships between entities using modern graph database language.

The basics of Policy Based Access Control

PBAC uses a policy decision point to match existing policies with an attribute store that holds information on the subject or the resource. PBAC supports comparison of policies in various access control types, depending on how the policies are defined and in which language they are written. For example, we can use a subject’s role, their name, their age, or their relationship with the resource.

Core architecture of PBAC

The PBAC architecture proposes 5 core systems to manage access control:

• Policy Enforcement Point (PEP): Gateway for all access requests for internal resources. Manages the traffic towards the PDP and the results.
• Policy Decision Point (PDP): Evaluates access control requests against the available policies and the attribute stores.
• Policy Storage: Storage of active policies to be evaluated, written in a policy language and stored in a database.
• Policy Information Point (PIP): Storage for attribute values not delivered by the PEP but mandatory to evaluate access requests by the PDP.
• Policy Administration Point (PAP): Manages the creation and updating of policies.

Introducing Relationship Based Access Control

Using PBAC, it can be particularly difficult to evaluate policies against a subject when the subject is not just a natural person. A user of an organization may have many legal entities connected to it. Even managing a child-parent relationship in a database without a graph API can be challenging.

Using ReBAC, we can define our model as a graph and write policies as relationships between a subject and a resource. We can also extend these relationships to the resource by defining relationships between two subjects or organizations. As a result, all the subjects with a relationship leading into a resource could receive access to that resource.

In the picture below, we define relationship access for the organization's products, giving access to the owners of these resources. The relationship can be extended to the owners of the organization. Subject B, since they are not an owner of the organization, will require the employee relationship access to be defined before receiving access to any resources. Other relationship access we can define are the owner relationship between Subject C and the student account, and the parent relationship between two subjects.

Conclusion: going forward

Both PBAC and ReBAC can implement specific access control patterns depending on the Customer Relationship Management (CRM) model as well as the complexity of our policies and attribute stores. As the Rabobank CRM model is both diverse and complex, we will require a combination of these patterns to deliver the right authorizations to each type of customer.

In future tech blogs, we will look at open-source libraries for PBAC and ReBAC.