While application development has accelerated and advanced over the past decade, authorization approaches have remained relatively static, with some core approaches now decades old and still popular. As technology, regulations and security landscapes evolve, modernizing authorization systems is becoming increasingly imperative to adapt. There are many modern approaches available, but let’s first look at the dominant approaches in use today.
Traditional authorization methods
Directory access Protocol
Many of today’s IAM systems rely on directory information services, to store identity data. At the foundation of most directory services is the Lightweight Directory Access Protocol (LDAP), organizing its data in directory information trees (DIT).
Directory Services were foundational to the building of internet applications that are widespread today, and support both role and attribute approaches mentioned below.
Role Based Access Control (RBAC)
RBAC provides a way to organize privileges based on a user’s role. Often used to restrict unnecessary access and based on the principle of ‘least privilege’, RBAC has been a popular model since its birth in the 1990's, and is still in use today.
RBAC requires a system administrator to assign rights based on roles within an organization (rather than individuals). Each role is defined with a certain area and level of access based on three principles: role assignment, role authorization and permission authorization. This means that individuals are only given access to what they need to do their job. Access can be defined based on several factors, such as authority, responsibility and job competency.
While popular, this approach runs into problems over time, with more roles than employees, employees with multiple roles, the cannibalization of roles and roles becoming obsolete or no longer relevant. Another limitation is that it is not an automatic process, it relies on manual input and constant maintenance, resulting in a high resource cost.
Attribute Based Access Control (ABAC)
ABAC uses attributes (such as title, location, team, etc) rather than roles, to determine access. In this model, the system administrator sets approved characteristics to determine access. This model allows for more granular access permissions than RBAC and proved popular in the 2010's. While a step forward from RBAC, ABAC runs into challenges with the manual maintenance of a growing number of attributes and complexity that develops over time.
Policy Based Access Control (PBAC)
PBAC, often considered a form of ABAC, works by granting access to users based on the use of combined attributes that form policies. Policies can consist of a variety of attributes, such as: name, organization, job title, security clearance, creation date, file type, location, time of day and sensitivity or threat level. Once these are combined to form policies, rules are established to evaluate who is requesting access, what they are requesting access to and the action determining access. PBAC gives administrators greater control than RBAC and can be high level or granular. The effectiveness of the policy used in PBAC is entirely based on the quality and combination of information provided as attributes.
Authorization challenges - and the way forward
The main challenges with current state operating authorization have come with age.
Access control has not kept pace with the evolution of applications and services it enables. Meanwhile, the world is rapidly changing towards the future state of identity, a world where not only humans but billions of devices and things can be connected. These entities not only interact with humans but also with each other, necessitating authorization decisions for data exchange. These decisions are often hardcoded into APIs or applications, posing scalability and flexibility challenges due to coarse-grained policies and individual applications and operating systems.
Overall, current approaches all have their shortcomings. Noting that there are still use cases that make sense for a coarse grained approach, but for more functional, transactional, and data-level use cases, a more modern approach is needed. In authorization, granularity is critical as it’s what separates use cases and differentiates the breadth of authorization approaches. Below are four examples of these patterns:
- Alice can access the healthcare application (application access)
- Bob can read patient records (functional access)
- Caroline can read patient data of patients that belong to the hospital where she currently works (data access)
- David can only read patient records of patients that he treats (transaction/record access)
Today’s authorization is mostly static, and the technology applied to authorization is brittle, project-based, costly and simply does not reflect the real-world. Access management of today is focused on how securely you can enable and offer your digital services, not enhance them. The solution to these challenges lies in capitalizing on the level of complexity in modern authorization logic (and the data involved), externalizing authorization and enabling scalability.
The next article dives deeper into how you can leverage modern authorization to drive value in your business.