Customizing a SaaS offering with OPA and Rego

A new way to think about supporting your customers

OK, picture this:

You are an organization that provides a Software-as-a-Service solution. You have built out lots of infrastructure, you have written extensive business logic to solve various problems, and you are successfully making the world better for your customers.

What are some of the problems you are probably facing? As a customer of multiple SaaS platforms, a few come to mind:

1. Your customers have their own philosophy of access control, and it is different from yours, which frustrates them.

2. Your customers internal accounting models are inconsistent with yours, which causes confusion and frustrates them.

3. Your customers have specific regulatory requirements that are low on your priority list, which makes them less likely to buy your services.

Can these problems be addressed with the use of Open Policy Agent and Rego? I believe they can. In fact, I believe that in time, customers will be able to provide their own policies for your system, allowing them to customize it to their preferences, without any action from you at all. Here’s how it might happen:

Step One: Identify Targets

Which aspects of your software solution are amenable to re-implementation as a Policy-as-Code solution? Some classic examples:

1. Access control.

2. The way your customer’s charges are organized and grouped (i.e. your billing model).

3. Regulatory compliance (for example, calculating taxes).

Note: these are just top-of-mind for me, you may find many other policy implementations.

Note 2: Your existing customers will probably tell you what they find frustrating about your service, if you ask.

Step Two: Implement via OPA and Rego

Re-implement one or more of these target areas via OPA and Rego. This will probably take a little time to get right, and you will probably have to rework some of your development processes to handle the addition of Rego, and some of your operational processes to handle the addition of OPA. There will also be some performance challenges in some areas, and some things may just not be easily amenable to implementation in Rego.

Step Three: Allow for customer-specific variations

Once you’re using OPA/Rego to implement the solution, you’re probably calling a URL with a particular path to get to the rules. What if you could call a different path for a specific customer? That would allow you to implement different policies for that specific customer. You don’t have to implement this universally - this could be something where you have a default path for most customers, and special paths for the ones that need them (a database configuration, for example)

Once you have a customer-specific path, your ability to tweak the policy to their needs is much expanded. What’s more, you don’t have to customize your core software to make these changes.

Note: You’ll probably find that you don’t always have all of the data that a customer needs to implement their preferred logic. That will require going back to the dev team. Over time, this should happen less and less.

Step Four: Allow customers to change their own policies

This is the most ambitious step, and we’re probably not there yet from a security standpoint (the possibilities of a customer’s Rego impacting system performance, making malicious URL calls, or affecting other customer’s Rego needs to be carefully studied). But assume that this problem is solved. What happens now?

1. A customer can write their own policy logic, implementing the solution according to their own preferences.

2. They upload that Rego to a server of yours.

3. You validate that Rego as you see fit.

   1. Either by hand, automatically, or both.

4. You rebuild your policy bundle, which now includes this new customer logic.

5. Your system is configured to use a specific custom path for that customer’s policy decisions.

6. Agents discover and accept the new policy bundle.

At this point, your customer is able to ‘mod’ your Software-as-a-Service solution in various ways, without any involvement from you. But in a safe way that doesn’t compromise your software, doesn’t compromise your other customers, and doesn’t require creating a bunch of one-off software implementations within your infrastructure.

Likely Objections

1. This won’t be fast enough.

2. You’re just moving a problem to a different place, not solving it in a new way.

3. Customers won’t be interested.

4. Too risky.

5. This won’t work for the types of customers I have, or the things that they need to be customized.

Speed

There are definitely certain types of problems (data transformation) that aren’t easily amenable to a Policy-as-Code implementation. But given OPAs ability to be deployed ‘next’ to the application that needs it, much of the network penalty goes away. Not to mention the possibility of implementing your software in Go, where the OPA logic can be directly embedded.

Moving the problem around

Implementing this internally, and even customizing the policy logic for the first customer is going to probably be a deadweight loss of your team’s development time. Once you have a second customer who needs a custom solution, I would imagine you’ll start seeing a significant reduction in effort, as well as improved customer retention.

Customers aren’t interested

If you don’t have any customers who would prefer that some aspect of their relationship with you to be customized to their needs, congratulations. On the other hand, if you have at least a couple of customers who have specifically indicated that a certain area of your solution is difficult to work with, this might be a novel way to address that.

Even if the customers aren’t interested in implementing the policy changes themselves (step 4 above), you can still implement the new policies on their behalf (step 3) and potentially save your development team from having to implement a hard-coded solution.

Too Risky

Step 4 might be a ‘bridge too far’ for your organization. That’s fair. Step 3 allows you to create customized implementations for your customers, in a way that remains completely under your control. And this doesn’t lock you out from pursuing Step 4 in the future, should the industry come to the conclusion that this is a viable strategy.

Wrong type of customers

Definitely a possibility. This is mostly going to be a challenge for customers that are either quite large, or working in different countries with different regulatory environments than the one you’re used to. If you’re not interested in targeting those types of organizations, you’re probably fine just the way you are.

Benefits

There are several ways this could benefit your organization.

1. You’re separating your solution into different domains, allowing experts to focus on their specific domain, rather than having to master multiple domains.

   1. for example, application logic vs access control logic.

2. Your organization should be able to respond more quickly to change, because your different development teams (Application vs Policy) can operate on their own independent cadences.

3. Your customers will perceive your organization as more responsive to their needs, and make it more difficult to justify switching away to another vendor.

4. Your customers will essentially provide their expertise to improve the capabilities of your platform, potentially allowing you to address markets that you can’t currently support.

   1. for example, tax calculations in different countries.

Conclusion

Thanks for reading this far. I would love your feedback. Is this a ridiculous oversimplification on my part? A foolish attempt to solve a problem that doesn’t exist? This problem has already been solved, and I’m a moron for not knowing about the existing solution(s)? An interesting idea that you would like to explore further? Let me know at: info@paclabs.io

Note: This article explores a focused subset of the concepts discussed here: