The State of the Authorization Union
A few weeks ago, I had the pleasure to talk at the European Identity Conference on a topic that is close to my heart: authorization. More specifically, I discussed how the evolving IT landscape requires an even finer grained authorization framework to be able to deliver value to consumers as a whole. In a later session, I took part in a panel entitled “How Will Authorization Look in the Future? XACML, OAuth, Proprietary” with Loren Russon (Ping Identity), Pam Dingle (Microsoft) and Eve Maler (ForgeRock). The bulk of the debate centered around standards and in particular the battle of XACML (eXtensible Access Control Markup Language) vs. OAuth (and to a lesser degree, user-managed access, or UMA).
TL;DR: we need to give users more control over how their data is used and we need to provide enterprises with the means to define granular access control in a controllable, transparent and configurable way.
Let’s take a step back and look at the last 24 months. According to IDC, data creation has doubled in size every two years (from 16.1ZB of data in 2016). The number of online users has also increased. If we measure that by mobile user penetration, it’s estimated that over two-thirds of the planet (7.5B human beings) will be using a mobile phone by the end of 2018. Lastly, according to ProgrammableWeb, we are seeing close to 2,000 new APIs yearly. If we equate APIs to services or mobile applications, that’s a large number of new applications. Basically, it means:
This growth is further fueled by the mantra “every company is a software company”. As a matter of fact, one could generalize it and state that everything is an IoT thing (an Internet-of-Things thing). We no longer realize how much of a data trail we’re leaving behind. Well, except when regulators kindly remind us with newly minted regulations such as GDPR.
So what does this have to do with authorization? Historically, authorization has been seen as a natural consequence of proving one’s identity (or authenticating). Take for instance HTTP 401, the error code one gets when using the wrong credentials in a web application. What’s the error message for that? Unauthorized. It only highlights the tight coupling there is between authentication and authorization. It’s so much more than that.
Authorization is more relevant than ever. In particular, the pace of technological change argues against the hard-coded hierarchies of the past. Business disruptors that are impacting so many industries (such as IoT) force companies to be more agile and proactive (rather than reactive). This means they need to choose patterns and technologies that will allow them to execute more efficiently. Digital identity is one such area that can help businesses win. And in it, authorization is a key layer.
Christine Robson of Deloitte stressed that authorization is a key component of the “blueprint for a digital identity”. Here is one of the slides she presented at Cloud Identity Summit 2017 (now called Identiverse). She defines authorization as:
There are two words I want to focus on:
Rules imply that we want to decouple authorization from:
Relationships are interesting. They suggest that the traditional role-based hierarchical way of defining authorization is no longer viable. That makes sense. With the growth in users, data and services, we can no longer expect to define relevant authorization checks using a static hierarchy for a world that is inherently dynamic where relationships are formed and dissolved all the time. Information is transitive. Authorization should, therefore, be dynamic to address the ever-changing landscape.
We have to look beyond users and user identity. We have to consider the many dimensions our daily digital interactions. With that in mind, I doodled a Venn diagram of “Dynamic Authorization Management” to highlight the three areas we need to take information from in order to define meaningful authorization policies. These are:
Now, Dynamic Authorization Management (or DAM for short) has multiple dimensions and names to it which all reveal different aspects to the challenge.
RBAC, Role-based Access Control, is the most widespread model for authorization today. Formalized back in 1992 by the National Institute of Standards and Technologies (NIST), it’s widely used across many applications and services. It’s a sound foundation for identity-centric access control. However, in the light of growing IT complexity, we need need to expand beyond “just roles”. This is where ABAC comes in.
ABAC, or Attribute-based Access Control is the latest model for authorization. It was formalized by the same team at NIST in 2013, and it builds on top of RBAC and aims to address its shortcomings, namely relationships, the expressiveness and the dynamic aspect of authorization and policy.
ABAC enables Dynamic Authorization Management, and XACML implements ABAC. More on XACML later. ABAC lets you express authorization in terms of multiple dimensions. I like to call that the Who, What, When, Where, Why and How. In other words the 5 Ws and 1 H.
One of the key drawbacks to RBAC is its inability to express relationships between users, data and services (the other drawback is its static nature). This means that if one wanted to control access to medical records within a given unit of a given hospital, we’d have to create the product of the matrix role multiplied by the number of hospitals, multiplied by the number of units, leading to thousands of roles (e.g., 10 roles times 10 hospitals times 10 units).
Yet, relationships matter more and more in this world. It can be a care relationship between a doctor and a patient. It can be a family relationship between a child and their guardian or event between an adult and their senior parent. It could be an employee-to-manager relationships. In short, relationships are everywhere and RBAC just does not know how to handle that.
This is where Attribute-based Access Control steps in. Using attributes and policies, it will let you naturally express a relationship. For instance, you could write the following policy (using ALFA notation—more on ALFA later):
One of the trends driving the need for ABAC in addition to more traditional RBAC is the need to protect the functionality, transactions and data users interact with rather than just secure the channel. For instance, historically, we would secure a link between an application and a database. We wouldn’t typically secure the data being exchanged itself. In other words, if your service account had the right role, your app would get access to the entire data set and your application code would discern which end users could act on which piece of data. Today, the trend is to externalize that control and express it as configuration or policies using attributes or metadata. We aren’t just securing the infrastructure or the channels. We’re securing the information itself and the flows around that information.
A term we’ve seen a bit of lately is “Identity Relationship Management” (IRM). The Kantara Initiative has a great page on the topic (thanks Joni Brennan). In particular, this sentence summarizes the evolution from traditional identity-centric IAM to IRM and beyond:
One of the main means of implementing RBAC was to leverage a user directory, typically LDAP. This approach meant developers had relatively little to do in the way of integrating with LDAP. After all, binding to LDAP and retrieving a list of roles is relatively trivial and has become standard in most applications.
Development frameworks such as JAAS, Spring Security and Microsoft Claims further simplified the integration between user directories and code as far as they could but didn’t remove the need to implement custom logic within the applications. In fact, developers typically spend anywhere between 20% and 50% of their time and lines of code implementing some form of authorization (they famously spend the rest of their time compiling).
Today, developers want better, faster, stronger (as Daft Punk would put it). Integrations need to be easier. This means authorization needs to be simple to set up and consume. In the past few years, there have been two key innovations in the ABAC/XACML space namely:
If we want developers to adopt dynamic authorization, we need to make it as easy to integrate as possible and require next to no integration code.
Developers matter, yes. We need to think like developers and provide them with a lifecycle in line with their way of working. That means authorization needs to be configuration-driven and its lifecycle must be akin to that of application code. Going back to the previous paragraph, authorization should no longer be implemented using lengthy code statements (if/then/else spaghetti) but as configuration and policies instead. I like to call this “authorization-as-configuration”.
In turn, this configuration must be managed just like code is. This is part of the “everything-as-code” mantra. It means policies and configuration will be version-controlled inside your favorite version control system. Policy lifecycle will follow the same lifecycle as code does. The policies are still decoupled from the code of course and we still gain visibility into the authorization logic (vs. having to understand code).
ALFA and Rego (part of the OPA engine) are two languages that go in the direction of developer friendliness and *-as-code. Both languages are easy to read and relatively dense, making them a natural choice for anyone wishing to edit and compare policies by hand.
Another trend that is fuelling the need for dynamic authorization is the ever-increasing presence of APIs (and microservices). We’re seeing this growth in APIs because of the need to break down walls, open up systems, exchange data, build mobile applications, integrate with the Internet-of-Things and much more. Behind every great app, there’s an API. Even conventional applications such as databases are getting REST-based APIs. That, in turn, means we have well-defined interfaces and data structures based upon which we can define and enforce authorization policies. One of my current cases is a customer who wants to apply XACML to AWS APIs, all of them. From S3 to Redshift to RDS and beyond.
APIs and API gateways are simplifying integrations, and in turn, making it possible to apply granular controls to data, services and transactions.
So, where do standards fit into the evolution of authorization? As we move from RBAC to ABAC and a more dynamic approach to authorization, which are the standards that stick out?
If you search Google for “API Authorization,” the odds are that you’ll get a lot of results on how to authenticate APIs and authorize APIs using OAuth. But OAuth is about authorization delegation. And that second word matters.
The use case for OAuth is to let a user, Alice, delegate access to one of her services (e.g., her bank account) for another of her services (e.g., an expense system). Through OAuth 2.0, Alice can state, “I grant the expense system access to my bank account for the purpose of listing transactions.” OAuth 2.0 solves the password anti-pattern (i.e., the problem whereby the expense system would have asked Alice for the username/password to her bank account).
OAuth focuses on the plumbing and the authorization of the integrations. It does not focus on authorization within the API business logic. Rather, much like RBAC, it lets developers implement authorization checks in code. OAuth scopes can be used to grant permissions to users and services. Scopes are similar to roles and permissions in RBAC.
Another important aspect to OAuth and OIDC is the “tokenization” of identity. Tokenization greatly improves the ability to share identity metadata across security domains to remove friction from the authentication process. However, dynamic authorization management is still needed to address the limitations of lack of policy language in these standards to avoid the mistakes of the past (e.g., hard coding access logic in new-age microservices and APIs).
User-managed access (UMA) is an OAuth-based protocol designed to give an individual a unified control point for authorizing who and what can get access to their digital data, content and services, no matter where all those things live. The Kantara website lists several use cases for UMA. They are all user-centric.
XACML is the oldest of the standards mentioned here (founded in 2001, latest version ratified 2013). It’s part of the OASIS family of standards (alongside SAML) and focuses exclusively on policy- and attribute-based access control. Where OAuth and OpenID Connect aim to simplify and replace SAML, XACML aims to address policy-driven authorization alone and interact with the other standards when needed. Its model is the same as ABAC. XACML provides:
What sets XACML apart from OAuth and UMA is the fact it has (is) a policy language. The policy language is what’s used to implement the relationships between parties. Unlike UMA, XACML is not particularly user-centric. Policies can be about users, resources, actions, etc… The policies are similar to a body of laws. They determine what can and can’t happen under specific circumstances.
A good set of examples would be:
Whereas OAuth and OIDC essentially replaced SAML (making the use cases of SAML easier to implement), XACML has modernized from within by adding new profiles such as the REST Profile of XACML, the JSON Profile of XACML and Abbreviated Language for Authorization (ALFA) (see below).
And it’s only the beginning. There are talks of what a “XACML 4.0” would look like. My colleagues at Axiomatics, as well as peers in the technical committee, are thinking about the shape of a simpler language yet.
ALFA is a newer initiative. In the light of “developers matter” and “everything-as-code”, it’s become apparent that policy syntax matters. XACML is, for historical reasons, XML-based and verbose. This makes reading XACML hard. The authors behind ALFA, Pablo Giambiagi and team, chose to design a syntax that would be easy to read, write and compare. This means developers can write ALFA policies in their own IDE, version control them using their standard tooling (same as code) and compare them just like they would code. ALFA enables “everything-as-code” for authorization. ALFA mirrors XACML and it is possible to translate back and forth between both languages. The ALFA draft is part of the OASIS family of standards, too. Like XACML, ALFA aims to be a business-driven policy language. It’s meant to be used to express business-relevant authorization policies that focus on transactions, data and functionality
More recently still, a set of developers has chosen to develop yet another policy language called Rego. It’s the language used by the Open Policy Agent, an open source, general-purpose policy engine. Rego aims at technical configuration for infrastructure such as AWS.
Cloud platforms have developed their own languages as well, such as AWS IAM and Google IAM. These languages are very similar to ALFA and Rego, and it’s likely one could translate from ALFA into these languages. It’s worth noting that AWS IAM and Google IAM tend to focus on identity attributes rather than take into consideration the entire spectrum of attributes.
Dynamic authorization is here to stay and more important than ever. The need to express relationships has grown, as well as the need to be able to express authorization consistently and coherently across multiple stacks. Managing authorization as configuration and policies managed like code (externalizing it) is the way to go. The evolution of authorization will be dictated by the trends in APIs, IoT, DevOps and cloud.
Approaches that simplify the work for developers will prevail. ALFA and JSON will be the route forward. OAuth, OpenID Connect and ALFA (or XACML) are complementary. OAuth and UMA will handle user consent and delegation whereas XACML will provide the policy and architecture.
By David Brossard
VP Customer Relations, Axiomatics