The ABCs of Access Control

For all the variety that exists in software systems, there’s a surprising amount of consistency in how access control is defined.

In fact, most systems use the following vocabulary:

• Users
• Resources
• Permissions
• Access control lists (ACLs)
• Roles
• Groups
• Folders
• Rules

And that’s about it.

Almost every system you’ve used personally or professionally leverages some combination of these concepts to implement access control.

While describing access involves a lot of jargon, it’s important to understand the different constructs that systems use today in order to improve on them. We’ll spend the rest of the article exploring the strengths and weaknesses of these constructs to help you implement a balanced, forward-thinking access management strategy.

The primitives

These are the fundamental building blocks of access. Access is usually described with a subject-verb-object structure where the subject is a user, the verb is a permission and the object is a resource, e.g. Emily has read access to prod database.

Users

Access control starts with users. Restricting what users can and can’t do within a given system is the core function of access control.

Resources

Users naturally want to access resources. Resources might be channels in Slack, for example, or documents in Google Drive, or databases, Kubernetes cluster and compute instances in AWS.

Permissions

The actions a user can take on these resources, like reading or writing, are defined by permissions. Some permissions are scoped to very specific resources like infrastructure (e.g. read access to a database), while others are scoped to much broader resources like organizations (e.g. the ability to invite new users to an org).

Direct access

When a user is granted direct access to a resource, they receive access to only the resource and nothing else. Managing access at the resource level offers a lot of configurability but does not scale well.

ACLs

The most common way of implementing direct access is using an access control list (ACL). This list tracks which users have which sort of access to a resource. Because each resource has an ACL, ACLs offer a lot of configurability but are difficult to manage at scale.

Bulk access

For better scalability, products also support granting access in bulk using collection types like roles, groups, or folders. These types enable users to receive access to many resources at once. The downside with collection types is they’re still maintained manually like ACLs. For very complex systems like AWS, this maintenance overhead grows difficult to manage over time.

Roles

Roles are collections of permissions which can be granted to users in bulk. For simpler products like Slack, a user’s role might be “member” or “admin”. For more complex systems like AWS, a user could have one of hundreds (maybe thousands) of roles which vary widely.

In general, most systems don’t allow you to customize roles. Instead, permissions and roles are hardcoded. In more complex systems like AWS, however, you can define your own roles based on a set of available permissions and resources.

Groups

Groups are collections of users which can be granted permissions and resources in bulk. Unlike roles which are collections of access and describe job functions like “admin”, groups are collections of users and describe cohorts like “Engineering” or “API Team”.

Nesting one group inside another cascades access across groups. There are typically no restrictions on nesting (i.e. the nested structure is a graph as opposed to a tree), though some systems like Okta don’t support group nesting at all.

Many systems implement groups. Increasingly this is how access is managed across systems. An identity provider will host a single group structure which all systems use as a source of truth. Then, in each end system, resources and permissions are bound to an end system group which is synchronized with an identity provider group. Using this model, users can be centrally added and removed from groups in the identity provider, which propagates changes to all systems.

Folders

Folders are collections of resources which can be granted to users in bulk. Nesting one folder inside another cascades access across folders. Typically folders are required to maintain a tree structure. This gives them a much more understandable nesting structure than groups.

Folders are most common in systems whose resources are documents like Notion or Google Docs, but are also present in cloud providers like AWS and GCP.

Implied access

Implied access constructs solve many of the scalability issues of collections by defining more abstract, qualitative relationships between entities.

Attribute-rules

One such example is attribute rules. Whereas ACLs and collections explicitly enumerate which users have access, rules implicitly define access based on a statement about expected user and resource attributes. In theory, once a rule is implemented, it never needs to be manually updated again, regardless of which users join or leave an organization.

For instance, it might be easier to specify who has access to the “North America Sales database table” by writing a rule rather than manually granting users access. One such rule might grant access to any user whose position is “salesperson” and whose location is “north america” as defined in a company’s HR system.

The core idea of rules is that it’s easier to maintain the qualities of entities (e.g. a user’s position and geography) and their qualitative relationship to other entities as described by a rule (e.g. all Norther American salespeople have access to this database table) than it is to maintain those relationships directly.

Attributes like position and geography which are set when a user joins the company are useful for automating birthright access, that is, the access a user is entitled to based on who they are.

The downside of rules is they make it more difficult to see who has access, as they are a more implicit way of defining access that ACLs and collections.

Here's what everything looks like together:

A hybrid approach

The reality is each of these constructs has its place. ACLs are useful for sensitive resources like production databases where you don’t want more than a handful of users to ever have access. Roles are necessary for taming the complexity of AWS, while Okta groups help you centralize access across many different SaaS applications. Attribute based rules help automate birthright access by defining access qualitatively in terms of a user’s attributes.

Knowing which cases to leverage each construct in is crucial to a balanced approach to access management.

Opal offers a single surface for managing all of these constructs in one place. With Opal, your users can request direct access to a database or folder, manage the relationship between resources and groups, create temporary sessions with roles, and restrict access based on resource tags and user attribute rules. With this flexibility, admins can choose exactly the right constructs to define in their access control model without worrying about additional operational overhead.

About Opal:

Opal is the centralized authorization platform for IT and Infrastructure teams. Deeply integrated with developer infrastructure, SaaS applications, and custom internal tools, Opal enables companies to implement scalable access management.

Want to see it yourself? Contact hello@opal.dev or book a meeting here for a personalized demo.