1 Introduction
The concept of authorization has been around since the beginning of Identity and Access Management (IAM) as one of its core capabilities, along with identity (human or non-human entities), authentication of that identity (when an identity of an entity/subject is verified) and auditing the access to resources. Authorization is a simple access control concept - deciding who has what type of access to a resource. An authorization decision should only occur after the identity has been authenticated.
The evolution of authorization mechanisms has evolved over time. In the beginning, Access Control Lists (ACLs) functioned as a simple form of access control to resources - either a subject is on the list, or it's not. You have access if it's on the list; if not, you don't. It doesn't get much simpler than that. There are still valid use cases where ACLs can be used, but its fall's short when authorization use cases get more complex. Role-Based Access Control (RBAC) was an effort to address the more complex authorization but still relatively simple use cases. RBAC provides some administrative and security advantages over ACLs. Assigning a role to one or more access rights - permissions and privileges, allow flexibility in combining or mapping subjects to resources. But RBAC's strength of aggregation under a role label also has its downside. Roles must be carefully planned and managed lest they become unwieldy and subject to role explosion.
In the push to make authorization decisions more granular and perform in real-time, Attribute-Based Access Control (ABAC) solutions became available. Initially, ABAC was popularized based on a standardized policy language, architecture, and processing model defined by the eXtensible Access Control Markup Language (XACML) specification. This logical form of access control, ABAC, allowed for the evaluation of attributes related to a subject, object, actions, and environment conditions against a set of rules and conditions within a defined policy. These policies could be evaluated at runtime on a policy decision point (PDP) engine that can be centralized or distributed. This approach also had the benefit of externalizing authorization, making it easier to integrate into an organization's system of system architecture. Although the XACML standard has not had widespread adoption, the concept of ABAC has morphed into Policy-Based Access Control (PBAC). PBAC/ABAC has seen a resurgence with the emergence of OPA (Open Policy Agent) and Rego as a policy language to address more modern IT architectures that include containers, Kubernetes, and other cloud-based use cases. PBAC has become the de facto approach to authorization today. Efforts to incorporate other access decision considerations include Risk Adaptive-Based Access Control (RAdAC). This form of access control uses contextual information to assess risk level as part of the access control decision-making and not solely base an access decision on an access policy. This can be accomplished by providing a real-time situational aware source of information as an extension of PBAC. But is this enough?
ACLs, RBAC, ABAC, PBAC, and their extensions all have applicable use cases. When looking at the various reasons that drive the evolution of authorization access controls, it's the growing complexity in digital security and having the ability to maintain the form of authorization used. So, what is the next level of authorization decision-making that can handle security complexity and maintainability increases? One approach worthy of consideration is Relationship-Based Access Control (ReBAC), where access is granted based on relationships between identity data and context. Knowledge graphs connect data and relationships in meaningful ways, and IndyKite introduced Knowledge-Based Access control (KBAC) to lead the way.
