Skip to main content

Modeling Roles and Permissions

note
Auth0 Fine Grained Authorization (FGA) is the early-stage product we are building at Auth0 to solve fine-grained authorization at scale. Sign up for the Developer Community Preview to try it out, and join our Discord community if you are interested in learning more about our plans.

Please note that at this point in time, it is not considered production-ready and does not come with any SLAs; availability and uptime are not guaranteed. Limitations of Auth0 FGA during the Developer Community Preview can be found here.

In this guide you will learn how to model roles and permissions model within Auth0 FGA using the authorization model and relationship tuple.

  • Roles are assigned to usersor a group of users, where any user can have more than one role (editor, owner, etc..).
  • Permissions are what allows users to access certain objects based on their specific roles (device_renamer, channel_archiver, etc..).

For example, the role viewer of a trip can have permissions to view bookings or the role owners can have permissions to add/view bookings to a trip.

When to use

When trying to create a role and permissions model within Auth0 FGA.:

  • Create roles by creating relations that can be directly assigned to users
  • Assign permissions by creating relations that users get through other relations

For example:

  • Grant someone an admin role that can edit and read a document
  • Grant someone a security_guard role that can live_video_viewer on a device
  • Grant someone a viewer role that can view_products on a shop

There are advantages to implementing roles and permissions within Auth0 FGA, such as:

  • Breaking down existing roles to have more fine grained permissions. This allows your application to check whether a user has access to a certain object without having to explicitly check that specific users role.
  • Introduce new roles/permissions or consolidate roles without affecting your application behavior. For example: if in your app all the checks are for the fine permissions check('bob', 'booking_adder', 'trip:Europe') instead of check('bob', 'owner', 'trip:Europe'), and then you later decide owners can no longer add bookings to a trip, you can remove the relation within the trip type with no code changes in your application, and all the permissions will automatically honor the change.

Before you start​

In order to understand this guide correctly you must be familiar with some Auth0 FGA Concepts and know how to develop the things that we will list below.

Assume that you have the following authorization model.
You have a type called trip that users can be related to as viewer and/or an owner.

type trip
  relations
    define owner as self
    define viewer as self

In addition, you will need to know the following:

Modeling Basics​

You need to know how to create an authorization model and create a relationship tuple to grant a user access to an object. Learn more →

Auth0 FGA Concepts​

  • A Type: a class of objects that have similar characteristics
  • A User: an entity in the system that can be related to an object
  • A Relation: is a string defined in the type definition of an authorization model that defines the possibility of a relationship between objects of this type and other users in the system
  • An Object: represents an entity in the system. Users' relationships to it can be define through relationship tuples and the authorization model
  • A Relationship Tuple: a grouping consisting of a user, a relation and an object stored in Auth Auth0 FGA
  • A Relationship: Auth0 FGA will be called to check if there is a relationship between a user and an object, indicating that the access is allowed
  • Direct Relationship Keyword: The self keyword can be used to indicate direct relationships between users and objects
  • A Check API Request the Check API Request is used to check for relationships between users and objects

The Playground

Try this guide out on the Auth0 FGA Playground

Step by Step​

To illustrate modeling Roles and Permissions in Auth0 FGA, we will use a trip booking system where you can have owners and/or viewers that can have more granular permissions such as adding bookings to a trip or viewing bookings on it.

In order to represent this, we need to:

  1. Understand how roles are related to direct relations for our trip booking system
  2. Adding implied relations to existing authorization model to define permissions for bookings
  3. Checking user roles and their permissions based on *relationship tuples* for direct and implied relations

01. Understand how roles work within our trip booking system​

Relating roles within Auth0 FGA can be best described as the following: Roles are relations that can be directly assigned to users. Looking at our authorization model, our roles would then be owner and viewer. Meaning that a specific user can be an owner and/or a viewer.

type trip
  relations
    define owner as self
    define viewer as self

02. Adding permissions for bookings​

Permissions within Auth0 Fine Grained Authorization (FGA) can be best described as the following: Permissions are relations that users get only through other relations. To represent permissions, we avoid adding the direct relationship keyword (self) to the relation in the authorization model. Instead, we define the relation from other relations to indicate that it is a permission granted to and implied from a different relation.

To add permissions related to bookings, we can add new relations to the trip object type denoting the various actions a user can take on trips (view, edit, delete, rename, etc...)

To allow viewers of a trip to have permissions to view bookings and owners to have permissions to add/view bookings, we would modify the type as the following:

type trip
  relations
    define owner as self
    define viewer as self
    define booking_adder as owner
    define booking_viewer as viewer or owner

Note: notice how both booking_viewer and booking_adder don't have the self syntax, this is to ensure that the relation can only be assigned through the role and not directly.

03. Checking user roles and their permissions​

Now that our type definitions reflects the roles and permissions on how bookings can be viewed/added. Let's create relationship tuples to assign roles to users and then checkif users have the proper permissions.

Let us create two relationship tuples:

  1. that gives bob the role of viewer on trip: Europe.
  2. that gives alice the role of owner on trip: Europe.
Initialize the SDK
// FGA_ENVIRONMENT can be "us" (default if not set) for Developer Community Preview or "playground" for the Playground API
// import the SDK
const { Auth0FgaApi } = require('@auth0/fga');

// Initialize the SDK
const fgaClient = new Auth0FgaApi({
  environment: process.env.FGA_ENVIRONMENT,
  storeId: process.env.FGA_STORE_ID,
  clientId: process.env.FGA_CLIENT_ID,
  clientSecret: process.env.FGA_CLIENT_SECRET,
});

await fgaClient.write({
  writes: {
    tuple_keys: [
      // Add bob as viewer on trip:Europe
      { user: 'bob', relation: 'viewer', object: 'trip:Europe'},
      // Add alice as owner on trip:Europe
      { user: 'alice', relation: 'owner', object: 'trip:Europe'}
    ]
  }
});

Now we can check: is bob allowed to view bookings on trip Europe?

Initialize the SDK
// FGA_ENVIRONMENT can be "us" (default if not set) for Developer Community Preview or "playground" for the Playground API
// import the SDK
const { Auth0FgaApi } = require('@auth0/fga');

// Initialize the SDK
const fgaClient = new Auth0FgaApi({
  environment: process.env.FGA_ENVIRONMENT,
  storeId: process.env.FGA_STORE_ID,
  clientId: process.env.FGA_CLIENT_ID,
  clientSecret: process.env.FGA_CLIENT_SECRET,
});

// Run a check
const { allowed } = await fgaClient.check({
  tuple_key: {
    user: 'bob',
    relation: 'booking_viewer',
    object: 'trip:Europe',
  },});

// allowed = true

bob is a booking_viewer because of the following chain of resolution:

  1. bob is a viewer on trip: Europe
  2. Any user related to the object trip:Europe as viewer is also related as a booking_viewer (i.e usersRelatedToObjectAs: viewer)
  3. Therefore, all viewers on a given trip are booking_viewers

To confirm that bob is not allowed to add bookings on trip Europe, we can do the following check:

Initialize the SDK
// FGA_ENVIRONMENT can be "us" (default if not set) for Developer Community Preview or "playground" for the Playground API
// import the SDK
const { Auth0FgaApi } = require('@auth0/fga');

// Initialize the SDK
const fgaClient = new Auth0FgaApi({
  environment: process.env.FGA_ENVIRONMENT,
  storeId: process.env.FGA_STORE_ID,
  clientId: process.env.FGA_CLIENT_ID,
  clientSecret: process.env.FGA_CLIENT_SECRET,
});

// Run a check
const { allowed } = await fgaClient.check({
  tuple_key: {
    user: 'bob',
    relation: 'booking_adder',
    object: 'trip:Europe',
  },});

// allowed = false

We can also check: is alice allowed to view and add bookings on trip Europe?

Initialize the SDK
// FGA_ENVIRONMENT can be "us" (default if not set) for Developer Community Preview or "playground" for the Playground API
// import the SDK
const { Auth0FgaApi } = require('@auth0/fga');

// Initialize the SDK
const fgaClient = new Auth0FgaApi({
  environment: process.env.FGA_ENVIRONMENT,
  storeId: process.env.FGA_STORE_ID,
  clientId: process.env.FGA_CLIENT_ID,
  clientSecret: process.env.FGA_CLIENT_SECRET,
});

// Run a check
const { allowed } = await fgaClient.check({
  tuple_key: {
    user: 'alice',
    relation: 'booking_viewer',
    object: 'trip:Europe',
  },});

// allowed = true
Initialize the SDK
// FGA_ENVIRONMENT can be "us" (default if not set) for Developer Community Preview or "playground" for the Playground API
// import the SDK
const { Auth0FgaApi } = require('@auth0/fga');

// Initialize the SDK
const fgaClient = new Auth0FgaApi({
  environment: process.env.FGA_ENVIRONMENT,
  storeId: process.env.FGA_STORE_ID,
  clientId: process.env.FGA_CLIENT_ID,
  clientSecret: process.env.FGA_CLIENT_SECRET,
});

// Run a check
const { allowed } = await fgaClient.check({
  tuple_key: {
    user: 'alice',
    relation: 'booking_adder',
    object: 'trip:Europe',
  },});

// allowed = true

alice is a booking_viewer and booking_adder because of the following chain of resolution:

  1. alice is a owner on trip: Europe
  2. Any user related to the object trip:Europe as owner is also related as a booking_viewer
  3. Any user related to the object trip:Europe as owner is also related as a booking_adder
  4. Therefore, all owners on a given trip are booking_viewers and booking_adders on that trip
caution

Note: Make sure to use unique ids for each object and user within your application domain when creating relationship tuples for Auth0 Fine Grained Authorization (FGA). We are using first names and simple ids to just illustrate an easy-to-follow example.

Check the following sections for more on how to model for roles and permissions.
Modeling Concepts: Concentric Relationships

Learn about how to represent a concentric relationships in Auth0 FGA.

Modeling Google Drive

See how to indicate that editors are commenters and viewers in Google Drive.

Modeling GitHub

See how to indicate that repository admins are writers and readers in GitHub.

Have Feedback?

Join us on the Discord community if you have any questions or suggestions.