Glossary of access control terms

Admin-time authorization refers to the process of assigning a user into a role, typically performed by an administrator. For example, an IT administrator adds a user to a CRM application and assigns them a “sales manager” role. This user will get access to all the permissions and entitlements associated with the “sales manager” role.

This assignment process is static, and most often does not include fine-grained resource access assignment.

Attribute-based access control is a fine-grained access control model where permissions are based on dynamic characteristics called “attributes.” ABAC policies use attributes that relate to the user requesting access (e.g. name, email, job title, seniority), resource that is the target of the authorization (e.g. project, tenant, folder, file), or environment used to obtain access (e.g. geo-location, network, device).

Common examples of ABAC include denying access to protected resources over public networks, or from certain locations. Regional differences in service levels or compliance requirements, such as GDPR, are common use-cases that are enforced using ABAC systems.

More about ABAC

Application authorization is the process of determining if a principal (typically a human user, or a service working on behalf of a user) has the right entitlements and permissions to access the resources of a specific application or service. The target of the authorization is a resource managed by a software application or service, as opposed to infrastructure authorization, where the target is the underlying infrastructure (e.g. k8s containers, or S3 objects).

There are several authorization models, or patterns, you can use to authorize an application. These models differ in the level of granularity they provide and effort required to set them up. Role-based access control (RBAC), attribute-based access control (ABAC), and relationship-based access control (ReBAC) are the three most common authorization models used to enforce access control for applications. RBAC is the simplest to implement and ReBAC provides the most fine-grained controls.

Aserto uses a hub and spoke model to ensure high availability with low latency. Authorizers are deployed in the same pod or subnet of the application service, to ensure millisecond decision times. These authorizers are controlled centrally via the Aserto control plane.

The Aserto control plane provides centralized control for authorization policies, user information, application data, and decision logs. It simplifies the process of managing authorization across applications, services, and APIs. It also provides a high-speed data fabric that ensures that the most up-to-date information is used to make real-time decisions.

Authorization is no longer a black box with the Aserto control plane. You can manage all your policies, across applications and services, in one place. You can also view all of the local authorizers, users, and application-specific data that underlines your access control system.

More about Aserto control plane

Aserto is built on top of Topaz, an open-source authorizer that is designed to be deployed right next to the application, in order to make access decisions as quickly as possible. You can deploy the authorizer as a sidecar or microservice, based on your application’s architecture.

The edge authorizer ingests the authorization policy and authorization data from your systems of record (e.g. IDP, source-code provider). It uses this data to determine if access will be granted or denied.

Aserto also provides a control plane to synchronize authorizers, and provide a high speed data fabric to get the most up-to-date information to the decision engine in real-time.

More about Aserto edge authorizers

An audit trail is a series of records of application events or user activities. Many applications provide some form of audit trail. Authentication systems like Auth0 or Azure Active Directory, for example, provide log-in trails which capture who logged in and when.

Aserto provide authorization decision logs. Decision logs are detailed records of every access decision made by an authorizer instance. They provide more in-depth information than just who logged in and when.

Authorization audit trails record who tried to access what, when, and why they succeeded or did not succeed. This additional level of detail is extremely helpful in compliance efforts, as well as when dealing with a breach, as it can help you assess the “blast radius” and focus your efforts on what has been compromised.

More about decision logs

Authentication is the process of proving that a user is who they claim to be. It begins and ends with login. Logged in users are authenticated users.

In the past, user IDs and passwords were the tools of the trade. Today, magic links, passwordless access, and multi-factor authentication are used, but it’s basically the same process.

Auth0, Okta, and Azure Active Directory are examples of authentication services. They store and govern secrets that are associated with users, and use that information to authenticate those users. They often provide single sign-on capabilities that simplifies the login process across many applications, and improves the user experience.

Authorization, or access control, is downstream from authentication. It is the process of determining the permissions and entitlements of authenticated users. Learn more about authentication vs authorization here.

In the context of an application, authorization determines what actions are available for users (what they can see, what they can edit, etc.). Application authorization systems can also inform UI behavior. For example, most modern applications ensure that only “Admins” can see the “Billing information” section and access it.

There are coarse and fine-grained authorization models, which differ in the level of granularity of enforcement. Coarse-grained authorization is useful when granting access over an entire system, while fine-grained access control enables more precision, often down to the resource-level (i.e. sharing a specific file vs an entire folder).

Authorization models typically implement one or more authorization patterns. The most three most popular patterns are:

1. Role-based access control (RBAC) where permissions are aggregated into roles that are assigned to users.
2. Attribute-based access control (ABAC) where user, resource, and environmental attributes determine access
3. Relationship-based access control (ReBAC), where the relationships between subjects (users/groups) and objects (e.g. tenants, projects, folders) are used to determine access.

RBAC offers coarse grained access - an “Editor” can edit any file. ABAC and ReBAC both offer finer-grained controls, with ABAC offering the most flexibility, and ReBAC providing a standard pattern for fine-grained control over individual resources.

More about RBAC, ABAC, and ReBAC.

Authorization policies list access rules. Based on these rules, access is granted or denied. Policies can be based on rules written in a domain specific language, like Rego, or on underlying data from the service that is being authorized.

Aserto lets you mix and match policies written in Rego or other domain-specific languages, with the underlying data from the application - more here.

Coarse-grained authorization, or coarse-grained access control, is the practice of determining access based on high-level criteria, such as the user’s role within the organization. Access granted by coarse-grained authorization systems is in itself coarse-grained: users are able to perform actions in the application based on their role, without regard to which resources they are performing those actions on.

Role-based access control (RBAC) is typically the authorization model used for coarse-grained scenarios. This is due to a combination of factors, including the simplicity of implementing RBAC models and the innate support most services have for users and groups, the building blocks of RBAC policies.

RBAC policies enforce access based on user roles. Permissions are aggregated into roles that are assigned to users. For example, a “Viewer” role will grant the can-view permission to anyone that holds it. The “Editor” role, on the other hand, will grant users can-view and can-edit permissions.

Build RBAC for React and Node.js app with this step-by-step guide.

Context-aware access, or context-based access controls is a method of granting access based on the context of the requestor. Context-based access control looks beyond just “who” requested access to “what”; it also reasons about “when” and “where” the request was made.

For example, you might have an “application engineer” role that provides access to your code base and infrastructure. The user should be able to access the code base or product server during working hours, but we might want to block access attempts in the middle of the night, or from unknown locations. Context-based authorization lets you do just that.

Customer identity and access management (CIAM) systems enable companies to securely collect, store and govern data about their external customers. They are also how organizations provide their external customers with self-serve access to their digital assets. These systems can be (and often are) distinct from the Employee / Workforce identity and access management systems that an organization uses for their internal employees.

Customer identity and access management systems provide a combination of capabilities to secure data collection and enable self-serve management of that data. These capabilities typically include self-serve registration and account management, consent and preference management, single sign-on (SSO), multi-factor authentication (MFA), and more. They make it easy for users to access the application securely and manage how it uses the data it collects about them.

Authorization decision logs are records of access control decisions, along with the context used to perform the authorization. They record who tried to access what, when, if they succeeded, and provide insight into the reasons that access was granted/denied.

Aserto automatically collects and aggregates decision logs for every decision made by the authorization engine. These aggregated logs can then be easily streamed into any SIEM or logging system for further analysis.

By capturing who access what, when, and why, decision logs improve an organization’s forensics while simplifying compliance and auditability.

More about decision logs

Delegated administrators are users with limited administrator capabilities.  In multi-tenant SaaS applications, delegated admins have the ability to invite users and grant them the relevant access and privileges. Most multi-tenant applications provide this functionality, allowing customers to self-serve to invite users and manage their entitlements. Salesforce, Hubspot, Jira, and Github are great examples of multi-tenant applications that provide customers with delegated administrator roles.

In single-tenant applications, delegated admins have some access to a subset of administrator privileges. For example, a ”billing admin” that can view and update billing information but cannot delete users from the tenant, and a “functional admin” that can edit and delete every resource in the system except for the billing information.

Aserto supports both functions. You can grant users administrative abilities over their account with multi-tenant RBAC, or create limited admin functions as custom roles.

Dynamic authorization, permissions, or entitlements refers to a method for determining access based on dynamic characteristics, such as attributes or context data. Rather than defining access based on static roles and standing permissions, dynamic authorization takes into account the conditions that apply when the access is being requested. Dynamic access answers the question “Does user X have the right permissions to access resources Y at this time?”

Attribute-based access controls (ABAC), policy-based access management (PBAM), and relationship-based access control (ReBAC) are all examples of dynamic authorization models. In these models, attributes, resource context, policy, and application data determine access. This enables finer-grained controls, while simplifying the administration of access to protected resources.

Software entitlements, also known as permissions or privileges, define the actions available to users accessing the system. Specifically, they define the actions (e.g. read, write, delete) that a user (human/machine) can perform over resources.

Fine-grained permissions, or fine-grained access controls, provide application owners with granular controls over the resources. Attribute-based access control (ABAC) and relationship-based access control (ReBAC) are two popular fine-grained authorization models.

More about ABAC and ReBAC

The phrase “Externalized authorization management” is used to describe external services that enable organizations to add fine-grained access controls to their applications and services.

Externalized authorization systems perform runtime authorization checks based on the user context and the authorization policy, either by sitting in front of the application, or being called directly by the application.

Organizations use externalized authorization management systems to add attribute and relationship-based access controls (ReBAC) to their internal or external applications. You can also use these systems to enforce role-based access control (RBAC), but they are typically used to provide finer-grained controls over protected resources.

Aserto is an externalized authorization management system. It enables applications to support any authorization model, from simple RBAC to finer-grained ABAC and resource-level ReBAC.

Fine-grained access control, aka fine-grained authorization or fine-grained permissions, refers to the ability to limit privileges to specific items, or levels within hierarchies of resources.

Google Drive is a great example of a system with fine-grained access controls. Its unified authorization system, Zanzibar, allows users to share folders and files with arbitrary levels of nesting with other users. Resource owners can also determine the permissions that recipients receive (e.g. view, comment, edit).

Slack is an example of a system with coarse-grained permissions. A full channel “member” can view every public channel; an Admin cannot pick and choose the channels they can access.

Aserto helps organizations add fine-grained permissions to their applications, using any authorization model they choose.

Everything about fine-grained access control is in this eBook!

Google Zanzibar is the centralized authorization system powering many Google applications, including Drive, Cloud, Calendar, and others. The authorization model used by Zanzibar is based on relationship-based access control (ReBAC).

The search giant wrote a paper describing Zanzibar, which has driven renewed interest in ReBAC, and has inspired multiple open-source implementations. One such implementation, Topaz, lets you enjoy the best of Zanzibar and Open Policy Agent (OPA), enabling you to support role, attribute, and relationship-based access control models (RBAC, ABAC, and ReBAC).

More about Google Zanzibar paper

Google app permissions are entitlements or privileges users hold over resources in various Google applications (e.g. Drive, Cloud). These permissions are managed and enforced by Google’s unified authorization system, Zanzibar.

Google Zanzibar uses a relationship-based access control (ReBAC) model to provide fine-grained access controls for Google apps. With ReBAC, permissions are defined by relationships between entities within a system.

On Drive, for example, a user can share a file, folder, folder containing folders, or even their entire directory with other users. They can also decide what actions are available to the receiving users by assigning them a relationship (Viewer, Commenter, Editor, Owner). The relationships between the subject (user/groups) and object of authorization (file, folder, directory) determine if access is granted.

More about Zanzibar, the engine behind Google app permissions.

Identity-first security is a new cybersecurity trend that directly follows from a zero-trust approach to security. Rather than trusting requests that are made from within a “secure perimeter,” identity-first security requires that every operation authenticates and authorizes the user. An identity-first approach can protect users, apps and data in ways that far exceed today's widely used network security tools.

COVID and the rise of remote work have pushed identity-first security to center stage. Traditional firewalls no longer cut it with a remote workforce. The zero-trust approach to security moves the focus from securing the network perimeter to securing identities. This approach recognizes that the foundational lever to secure access to critical resources is first and foremost, understanding the identity of users. Whether it’s an end-user, employee, partner, or machine every entity must be authenticated and authorized prior to receiving access.

Authentication is handled by an identity provider, while authorization is a separate process and must be handled by an authorization service. Aserto integrates with all the leading identity providers, allowing you to seamlessly share identity information from Auth0, Okta, Azure Active Directory and others with Aserto and use that in the authorization process.

Identity governance and administration (IGA) systems are admin-time authorization systems that provide IT with an administrative tool. IGAs certify and provision identity information, as well as manage access requests, certifications and governance of user access to business applications.

IGA systems integrate with third-party systems to pull in identity and entitlement information. This aggregated data is then available in one place for review. This information is also used to build reports and analytics that can be used to alert administrators of any events that are out of the ordinary.

Identity providers (IDPs) are systems that create, maintain, and manage digital identity information securely. They also provide authentication services, such as single sign-on (SS0) and multi-factor authentication (MFA) to their customers.

Identity providers make sure that users are who they claim to be. They ensure that only authenticated users can access the application. Once logged in, the process of authorization makes sure that users can access what they need to perform their duties.

More about authentication and authorization

Just in time access control, or just in time authorization refers to the practice of granting access to resources when users need them, and revoking access when they no longer need it. Some systems let you determine the amount of time the user will have access when you set up the access, others let you dynamically revoke access. Regardless, most fine-grained access control systems provide this functionality.

Based on the principle of least privilege, a user should only have access to what they need to perform their duty. However, the situation is oftentimes the opposite and over-provisioned roles are the norm. Just-in-time access is a way to combat over provisioned roles to limit the potential blast radius in the case of a breach.

An example of just-in-time access would be a support agent being granted access to customer records, when a ticket from that customer is assigned to them. Once the issue is resolved and the ticket closed, the support agent will lose access to that customer’s records.

Open Policy Agent (OPA) is an open-source general purpose decision engine that enables policy-based access management. OPA is popular among the Kubernetes audience as it is mostly used for infrastructure use-cases, such as Kubernetes admission control.

OPA uses authorization policies written in its domain specific language, Rego, to enforce access controls. These policies are decoupled from application code and stored in their own repository where it is versioned and stored. This practice is known as “policy-as-code.”

More about policy-as-code

Open Policy Agent policies include sets of rules that represent access control logic in OPA’s domain specific language called Rego. Rego is a logical language derived from Datalog.

OPA supports fine-grained access controls with attribute-based access control policies. While OPA provides sophisticated methods for policy management, the task of getting authorization data to the engine is left as an exercise for the developer.

Open Policy Contains (OPCR) is an open-source CNCF Sandbox Project that secures the software supply chain for OPA policies by making it easy to build them into immutable OCI images. The policy CLI provides a Docker-inspired workflow for building tagging, signing, and testing these policy images.

More about Open Policy Containers

Open-source authorization refers to open-source projects that can be used to build cloud-native access control systems. The source code of open-source authorization projects is exposed, making it available for use, modification, and distribution by users.

Open-source authorization examples include the Topaz authorization system and the Open Policy Agent general purpose engine, among many others.

Policy-based access management (PBAM), or policy-based access control (PBAC), allows organizations to enforce consistent entitlements across multiple applications by extracting authorization policy from application code and managing it centrally.

The policy is at the center of PBAM systems, which typically support finer-grained access control models, like ABAC. Overall, PBAM systems include the following capabilities:

• Fine-grained access controls
• Centralized policy management
• Policy-as-code workflows
• Centralized decision logs

More about policy-based access management

Rego is a domain-specific language used by OPA policies to define access control rules. Inspired by Datalog, Rego is a declarative language for defining rules. It can be thought of in the same way you think of a query language (like SQL).

​​Rego is an expressive policy language that can be used to construct a wide variety of RBAC and ABAC-style policies.

More about getting started with Rego

Role-based access control (RBAC) is an authorization model where permissions are tied to user roles. With RBAC, sets of permissions are aggregated into roles that are assigned to users. A user with the “Viewer” role is granted the can-view permission, while a user with the “Editor” role has both can-view and can-edit permissions.

RBAC is the simplest authorization model to implement. It is also a straightforward model to reason over. However, it relies on static roles and only provides coarse-grained access controls (for example, an “Editor” can edit every file in the system and “Viewer” can read any file). It also bears the risk of “role explosion,” where the sheer magnitude of roles in the system renders it unusable.

Overall, RBAC is a good entry point to authorization, but it isn’t sufficient when fine-grained control is required. In these situations, you’ll need to use attribute or relationship-based access control systems.

More about RBAC vs ABAC, and RBAC vs ReBAC.

Relationship-based access control, or relationship-based permissions, is a graph-based authorization model. Permissions are assigned via the relationships between subject (users/groups) and objects (e.g. tenants, projects, folders, individual resources). Data ownership, parent-child relationships, groups, and hierarchies (or relation chains), are all examples of relationships.

To set up a ReBAC system you need to model your application so it fits within the “tuple” schema of subject→object→relation. This opens the door for tailoring authorization to applications, by basing access control on the objects in your domain model. Whether you use tenants, or projects, or folders, you can map permissions between users and these objects with relationship-based access control.

Examples of graph-based ReBAC authorization systems can be found in social media, where users control the information they share with others based on the relationships they have. First degree contacts might be able to access your posts and pictures, while second or higher degree contacts can only view publicly accessible information, such as your name and bio.

Recently, Google Zanzibar has raised awareness of ReBAC. Zanzibar is the unified authorization system used across many Google applications, including Drive, Cloud, Maps, Calendar, and more. Zanzibar uses a relationship-based access control model.

More about ReBAC and Zanzibar

A relationship database stores and provides access to relationships between objects. Relationship databases are often implemented utilizing a relational model, with relationship tuples that store a named relationship between a subject and an object.

In the context of authorization, relationship databases are used to implement the Google Zanzibar model, i.e. relationship-based access control (ReBAC). With ReBAC, applications model their access control rules as { Subject, Relationship, Object } tuples.

A relations graph is a graph that represents relationships between entities. Facebook’s social graph is an example of a relations graph, one that maps out relationships between users. Facebook also lets users control what they share with others based on their relationships to the requesting users. This is an example of graph-based access control using the relationship-based access control (ReBAC) model.

A relations graph offers an intuitive authorization model when the application domain exposes relationships between users and objects.

Runtime access control refers to the process of making authorization decisions as requests come in. In contrast to admin-time authorization, which is set up prior to the user having any access and is coarse-grained, runtime authorization performs the access checks as the user is invoking operations over resources.

Runtime access control systems tend to provide finer-grained controls than admin-time systems. Runtime authorization systems support ABAC and ReBAC, while admin-time systems  tend to be role-based.

Aserto provides both admin-time authorization and runtime access control, allowing organizations to easily secure access to their internal and external applications.

Security information and event management (SIEM) systems provide organizations with the ability to detect, analyze, and respond to security threats before they harm business operations. SIEM solutions let you aggregate log data from all your digital assets and analyze that information in one place. You can use this data to recreate past events or analyze new suspicious events.

Aserto automatically collects and aggregates detailed authorization decision logs capturing who accessed what, when. These decision logs can be easily streamed to your favorite SIEM tool for further analysis.

While some authentication platforms offer some limited access controls, which typically includes baking roles or permissions into access tokens, modern authorization systems offer standalone products for building and governing application authorization.

Standalone access control systems typically integrate with other solutions in the identity and access management ecosystem, such as identity providers and user directory services.

Aserto is a standalone authorization system that helps developers add fine-grained authorization to their applications and centrally manage all of their policies, applications, users, and data. It is built on top of Topaz, a standalone open-source authorization system that supports RBAC, ABAC, ReBAC, and combinations out-of-the-box.

Topaz is an open-source, cloud-native authorizer you can deploy in your environment to add fine-grained access control to your applications, services, or APIs. It combines the best of Open Policy Agent and Zanzibar, allowing developers to combine RBAC, ABAC, and ReBAC. This is done via a built-in relationship database that supports the Zanzibar data-centric model, and Rego plug-ins to support integration with OPA policies.

Check out the repo

User roles are predefined categories assigned to users that define what they can access, oftentimes based on their function within the organization. In the context of an application, user roles are typically used for authorization. Some applications center their authorization model around roles, as in the case of role-based access control (RBAC). Other applications use roles in addition to other inputs, such as environmental attributes or relationships between users and resources to determine access.

More about RBAC vs ABAC

More about RBAC vs ReBAC

User permissions, also known as user entitlements or privileges, define the actions that users can take in a system. In the context of an application, user permissions define what users can see and do once logged into the application.

User permissions are typically aggregated into user roles. A “Viewer” role includes the can-view permissions, while the “Editor” role contains the can-view and can-edit permissions. With both permissions, the “Editor” can read and write the target resource.

Workforce identity and access management is a process to provide employees and other internal users, such as partners and contractors, secure access to organizational resources and tools.

Historically, workforce identity has been classified as an admin-time authorization solution that is set up once prior to the user getting any access. Today, there are services that are providing real-time workforce identity, enabling organizations to easily add or remove access when it is needed.

Aserto supports both workforce identity use cases and external/customer access control use cases.