Skip to main content

AuthZ Overview

Get an overview of AuthZ - key terminology and setup process explained

AuthZ is an authorization service that allows users to define permissions and policies outside of their code. Users can define resources and permissions for each resource to easily construct permissions. AuthZ also supports importing identities that can then be mapped to roles and groups to simplify access management.

Definitions​

Schema​

The overall structure of an access control system, including defined roles, resource types, relationships, and the basic framework for policies.

Resource Type​

A resource type is used to define resources or subject types that make up your application. Each resource type will have its own set of permissions and roles, relationships, rules, and functions defined. From an object-oriented perspective, this would be a class.

Resource​

A resource is an instance of a resource type that will be checked for specific permissions. In an object-oriented perspective, this is the object, i.e. the specific instance of the class.

Resource ID​

A resource ID is a unique identifier referencing a specific resource.

Subject​

A subject is an instance of a resource type that is being granted a role or relation. Resource Types can contextually represent either the resource or subject when assigning roles and relations to objects in your application. The resource is the object to which access is being granted, and the subject is the object that is being given access.

RBAC (Role-Based Access Control)​

A model of access control where permissions are assigned to roles, and users are granted access to resources based on the roles they hold. Access decisions are determined by the user's role, which is predefined within the system.

Role​

A role is a collection of permissions that you can assign to a user. These often represent a hierarchy within an organization, a specific job title, or a responsibility.

Rule​

A rule defines which permissions a role can perform.

ReBAC (Relationship-Based Access Control)​

A model of access control where permissions are granted based on the relationship between the user and the resource. Access decisions are made by evaluating the user's relationship to the resource, such as ownership or management.

Relationship​

A relationship defines the association between resource types. For example, a file could have a parent folder and a user could be a member of a group.

Tuple​

A data structure that represents a specific instance of a relationship in ReBAC, typically consisting of a subject, a relationship, and a resource. For example:

{
  "resource": {
    "type": "blog_post",
    "id": "cats"
  },
  "relation": "author",
  "subject": {
    "type": "user",
    "id": "Rachel"
  }
}

ABAC (Attribute-Based Access Control)​

An access control model where decisions are based on attributes of the user, resource, and environment, rather than relying solely on predefined roles or relationships.

Attribute​

A characteristic or property of a user, resource, or environment used to make access control decisions, such as a user’s role, the sensitivity of a resource, or the time of access.

Policy​

A set of rules that define the conditions under which access to a resource is granted or denied, based on attributes.

Condition​

A specific criterion within a policy that must be met for access to be granted, often based on attribute comparisons (e.g., user.role == "admin").

Function​

A logical expression that evaluates attributes within a request to determine if a condition is met. Functions can reference dynamic data paths for evaluation. In AuthZ, ABAC functions are resource type-specific and can be reused across different role permissions for the same resource type.

Variable Path​

A reference to a specific attribute in a structured JSON object using dot notation.

For example, request.attributes.country refers to the value associated with the attributes.country key in the request data, such as "US", if the request body contains:

{
  ...,
  "attributes": {
    {
      "country": "US"
    }
  }
}

For nested attributes, you can use dot notation to drill down into the data structure, like request.attributes.device.type, etc.

Context​

The set of circumstances and conditions that surround a policy evaluation, including all relevant attributes of the user, resource, resource relationships, and environmental factors such as time and location. The context ultimately helps define who (subject) can act on what (resource) and in which environment.

Operator​

An operator used to compare attribute values in a function, such as ==, !=, >, <, >=, <=, or in.

Policy Evaluation​

The process of applying policies to a specific access request to determine whether the request should be allowed or denied, based on the conditions defined within the policy.

Setup overview​

When setting up AuthZ for a project, the general process is as follows:

  1. Create the resource types that define the subjects and objects within your system and specify the permissions that exist for each resource type on the Resource Types page. It is not defining specific objects, but types of objects. Examples of this would be users, articles, images, files, folders, etc. Common permissions for resource types would be CRUD (create, read, update, and delete). However, there are no limits to how many permissions can be created, only that each permission must be a unique string.

  2. Resource roles can be defined for each resource type in Resource Types. A role will populate in the Roles & Access table and the permissions available for this role will need to be defined on the resource type.

  3. Define any desired relationships of the various resource types on the Resource Types page.

  4. Define roles for your project on the Roles & Access page. Roles are types of users in your project, such as an author, editor, reviewer, etc. The various roles usually have different permissions available to them based on their associations with resource types.

    • RBAC roles are granted permissions over every object of a resource type, such as a system_admin that can update any article.

    • ReBAC roles are granted specific permissions based on the relationship to an object, such as an author can delete their article, but not another author’s article. These resource type-specific roles can also be defined on the Resource Types page.

  5. The Roles & Access page can then be used to map Roles to Resource Types and set permissions that each role is allowed to perform on them. An example of this is an author that writes an article is the owner, and can delete that article, but not the article created by another author. This might have already been done on the Resource Types page.

    This is where you can fine-tune the access of all the roles in your system. Using the example from step 1, a reviewer might only be able to read and update articles; an author might be able to create, read, update, and delete their articles; whereas a system_admin might have all access to any article.

  6. On the Roles & Access page, you can optionally define attribute-based conditions for a role permission that must be met at runtime for the permission to apply. For example, you might restrict an editor’s permission to update an article based on whether it has been published.

  7. The final step is to assign roles and relations to specific objects in your app on the Assign Roles or Relations page in the Pangea User Console. For example, if your application has an article with the ID healthy_eating and a user with the ID Jared, you can assign Jared the editor role by creating a tuple using the API endpoints or the Assign Roles or Relations feature.

Was this article helpful?

Contact us