In today’s cloud-native, app-first and remote-first world, it has become a considerably more complicated task to verify a user or a service’s identity and determine policies that say what they are and aren’t allowed to do.

Yet, the first half of that problem is authentication. For the most part, it has already been solved because of standards like Security Assertion Markup Language (SAML), OAuth and Secure Production Identity Framework for Everyone (SPIFFE). These standards help organizations verify that a user or machine is whom they say they are. But the second part of the problem, authorization — deciding what users or machines can or can’t do within the system after they’re authenticated — is a different story. 

Unlike authentication, authorization hasn’t yet been well standardized. This means that authorization policies, tooling, implementation, and even the programming languages used are still completely unique and custom-designed for each individual organization and application. This puts the burden on developers to create potentially thousands of bespoke authorization policies across multiple applications for protection, leading to development churn and repetitive tasks across applications. Not only is this hard work, but it also requires reinvention and lots of operational overhead. It also introduces risk.

Enterprises have been doing custom authorization for decades now. As such, Dev teams may not realize a better way can be found, leaving CISOs and security teams to try to fill in the gaps with compensating controls in other places, like bolted-on privilege management or overburdened authentication solutions. But these silos of policy add more complexity, not less, and can only do so much to truly govern access.

Wasted time and heightened risks  

Imagine if you’re a large financial institution with thousands of applications accessed by tens (or hundreds) of thousands of employees, contractors and other users. The authorization policies that govern access to these applications are varied and complex, and they are mandated by both internal and external regulations.

For decades, these policies have been enforced manually or through hard-coded logic inside of application code. The former provides no guarantee that policies are adhered to and requires costly and time-consuming manual audits. The latter results in a tangled mess of code that few can understand or modify. As business requirements evolve, the rollout of necessary changes is slow and error-prone with both approaches, and the firm’s competitive advantage is impacted.

At the same time, as every organization slowly becomes a software company, developers have more say in technical decision-making and increasingly opt to use the best language, framework, database or execution environment for their use case. This Cambrian explosion of technological choice is great from the developer’s point of view as they get to use the best tool for the job. At the same time, security practitioners are faced with an increasingly difficult technological landscape that must be secured to meet new stringent requirements.

Combining these factors calls for a new approach to solving policy and authorization at scale in large organizations — the old ways of solving “who can do what” no longer apply.

Empowering developers through open source  

Authorization can no longer be maintained through tribal knowledge or custom hard-coded application code. Continuing down this path will only leave developers with more siloed authorization policies to fix and your organization unprotected in the cloud. Like authentication, new standards must be set by the enterprise through open source. And CISOs are helping lead that change by adopting and advocating for these standards.  

The open-source and developer community has adopted Open Policy Agent (OPA) as the de facto standard for authorization. OPA is an open-source technology engine that provides a toolset and framework to unify policy across your cloud-native tech stack. With OPA, you can specify policy-as-code, which offloads policy decision-making from your applications, removing the need for custom hard-coded authorization policies. 

There are three critical ways OPA can help organizations solve for authorization:

1. OPA breaks down policy silos. OPA can act as a decision-making engine for all applications in your tech stack, thereby unifying the authorization policy. OPA uses Rego, a simple declarative language purpose-built for expressing the logic that decides “who can do what” in modern systems.
2. OPA ensures compliance. Make it easier for your developers to modify authorization policies based on compliance regulations. By leveraging policy as code, developers don’t need to make individual policy updates across multiple applications. Instead, developers can make authorization code changes to their OPA policies required for regulatory compliance on certain applications and keep your environment secure.  
3. OPA saves time for developers. OPA acts as a building block that developers can plug into any part of your cloud-native system to enforce authorization policies, making it easy to use. This ability to apply sweeping authorization policy changes across the tech stack ultimately frees up time for developers and, as a result, lowers costs.

Set the standard for authorization 

The current process for authorization will only create unnecessary work for developers to complete.

By setting the authorization standard with OPA, organizations can unify policy, better meet compliance requirements and give time back to developers. With these authorization advantages, developers can focus on what matters most: building innovative applications and driving growth in the cloud.