A couple months 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 XACML 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 is estimated that over ⅔ of the planet (7.5bn 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 API to services or mobile applications, that’s a large number of new applications. So, in sum, it means
- More users of different kinds (employees and consumers; individuals of all ages from around the world)
- More data (health data, IoT data, financial data…)
- More services for the users to interact with the data
This growth is further fuelled 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 are 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.
A Blueprint for Digital Identity
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 (Identiverse’s predecessor). She defines authorization as:
|“Complex authorization rules and relationships”|
There are two words I want to retain:
Rules imply that we want to decouple authorization from both
- The authentication layer. It’s more than just about who you are; and
- The business application: let your apps do what they do best and delegate authorization management to an external rules decision engine.
Relationships are interesting. They imply the fact 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.
Dynamic Authorization Management
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” which highlights the three areas we need to take information from in order to define meaningful authorization policies. These are:
- Identity: who the user is, what role or job title they have, etc…
- Data: what type of data we are dealing with, what metadata is associated with the data.
- Context: environmental information such as time, location, and device.
Now, Dynamic Authorization Management (or DAM for short) has multiple dimensions and names to it which all reveal different aspects to the challenge.
- Dynamic refers to the fact that authorization decisions are taken at runtime in real time when needed rather than statically stored inside a user repository (as a typical entitlement server would do). This means decisions are fresh and can leverage contextual information such as the time of day
- Externalized refers to the fact that authorization decisions are no longer implemented in code by the application but rather externalized and expressed as configuration such as policies. This decouples the business applications from the authorization policies. And, in fact, this is in line with microservice architecture and principles. Dynamic Authorization Management is the microservice of authorization.
- Attribute-Based refers to the fact that authorization will be expressed using attributes (key-values pairs) that describe the users, data, and context. Attributes are essentially metadata from which we want to derive authorization. In a later paragraph, we will talk about Attribute-Based Access Control which implements dynamic authorization management.
- Policy-Based refers to the fact that the attributes aforementioned will be used together in policies to convey authorization meaning. Policies can be permissive i.e. they grant access to a given resource or restrictive i.e. they deny access to a resource. Policies are the secret sauce to dynamic authorization management.
- Centralized refers to the fact that, once externalized and decoupled from applications, the authorization logic, expressed as policies, can be centrally managed. This means that authorization lifecycle, access review, auditing, and other workflows become easier as the data is all centrally managed.
- Standardized refers to the fact that there is one standard out there, XACML, that provides ABAC in a vendor-neutral, technology-neutral way. We’ll get back to that later.
From RBAC to ABAC
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 is widely used across many applications and services. It is a sound foundation for identity-centric access control. However, in the light of growing IT complexity, we need more than just roles. We need to expand beyond “just roles”. And 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. ABAC builds on top of RBAC and aims to address its shortcomings namely relationships, the expressiveness, and the dynamic aspect of authorization, and policy.
|“Attribute-based access control (ABAC) is the latest development in an evolution of access control models going back more than 40 years.” Attribute Based Access Control, Vincent Hu (NIST), David Ferraiolo (NIST), Ramaswamy Chandramouli (NIST), Richard Kuhn (NIST)|
ABAC enables Dynamic Authorization Management. XACML, the eXtensible Access Control Markup Language, 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 being RBAC’s 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):
* Doctors can view medical records of patients they are assigned to
target clause user.role == “doctor”
condition patient.assignedDoctor == user.identifier
Sample ALFA policy with a relationship. Source: Wikipedia.
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 would not 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 and it would be down to your application code to 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 are not just securing the infrastructure or the channels. We are securing the information itself and the flows around that information.
A term we’ve seen a bit of lately is “Identity Relationship Management” or 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 Identity Relationship and beyond:
|“Today a company must implement a dynamic IAM solution that serves employees, customers, partners and devices, regardless of location. This is the evolution of IAM to IRM: Identity Relationship Management.”|
|Source: The IRM Pillars, Kantara Initiative.|
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 did not 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:
- A new REST/JSON interface to query for authorization decisions
- A simplified authorization language called ALFA (Abbreviated Language for Authorization).
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 are seeing this growth in APIs because of the need to break down walls, open up systems, exchange data, build mobile applications, integrate with Internet-of-Things and much much more. Behind every great app, there is 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?
OAuth & UMA
Google “API Authorization” and the odds are that you will get a lot of results on how to authenticate APIs and authorize APIs using OAuth. OAuth, however, 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 expenses system. Through OAuth 2.0, Alice can state “I grant the expenses 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 expenses 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 APIs’ 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, i.e. 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 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:
- An architecture
- A request / response scheme (how you ask for authorization decisions)
- A policy language.
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 cannot happen under specific circumstances.
A good set of examples would be:
- Doctors can view medical records of patients they have a relationship with.
- No one can edit a medical record from outside the hospital
- Break the glass: a doctor can view a patient’s medical record if this is an emergency.
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 & Rego
ALFA is a newer initiative. In the light of “developers matter” and “everything-as-code”, it has 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 is meant to be used to express business-relevant authorization policies that focus on transactions, data, and functionality
More recently still, a set of developers have 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 platform have developed their own languages too such as AWS IAM and Google IAM. These languages are very similar to ALFA and Rego and it is likely one could translate from ALFA into these languages. It is 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; and the need to be able to express authorization consistently and coherently across multiple stacks has also grown. Externalizing authorization, managing it as configuration and policies managed like code 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.