Skip to main content

AuthZ Overview

Beta

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​

  • 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, roles, relationships, and rules defined. In an object-oriented perspective, this would be a class.

  • Resource - A resource is an instance of a resource type which 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 the 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 for which access is being granted to, and the subject is the object that is being given access.

  • Roles - 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 responsibility..

  • 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.

  • Rule - A rule defines which permissions a role can perform.

  • RBAC - Role-based authorization controls.

  • ReBAC - Relationship-based authorization controls.

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 in 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 the Resource Types. These roles will populate in the Roles & Access table and will need to have the permissions available to that role defined there.
  3. Define any desired relationships of the various resource types on the Resource Types page.
  4. Define the roles for the project in 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 to resource types.

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

  • ReBAC roles are granted specific permissions based on the relationship to that object, such as an author can delete their own article, but not another author’s article.

  1. 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 in 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 own articles; whereas a system_admin might have all access to any article.
  1. The final step is to assign the roles and relations to specific objects that exist in your app on the Assigned Roles and Relations page. For example, if your application has an article with an ID of healthy_eating, and a user with the ID of John, you can give John the editor role, by creating a tuple using the API endpoints, or using Assign Roles or Relations on the console.

Was this article helpful?

Contact us