Centralization vs. decentralization in authorization

Emme Reichert   ·   Friday, September 29th, 2023

For many years, there has been a conversation around centralization and decentralization of cybersecurity capabilities.

Which one of these should enterprises do, what they mean, and which is better?

This is especially true when it comes to access control.

We spoke with our Chief Technology Officer, David Brossard, and Chief Product Officer Mark Cassetta, to share some of their insight on the conservation of centralization versus decentralization access control and authorization.

Sometimes when you say “centralization”, enterprise teams can have a visceral reaction. Why is that?

David: (chuckles) Well, no one wants to relinquish control and no one wants the responsibility.

When you say centralization in the context of authorization it could mean centralizing decision making, enforcement or policy management/authoring.

Historically, if we go back to 2010, popular opinion was for centralizing decision making with one logical policy decision point (PDP) for the entire enterprise.

That is why many teams wince when talking about centralization because there would be one central point of failure; which most enterprises do not want.

However, we know there is no need to have one central PDP. You could actually have any number of PDPs.

Instead of having one central PDP, there could be ten PDPs behind a load balancer so the load is spread ensuring that if one fails, there are nine others still working. This way there is resilience built into the system as well as a failover.

With regards to centralizing enforcement, this concept goes hand in hand with the idea of decoupling enforcement.

A good natural centralized PEP is an API gateway.

It’s also a great decoupled PEP. It’s separate from the apps and APIs, it protects, it can be configured independently of the app’s development lifecycle, and apps do not need to be recompiled to address new authorization needs.

Decentralized PEPs on the other hand tend to live closer to the app, perhaps as a micro-gateway sidecar (still decoupled) or perhaps as configuration in the application itself (as part of a framework feature such as Spring Security) or even right into the application itself (as annotations or even code). That leads to more tightly coupled enforcement points which is usually not the ideal outcome.

When you look at centralizing policy management, that can be a bit trickier. I think everyone wants to have centralized policy management or at least centralized policy accountability or visibility so they know what policies there are in the enterprise.

However, you don’t necessarily want to have one team authoring and maintaining all of the policies for the entire enterprise.

If you do want to have a central team write all of the policies, go ahead, but there is the likelihood it won’t scale.

What’s more ideal is a central policy management tool capable of delegating policy authoring.

Delegating the responsibility is decentralization, but the platform is central.

When trying to decide whether or not to centralize the decision making, enforcement or policy management the core question is: what do you want to achieve? Do you want global visibility of all of the authorization you’ve deployed? Or do you want to know the entire set of policies?

Mark: Historically, as companies grew, they increased the amount of control IT and security organizations had over employee actions, which makes sense in that you avoided a “Wild West” scenario when it comes to IT, but it also tended to slow things down.

I guess the visceral reaction comes down to the word centralization and the control that is associated with the word given the history.

However, it’s not all about centralizing control. You can centralize strategy while empowering decentralization. This approach enables individual teams and applications to take control and write their own policy and even govern it.

What is the argument in favor of centralization? Who typically favors this approach?

David: Let’s look at central policy management for this. I think many companies want to control how things and data are shared, so they likely want more centralized control.

There are also companies that want to enable developers to be as efficient as possible to get their jobs done. Those companies don’t care as much about centralization, they care about the common capability and the reuse of the capability, who writes the policies and where they are stored doesn’t matter as much.

For Axiomatics, those are the customers who purchased our solution not necessarily for compliance purposes – though that’s a plus – but to enable developer efficiency.

Mark: The argument in favor of centralization is to achieve an internal balance between speed and control.

Control usually refers to security while  speed can be the application team or business trying to get to market as fast as possible. No matter what industry or vertical you are in at some point one of those has more of a business impact than the other.

If I am in an industry where compliance is a particularly big pain point, I’m going to value control a little bit more.

In those instances, centralizing and maintaining more control over policy, authoring and governance is likely more warranted because the outcome could be significant fines or jail time for failing an audit or non-compliance.

Those are the organizations that tend to favor centralization.

What is the argument in favor of decentralization? Who typically favors this approach?

David: The argument in favor of decentralization is the acknowledgement that one team can’t scale to write all of the enterprise’s policies.

This is because authorization is a two-sided equation, where one side is the identity piece and the other side is the application, data, resources, and services.

While an IAM team may have full or most of the control over identity, LDAP, and Azure AD, they don’t have control over applications or over building an application catalog.

If you want to do proper authorization, you have to let those teams write their own policies. They know best. That is the argument in favor of decentralization as well as speed and execution.

Mark: When you start to look at decentralization, it starts to become a question of how fast you want things to go and how willing are you to accept that there could be a mistake for which you could be held accountable.

At the end of the day, policies are in place and call back to the central attribute source while the application goes to market, so everyone will be happy.

When you look at who favors decentralization, it tends to be development teams and they favor more of a shared services model.

When you look at the evolution of decentralization, that’s where this whole notion of shared services starts to emerge.

You start seeing that centralized model evolve to a shared services model, where the enterprise establishes a service teams can use and choose from this menu of what you need to be successful in your organization.

What is the compromise to be had here and how do we get to a compromise?

David: You have to strike a balance between policies that you want to manage centrally and those you want application owners to write for themselves.

For instance, a company’s Google Drive is managed by the IT department and globally the company says that they prohibit external sharing.

But they could delegate that role to share drive owners, so now the owners control the ability to allow or disallow external sharing. This enables a product manager to create two shared drives, one for internal documents and one for external documents that could be shared with customers.

The compromise is delegating what can be done, making sure some policies are driven through the central entity and letting some things be controlled by local teams.

When you think about it, it is very analogous to how many governments work. The federal government puts certain laws in place, then the state and local governments decide other things for specific areas.

Mark: The compromise is to think about a shared services model, specifically for and within identity.

That way you look at the major access components: authentication, authorization, some level of auditing and compliance as a service that you are empowering your application teams to use.

You can set the service up with global policies that provide guardrails for teams to stay within so compliance and efficiency can be maintained.

In return, the IAM team gets the control they need and application teams can quickly adopt tooling that will make them safely go faster.

Take the next steps

Request a demo with one of our solution experts to learn more about our Orchestrated Authorization solution.