Use Case: Customer-Controlled Access Policy

You are a large financial transaction enterprise, and you have decades of legacy systems for integration with your customers. You have used Role-Based Access Control (RBAC) to create Roles and define sets of Entitlements that apply to those roles to govern how your customers are able to use those integration APIs.

The Problem

Some or many of your customers did not wish your pre-defined roles and entitlements. They want to have access control that is designed around their business structures and their balance of concerns about security vs functionality. So you have had to build new roles, defining different sets of entitlements, for many of your customers. And when you add new capabilities to your system, you have to add new entitlements defining the limits around those capabilities. And your customers who have customized roles need to have these new entitlements reflected, either added to existing roles, or through the creation of new roles. This gets worse and worse as time goes by. Ultimately, what you are experiencing is Role Explosion.

The Old Way

You keep adding more entitlements, and adding more custom roles for your customers. It represents a considerable time sink for your support team to maintain, update and manage these custom roles.

The Policy As Code Way

First, you will need to do a careful analysis of your existing roles and entitlements - what problem are they solving, and how they interact with your systems. One-by-one, examine your applications and services to determine how they might need to change to create a standardized PaC solution. It is important to note that this is not a trivial challenge. If your existing roles and entitlements set is large, you will need to spend significant amounts of time to overhaul it.

Next, implement your standardized solution with a Policy as Code language (in this case, Rego). The Rego is straightforward, generally mimicking the capabilities represented by your existing roles and entitlements.

“Is User U with Roles X,Y & Z allowed to perform action A?”

And then, by organizing the policy code properly, you allow your customers to create their own variations on your rules. You accept the modified rules, and adapt your policy systems to use the customer-specific rules if available, falling back to the standard rules as a default.

Results

Your development team is no longer the bottleneck for customer-specific change requests. Customers are empowered to make their own policy about their employee’s access. More sophisticated customers are able to use the expressiveness of policy code to create access control that is more nuanced than what roles and entitlements can easily provide (for example, based on attributes such as the size of a transaction or the time of day).

The rules for each customer are isolated from each other, and failures/errors in their rules do not impact the performance of any other customer. Your development teams that supported those customers with custom roles and entitlements is repurposed towards revenue-generating activities.