Member post originally published on Aserto’s blog by Omri Gazitt
In the beginning…
Anyone remember the time before we had identity standards? I do. Back in the early days of SaaS, every app had to build its own login system. My team at Microsoft participated in some of the early efforts, like SAML (2003) and WS-Federation (2007), to standardize “single sign-on” for SaaS applications.
But it wasn’t until the industry rallied around standards like OAuth2 (2012) and OpenID Connect (2014) that we reached a tipping point. Applications that didn’t support a standard authentication flow started feeling broken.
And now, in 2023, building your own authentication system is not even a question. Your B2B customers require your SaaS app to support their single sign-on system. And it’s at least an order of magnitude cheaper to incorporate a standard authentication service, such as Auth0, Okta, Cognito, or Azure AD, than to roll your own federated identity system.
Authorization is the next frontier
Now that authentication is a solved problem, the same needs to happen for authorization. We find ourselves in a similar situation to AuthN 10 years ago. Every application rolls out its own permissioning / RBAC system. We do this because there isn’t a better way.
But this is starting to change. We now have a cohort of authorization service vendors that offer a similar value proposition to application developers: rather than invest time in building your own permissioning system, adopt an off-the-shelf solution for a small fraction of the cost.
Each vendor has a different take on the problem. The model to support – RBAC, ABAC, ReBAC, or all three? Expressing authorization policy as code, or as data? Providing a central service, or a distributed architecture?
These alternatives leave a lot of room for innovation, which is great for an early software category. But one thing that isn’t really a differentiator is the protocol for calling an authorization service with a set of inputs, and receiving an authorization decision. And conversely, if we had a standard protocol, we could accelerate adoption of externalized authorization systems. Each of these solutions could be optimized around a different set of tradeoffs, but from the standpoint of a calling application, they would be largely interchangeable. It would also allow for standard libraries for authorization – much like the role that passport.js has fulfilled for authentication.
Where are the authorization standards?
Today, the authorization world is a fractured mess – each vendor supports its own APIs and protocols. With that said, there finally seems to be some appetite to change this.
We’re in the early innings of a promising effort called AuthZEN, where the authorization community is hoping to establish a set of patterns and standards for externalized authorization. AuthZEN is the product of informal conversations that have picked up steam since Identiverse 2023, across a number of identity & access practitioners and vendors, both large and small.
A few of us created a charter document, and on October 14 2023, AuthZEN became an official OpenID Foundation working group. OIDF is the home of OpenID Connect, the most ubiquitous interoperability standard for federated login, and that’s where we’re setting our sights as well. Read the OIDF announcement here.
So what do we hope to accomplish?
Architectural patterns
Identity standards coin standard terminology, like “Identity Provider” and “Resource Server,” and describe the message exchange patterns between them. In the authorization space, the XACML (2003) standard provides some useful terminology to describe the various moving parts:
- Policy Enforcement Point (PEP): typically the application that gates the access to a protected resource.
- Policy Decision Point (PDP): the authorization service that computes an authorization decision with a given set of inputs – typically a policy, user context, and resource context.
- Policy Administration Point: the system that manages authorization policies.
- Policy Information Point: a system that provides data (user, resource, and environmental attributes) that are used in computing authorization decisions.
But the XACML spec is tied to a single, and now fairly outdated, authorization model. We need a reference architecture that is policy language-neutral. Much like the seven-layer ISO OSI model provided us with a useful taxonomy for network protocol stacks, the XACML terminology can help us define the moving parts of an authorization system.
Protocols & message exchange patterns
OAuth 2.0 and OpenID Connect define specific interactions between an application, Identity Provider, and Resource Server, including the HTTP messages that are exchanged between these actors. To accelerate the adoption of externalized authorization systems, we need a similar set of specifications for authorization flows.
The most obvious protocol to formalize is between the Policy Enforcement Point (the app) and the Policy Decision Point (the authorization engine).
In addition, it’s valuable to define the interaction model between the Policy Administration Point and PDP, as well as how authorization data makes it from Policy Information Points into the PDP.
If we formalize these additional interactions, we can hope to allow more interesting interoperability scenarios. For example, an organization could store data about its users and groups in one system, and expect changes to those entities to “flow down” to a potentially heterogeneous set of authorization systems.
Likewise, an organization may be able to author and administer a set of policies in one vendor’s Policy Administration Point (PAP), and have these policies disseminated to a heterogeneous set of Policy Decision Points.
Call to action
If you’re an authorization vendor, join us at the OpenID Foundation AuthZEN working group! We’d love to make sure the specifications we work on can work for a wide variety of authorization styles – from attribute-based systems such as XACML, OPA, and Cedar – to relationship-based systems such as Google Zanzibar, Topaz, and OpenFGA.
And if you’re building SaaS or internal enterprise applications and don’t want to reinvent the authorization wheel, stay tuned to this space! There are now a set of vendors that can help you get going, and you can reduce lock-in risk by working with vendors that support these emerging standards efforts. You can bet that Aserto is one of them!