Organizations today are embracing cloud-native technologies to increase time-to-market, scalability and cost savings. A big part of the cloud-native transition is moving legacy systems and architectures to the cloud. With this comes both complexity and new risks because modern applications are often composed of dozens of microservices, housed in containers and hosted on immutable, dynamically scaling platforms like Kubernetes. Security measures and entitlements systems that worked on legacy systems no longer apply. This is especially true for identity and authorization.
Identity-and-Access (IAM) teams are often faced with the challenge of shepherding the transition to the cloud for many traditional identity solutions, providing integration between various internal and external systems and focusing on the authentication of users. Authentication standards and tools, like single sign-on (SSO) multi-factor authentication (MFA) and SAML were developed to address these challenges and have evolved to provide the patterns to allow a user or service to login or authenticate to ascertain who a user claims to be.
IAM teams can utilize these tools and frameworks to assure with a high degree of certainty that the user authenticating is who they claim to be. Authorization, understanding and controlling what actions or resources a user or service can access, on the other hand, has not reached the same level of maturity or understanding. Application teams are still spending many hours each week maintaining and adding authorization to new and existing applications.
This authorization challenge is why Styra created the open source project, Open Policy Agent (OPA), and soon after, Styra Declarative Authorization Service (DAS). OPA is an example of policy-as-code and is a general purpose policy engine that decouples policy decisions from other responsibilities of an application. OPA works equally well making decisions for Kubernetes, Microservices, functional application authorization and more, thanks to its single unified policy language. An example of policy (think of it as a set of rules) is perhaps, what roles are required to perform actions in a system, or authorization—a type of policy that dictates who or what gets to do what in a system.
It is not surprising that the benefits and controls that organizations have been able to achieve with OPA, and policy-as-code in general, within their infrastructure (Kubernetes, Terraform, etc) are starting to be noticed by organizations, and specifically by the IAM teams and the legions of engineers who are tasked with implementing authorization in their applications.
Benefits of authorization in your identity solution
Applying policy-as-code into an authentication or identity solution can provide many benefits, including:
Leverage existing data sources (LDAP, AAD, SCIM, etc.) to make use of your existing investment in IAM. When that rich context is coupled with declarative policy, you can replicate this at-scale to as many clouds, continents, regions, availability zones as you need. Additionally, you will be able to understand the impact of a policy or data change long before you deploy it which will help with down-time, testing, etc.
Having centralized policy authoring, data management, and decision logs, without sacrificing physically distributed enforcement can certainly be a time saver when it comes to making sure you can indeed run at-scale.
The availability to run an instance of the entitlements service (IAM + Authorization) as close to the applications that need them as you like. Plus, distributed policies/data that are kept up-to-date offers an alternative to a single point of failure on-premises solution, and can mean the difference between a fully functional application and a broken one.
While there are several more benefits to making the perfect couple of authentication and authorization work together, the easiest way to do so is to extend existing systems-of-record for IAM, associate declarative policy and enforce authorization decisions across all of your deployment models. This allows you to answer the simple question, “Who can access what under which context?”
But, until recently, there hasn’t been an easy path for IAM teams to either modernize an existing authorization solution, using industry best-practices, or to create from the ground up with a new solution based on industry standards and policy libraries.
Styra Declarative Authorization Service (DAS) for Cloud-Native Entitlements can be brought in to fill the need of organizations where they need a broader set of controls. The understanding is that these controls will trickle down to other areas of the system or organization. For example, using an identity vendor plus Styra DAS gives an organization the ability to extend authorization environments to incorporate different types of data sources from different systems. The organization can then take that information and utilize it in different areas they need to control, not just an app (like infrastructure).
A version of this blog first appeared in The New Stack on March 11, 2022