The Lay of the Authorization Land

Identity and Access Management (IAM) is typically divided into the Identity part, which deals with user authentication and the Access Management part, which deals with authorization. Authorization in enterprises is the ability to determine the assets a principal may access and how they may access those assets. At an airport for example, authentication is when airport security identifies you as the passenger and authorization is when a gate agent lets you board a specific flight.

“At an airport for example, authentication is when airport security identifies you as the passenger and authorization is when a gate agent lets you board a specific flight.”

In this blog post, we will limit to talking about digital assets, unlike physical assets such as buildings and conference rooms or machinery and equipment. Digital assets can impact physical assets too, for example adding a person in an HR system will typically result in that person being able to access a physical building belonging to the organization.

It’s All About Data

Digital Assets of an organization boil down to stored data. Whether it’s an approval for a customer refund, financial details of business performance, or an onboarding of a new employee - it always translates to access to an organization’s stored data. In short, accessing an organization’s digital assets is the same as accessing the organization’s stored data. Authorization uniformly applies to all such data, and so everything written in the rest of this post should be considered applicable to any type of stored data.

“In short, accessing an organization’s digital assets is the same as accessing the organization’s stored data.”

Access is in Context

How data is accessed depends on the context of the access. At a consumer user level, access may mean a user is viewing their stored shipping address, or updating their password. Deep down at the resource level this translates to read or write access to specific fields in a database. An organization would like the user to be able to edit their information, but only in that specific context in that specific field in the database.

Authorization decisions are greatly affected by the higher-level context of the access. In many organizations’ computing architectures, the higher-level context is lost at the time the data access is actually effected at the database level. Therefore, one may be able to make more informed fine-grained authorization decisions higher up in the computing stack, at the application level.

The Three Dimensions of Authorization

Authorization concerns may be categorized in three independent dimensions:

• User Constituencies: Who are the users for whom we need to determine the policies. Note that sometimes users may be represented by bots acting on their behalf, typically in offline batch processes. Users are typically divided into the following constituencies:

  • IT employees: These are privileged users that can access infrastructure and data as administrators
  • All employees: These are normal employees of an enterprise whose access privileges are typically limited. An IT employee is also a normal employee when it comes to assets that do not concern their higher-privileged function in the organization
  • Extended Workforce (Vendors, contractors and temporary workers): These may often look the same as employees when it comes to using various applications and accessing data, but there may be important policy differences in what data they may access or even how they are authenticated
  • Partner users: This constituency is similar to the extended workforce, but these may have more limited access, sometimes through specialized applications
  • Organizational customer users: If an organization serves other organizations, then these are employees, temps, contractors or vendors of the customer organization
  • Consumer users: These are individual end-user customers directly using the organization’s products and / or services. These also include end-user customers of an organization’s customer organizations

• Asset Access Paths: Where is authorization required to be enforced. Digital assets can be accessed using multiple paths, based on their functionality and location:

  • On-premise resources: Such as file shares
  • Cloud infrastructure resources: Such as cloud storage, VMs, VPCs, serverless functions and containers. This can include platform services such as key-management, data warehouses or industry specific solutions
  • Internal applications: Such as homegrown functional applications such as, say, a specialized billing system, or installed third-party developed applications, such as ERP. These applications - internal or third-party - may be hosted internally within an organization’s data center or hosted in a public cloud. The important distinction here is that the organization has full administrative control over the application
  • SaaS applications: Cloud-based applications an organization’s users may be using. The organization in this case has limited administrative control over the application, to the extent that the application’s administrative interface allows

• Policies: What are the rules governing access by specific users to specific assets. These may be captured using different strategies

  • ACLs that name specific users. A policy typically is simply the presence of a user within an ACL in order to access a specific asset

  • RBAC that defines groups of users. A policy in RBAC typically is the association of an asset to a group such that only users from that group are permitted to access the asset

  • ABAC (Sometimes known as PBAC) defines additional attributes that a principal and an asset may have in order to gain access. A policy in ABAC may incorporate attributes such as time of day, IP location, or a user’s work jurisdiction in addition to groups to determine access. While this is more dynamic than RBAC, it requires the attributes to be easily ascertained at the time of access

  • Just-In-Time Access Management enables dynamic querying of access to a specific resource. Policies may be defined based on data that is obtained from various systems and dynamically updated. A policy may depend upon data that is fast changing, e.g. a user’s assignment to a support case.

    If you want to see how this can work in action; how a customer service employee dynamically gets elevated and reduced privileges based on the customer case they are working on, and how those privileges are enforced in internal apps and 3P SaaS apps like Salesforce. Watch the video here.

How I got Involved

After having spent quite some time working on various aspects of identity, and having led standards efforts in this space, I realized that the authorization space is still quite challenging. The need to effectively manage authorization is unfulfilled in modern enterprises, despite the growing urgency of addressing it due to the transition to a zero-trust architecture.

I believe it’s very important to secure access by insiders, because in a perimeter-less security world least-privilege access is the goal; you need really good control on what insiders can do is central to securing enterprises. This is because an increasingly common way of compromising enterprise security is where attackers masquerade as insiders. Remote work and SaaS proliferation has also led to malicious insiders being bolder in their efforts to compromise enterprise assets for personal gain.

“…least-privilege access is the goal; you need really good control on what insiders can do is central to securing enterprises. This is because an increasingly common way of compromising enterprise security is where attackers masquerade as insiders.”

While a number of solutions are focused on managing IT users’ access to infrastructure resources, the whole area of managing all workforce users’ access to internal or 3P SaaS applications seemed to have been left out. Normal approaches like RBAC and ABAC haven’t really addressed the biggest issue - which is that almost all enterprises operate in an environment where every employee has way too much access capability than what they require. Another problem is that solutions operating at a resource level lose a lot of the context of the access that is critical to determining whether such access should be allowed or not.

This is why I got so excited by what my former colleagues from Google - Erik and Scott - were up to. They saw the same problems I saw and had found novel ways to address them. I hope more people likewise look critically at how their organization solves authorization problems and help the industry rethink how this gets addressed in enterprises.