Authorization has become the latest buzzword in IAM land. Second to none… Well ok maybe second to passkeys. And with renewed attention, many practitioners have been asking great questions about the scale, performance, governance, and responsibility model for authorization. There are recurring questions that regularly come up in IDPro’s Slack #authorization channel. This post aims to address them.
Now, if you’re entirely new to the authorization conversation, don’t worry, we got you covered. Check out these introductory articles that describe the authorization landscape:
- NIST SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations | CSRC
- A Taxonomy of Modern Authorization Models – IDPro
- The year of authorization: lessons learned from Identiverse 2023
- The state of the Union of Authorization 2018
Policy Lifecycle Management, Ownership & Collaboration
Who’s in charge
So you’ve decided to externalize and decouple authorization from your application. You now need to define your authorization policies (whether those end up expressed as an actual policy, ACLs, or a graph is besides the point). But who should define those policies? Approve them? Review them?
Based on past customer interactions, we’ve come to realize at Axiomatics that there are different types of policies:
- Enterprise-wide policies
- Application-specific policies
Additionally, there may be different sources for the policies:
- The compliance & legal teams
- The application teams
Figure 1: Policy Lifecycle Management
Generally, most of the actual policies come from the business or someone who knows the business. That translates to product owners or product managers seconded by business analysts. Those policies that are not application-specific would be defined by the legal and compliance teams. Interestingly, some of these policies may come from standards e.g. PCI DSS, SOX, PSD2… All you have to do is apply them. As a matter of fact, some industry standards (FHIR, HL7) have even implemented their own policies using XACML.
Historically, you’d expect product owners & business analysts to implement their own policies. However, with the rise of *-as-code and lightweight policy syntaxes such as ALFA or Rego, product owners can delegate the implementation of policies to developers. This leads to the main benefit of app/policy co-development and therefore a faster app development time and more cohesion between the app and the policies.
Now that we introduce a hierarchy of policies with varying scope, we also need to introduce a means to collaborate between policy authors. How else can a local product owner be aware of the enterprise policy on money laundering (as an example)? What collaboration, discovery, and reusability capabilities does your authorization platform provide?
What skill set do policy authors need?
A range of skills are needed to write effective and efficient policies. Starting with the plain old English version, you need knowledge of the business application and business rules that need to be applied. Representatives from security, compliance and legal will have their own guidelines or regulations that must be accounted for in the access policies. Finally, you need the technical perspective to make sure access policies are written in a way that will provide the best performance and the technical people will know how to configure the system for any metadata that the policy decision needs, such as attribute sources, connecting to the MFA system, etc. It may sound scary but take a step back and look at it as if it layers of an onion. Peel back one layer at a time: start with the requirements. The skills needed are strictly business-related. Eventually, you hit the layer where knowledge of the specific authorization platform is needed e.g. ALFA, ACLs, or Graph. Fortunately, these models are relatively easy and there are lots of resources available e.g. https://alfa.guide, https://authorization.guide, or https://authorization.academy.
Authorization API Standardization
Many Authorization platforms, products, and SaaS follow their own standards. For instance, Open Policy Agent has a relatively flexible interface depending on how the Rego policy is written. Others like Oso and Cerbos have a proprietary interface. Some like Cedar don’t have an API to speak of. Standards-based options such as XACML and ALFA follow the OASIS XACML REST/JSON PEP-PDP interface (what a mouthful). NIST has their own interface as part of NGAC, the standard. The good news is that all these approaches are very similar. Several vendors and practitioners have been working together under the helm of the OpenID Foundation in a new working group called AuthZEN to standardize the PEP-PDP interaction and align the vendors/platforms. You can see the latest samples here. There will be an interop at Identiverse 2024. This will increase interoperability between platforms and products. AuthZEN’s goal is also to encourage non-authorization vendors (e.g. other SaaS such as Workday and Salesforce) to adopt these APIs and allow their customers to externalize their authorization configuration.
More broadly, there are 3 areas worth standardizing
- The standards of underlying data sources e.g. SQL, SCIM, OData… That’s really just about plumbing. Each AuthZ solution can easily address that
- The policy language: a standard policy language makes learning the language easier. There are more resources to learn and there are more templates to be had. For instance, ALFA’s Wikipedia page contains lots of examples. The OPA community has many Rego samples… It also matters from an integration perspective if, for instance, you’d want to give the policies to an IGA tool like Sailpoint. It may also matter from a “PDP engine” perspective. Imagine you have a single control plane where you write your policies yet you want to provision to different PDPs in different layers/from different vendors. Having a single language is useful. This is where the feature parity between Cedar and ALFA is interesting. You can imagine translating from one to another. This is also where IDQL is useful as it aims to provide that translation mechanism. But be wary of languages that are very vast (Rego) and cannot be easily translated to purposely constrained languages (Cedar and ALFA).
- Lastly and most importantly, as previously discussed, the PEP-PDP interaction. That’s what AuthZEN aims to address. It’s partly addressed in OPA (although they give a lot of freedom to developers) and it has already been addressed by XACML (JSON profile, REST profile). See the work we’re doing on prior art here.
Architectural Patterns, Scale & Performance
Performance requirements can take many forms. For example, do you need a lot of throughput (typically you can deploy more instances of the PDP service) or is response time the most critical factor? Caching policies, attributes, or decisions can help with response time. Placing the PDP as close as possible to the protected resource (like with a sidecar) can eliminate or reduce network callouts.
There are many examples of externalized authZ systems managing millions of users or transactions. In many cases, you need to pick the product with the right architecture and configure it properly to meet performance needs.
That said, processing security requests will take resources – whether it happens within the application code or if you call an external authZ service. Today that performance hit may be buried within the app and now you expose the performance considerations when using an authZ service, but this also gives you the opportunity to optimize performance in a way that you may not have had available to you before.
We’ve come a long way since the early days of “externalized & decoupled authorization”. In 2010, many vendors would argue for a single logical centralized PDP. Long gone are those days. Now you can mix and match: one central PDP and/or sidecar PDPs. One single PEP (e.g. an API gateway) or micro-PEPs deployed inside each application.
If you have to argue about performance with a peer, ask them what the performance of the current system is. I’d argue externalizing and more importantly decoupling authorization gives you an opportunity to optimize and increase the overall performance of your applications.
Conclusion
I hope this article has proven useful. If you’ve read to this point, just know you’re not alone: many of us have pondered about these topics. Fortunately, the IDPro community is thriving with eager volunteers that have great insights on rolling out a successful externalized authorization strategy so come find us on IDPro’s #authorization Slack channel.
Authors:
David Brossard, Chief Technology Officer, Axiomatics
In his role as CTO, David drives the technology vision and strategy for Axiomatics based on both identity and access management (IAM) market trends as well as customer feedback. He also leads the company’s strategy for standards and technology integrations in both the IAM and broader cybersecurity industries. David is a founding member of IDPro, a co-author of the OASIS XACML standard, and an expert on standards-based authorization as part of an overall IAM implementation. Most recently, David led the design and development of Salesforce’s identity offering, including customer identity and access management (CIAM) solutions.
Alex Babeanu, Chief Technology Officer, 3Edges
Alex leads the research and development of 3Edges, which created the best and easiest to use Graph platform on the market, specifically built for graph-aware dynamic authorization. His past experience includes building pieces of the Oracle Identity Manager server as a Principal at Oracle, and over 10 years spent as a consultant in the field, architecting many solutions for public and private organizations in all verticals. Alex holds an MSc in Knowledge Based Systems from the University of Edinburgh, UK, and is an avid Sci-Fi enthusiast.
