Skip to main content

Modeling Authorization for an IoT Security System with Auth0 FGA

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.

This tutorial explains how to model permissions for an IoT system using Auth0 FGA.

What you will learn
  • How to model a permission system using Auth0 FGA
  • How to see Auth0 FGA Authorization in action by modeling an IoT Security Camera System

IoT

Explore the IoT sample on the Auth0 FGA Playground

Before You Start​

In order to understand this guide correctly you must be familiar with some Auth0 Fine Grained Authorization (FGA) concepts and know how to develop the things that we will list below.

Auth0 FGA Concepts​

It would be helpful to have an understanding of some concepts of Auth0 FGA before you start.

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 →

Modeling Concentric Relationships​

You need to know how to update the authorization model to allow having nested relations such as all writers are readers. Learn more → Used here to indicate that both IT Admins and Security Guards can view live video.

Direct Relationships​

You need to know how to disallow granting direct relation to an object and requiring the user to have a relation with another object that would imply a relation with the first one. Learn more → Used here to indicate that "Rename Device" is a permission that cannot be assigned directly, but can only be granted through the "IT Admin" role.

User Groups​

You need to know how to add users to groups and create relationships between groups of users and an object. Learn more →

Used here to indicate that security guards on a certain group are security guards on a device in that group.

Concepts & Configuration Language​

What You Will You Be Modeling​

In this tutorial, you will build an authorization model for a sample IoT Security Camera System (detailed below) using Auth0 Fine Grained Authorization (FGA). You will use some scenarios to validate the model.

The goal by the end of this post is to ask Auth0 FGA: Does person X have permission to perform action Y on device Z? In response, you want to either get a confirmation that person X can indeed do that, or a rejection that they cannot.

Requirements​

These are the requirements:

  • Security guards have access to view live and recorded video from Devices.
  • IT Admins can view live and recorded videos, as well as rename Devices.
  • To make access management easier, Devices can be grouped into Device Groups. Security guards with access to the Device Group are Security Guards with access to each Device in the group. Similarly for IT Admins.

Defined Scenarios​

Use the following scenarios to be able to validate whether the model of the requirements is correct.

There will be the following users:

  • Anne
  • Beth
  • Charles
  • Dianne

These users have the following roles and permissions:

  • Anne is a Security Guard with access to only Device 1
  • Beth is an IT Admin with access to only Device 1
  • Charles is a Security Guard with access to Device 1 and everything in Device Group 1 (which is Device 2 and Device 3)
  • Dianne is an IT Admin with access to Device 1 and everything in Device Group 1

Image showing requirements

caution

In production, it is highly recommended to use unique, immutable identifiers. Names are used in this article to make it easier to read and follow.

Modeling Device Authorization​

The Auth0 Fine Grained Authorization (FGA) service is based on Zanzibar, a Relationship Based Access Control system. This means it relies on object and user relations to perform authorization checks.

Starting with devices, you will learn how to express the requirements in terms of relations you can feed into Auth0 Fine Grained Authorization (FGA).

01. Writing the Initial Model for a Device​

The requirements stated:

  • Security guards have access to view live and recorded video from Devices.
  • IT Admins can view live and recorded videos, as well as rename Devices.

The goal is to ask Auth0 FGA whether person X has permission to perform action Y on device Z. To start, you will set aside the Security Guard and IT Admin designations and focus on the actions a user can take.

The actions users can take on a device are: view live videos, view recorded videos, and rename devices. Mapping them to relations, they become: live_video_viewer, recorded_video_viewer, device_renamer.

In Auth0 FGA, the authorization model for the device would be:

type device
  relations
    define live_video_viewer as self
    define recorded_video_viewer as self
    define device_renamer as self

02. Inserting some relationship tuples​

The requirements are:

  • Anne is a Security Guard with access to only Device 1
  • Beth is an IT Admin with access to only Device 1
  • Security Guards can view live and recorded video
  • IT Admins can view live and recorded video and rename devices

Before we tackle the problem of users access to device based on their role, we will try to grant user access based on their view relationship directly.

We will first focus on Anne and Beth's relationship with Device 1.

To add Anne as live_video_viewer of device:1:

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: [
      { user: 'anne', relation: 'live_video_viewer', object: 'device:1'}
    ]
  }
});

To add Anne as recorded_video_viewer of device:1

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: [
      { user: 'anne', relation: 'recorded_video_viewer', object: 'device:1'}
    ]
  }
});

Likewise, we will add Beth's relationship with device:1.

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: [
      { user: 'beth', relation: 'live_video_viewer', object: 'device:1'},
      { user: 'beth', relation: 'recorded_video_viewer', object: 'device:1'},
      { user: 'beth', relation: 'device_renamer', object: 'device:1'}
    ]
  }
});

Verification​

Now that you have some relationship tuples added, you can start using it to ask some questions, e.g., whether a person has access to rename a device.

First, you will find out if anne has permission to view the live video on device:1, then you will see if anne can rename device:1.

Anne has live_video_viewer relationship with device:1.

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: 'anne',
    relation: 'live_video_viewer',
    object: 'device:1',
  },});

// allowed = true

On the other hand, Anne does not have device_renamer relationship with device:1.

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: 'anne',
    relation: 'device_renamer',
    object: 'device:1',
  },});

// allowed = false

Now, check the other relationships fore Anne and Beth.

UserObjectRelationQueryRelation?
annedevice:1live_video_vieweris anne related to device:1 as live_video_viewer?Yes
bethdevice:1live_video_vieweris beth related to device:1 as live_video_viewer?Yes
annedevice:1recorded_video_vieweris anne related to device:1 as recorded_video_viewer?Yes
bethdevice:1recorded_video_vieweris beth related to device:1 as recorded_video_viewer?Yes
annedevice:1device_renameris anne related to device:1 as device_renamer?No
bethdevice:1device_renameris beth related to device:1 as device_renamer?Yes

03. Updating our Authorization Model to facilitate future changes​

Notice how you had to add the Anne and Beth as direct relations to all the actions they can take on Device 1 instead of just stating that they are related as Security Guard or IT Admin, and having the other permissions implied? In practice this might have some disadvantages: if your authorization model changes, (e.g so that Security Guards can no longer view previously recorded videos), you would need to change relationship tuples in the system instead of just changing the configuration.

We can address this by using concentric relation models. It allows you to express that sets of users who have a relation X to the object also have relation Y. For example, anyone that is related to the device as a security_guard is also related as a live_video_viewer and recorded_video_viewer, and anyone who is related to the device as an it_admin is also related as a live_video_viewer, a recorded_video_viewer, and a device_renamer.

At the end you want to make sure that checking if Anne, Beth, Charles, or Dianne have permission to view the live video or rename the device, will get you the correct answers back.

The resulting authorization model is:

type device
  relations
    define it_admin as self
    define security_guard as self
    define live_video_viewer as self or it_admin or security_guard
    define recorded_video_viewer as self or it_admin or security_guard
    define device_renamer as self or it_admin

The requirements are:

  • Anne and Charles are Security Guards with access Device 1
  • Beth and Dianne are IT Admins with access Device 1
  • Security Guards can view live and recorded video
  • IT Admins can view live and recorded video and rename devices

Instead of adding different relationship tuples with direct relations to the actions they can take, as you did in the previous section, you will only add the relation to their role: it_admin or security_guard.

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: [
      { user: 'anne', relation: 'security_guard', object: 'device:1'},
      { user: 'beth', relation: 'it_admin', object: 'device:1'},
      { user: 'charles', relation: 'security_guard', object: 'device:1'},
      { user: 'dianne', relation: 'it_admin', object: 'device:1'}
    ]
  }
});

Verification​

We can now verify whether charles is related to device:1 as live_video_viewer.

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: 'charles',
    relation: 'live_video_viewer',
    object: 'device:1',
  },});

// allowed = true

Check the other relationships for anne, beth, charles and dianne.

UserObjectRelationQueryRelation?
annedevice:1live_video_vieweris anne related to device:1 as live_video_viewer?Yes
bethdevice:1live_video_vieweris beth related to device:1 as live_video_viewer?Yes
annedevice:1recorded_video_vieweris anne related to device:1 as recorded_video_viewer?Yes
bethdevice:1recorded_video_vieweris beth related to device:1 as recorded_video_viewer?Yes
annedevice:1device_renameris anne related to device:1 as device_renamer?No
bethdevice:1device_renameris beth related to device:1 as device_renamer?Yes
charlesdevice:1live_video_vieweris charles related to device:1 as live_video_viewer?Yes
diannedevice:1live_video_vieweris dianne related to device:1 as live_video_viewer?Yes
charlesdevice:1recorded_video_vieweris charles related to device:1 as recorded_video_viewer?Yes
diannedevice:1recorded_video_vieweris dianne related to device:1 as recorded_video_viewer?Yes
charlesdevice:1device_renameris charles related to device:1 as device_renamer?No
diannedevice:1device_renameris dianne related to device:1 as device_renamer?Yes

04. Modeling Device Groups​

Now that you are done with devices. Let us tackle device groups.

The requirements regarding device groups were:

  • Devices can be grouped into Device Groups
  • Security guards with access to the Device Group are Security Guards with access to the Devices within the Device Group. Similarly for IT Admins

The type definition for the device group:

type device_group
  relations
    define it_admin as self
    define security_guard as self

With this change, the full authorization model becomes:

type device
  relations
    define it_admin as self
    define security_guard as self
    define live_video_viewer as self or it_admin or security_guard
    define recorded_video_viewer as self or it_admin or security_guard
    define device_renamer as self or it_admin
type device_group
  relations
    define it_admin as self
    define security_guard as self

Updating relationship tuples on roles​

Remember that Charles is a Security Guard, and Dianne an IT Admin on Group 1, enter the relationship tuples below to reflect that.

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: [
      { user: 'charles', relation: 'security_guard', object: 'device_group:group1'},
      { user: 'dianne', relation: 'it_admin', object: 'device_group:group1'}
    ]
  }
});

You still need to give all the security guards of group1 a security_guard relation to devices 2 and 3, and similarly for IT Admins. Add the following relationship tuples to do that.

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: [
      { user: 'device_group:group1#security_guard', relation: 'security_guard', object: 'device:2'},
      { user: 'device_group:group1#security_guard', relation: 'security_guard', object: 'device:3'},
      { user: 'device_group:group1#it_admin', relation: 'it_admin', object: 'device:2'},
      { user: 'device_group:group1#it_admin', relation: 'it_admin', object: 'device:3'}
    ]
  }
});

Verification​

Now that you have finalized the model and added the relationship tuples, you can start asking some queries. Try asking the same queries you did earlier but on device 2 instead of device 1.

We can ask is dianne related to device:2 as live_video_viewer?

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: 'dianne',
    relation: 'live_video_viewer',
    object: 'device:2',
  },});

// allowed = true

Type any of the following queries in the TUPLE QUERIES section and press ENTER on your keyboard to see the results.

UserObjectRelationQueryRelation?
annedevice:2live_video_vieweris anne related to device:2 as live_video_viewer?No
bethdevice:2live_video_vieweris beth related to device:2 as live_video_viewer?No
annedevice:2recorded_video_vieweris anne related to device:2 as recorded_video_viewer?No
bethdevice:2recorded_video_vieweris beth related to device:2 as recorded_video_viewer?No
annedevice:2device_renameris anne related to device:2 as device_renamer?No
bethdevice:2device_renameris beth related to device:2 as device_renamer?No
charlesdevice:2live_video_vieweris charles related to device:2 as live_video_viewer?Yes
diannedevice:2live_video_vieweris dianne related to device:2 as live_video_viewer?Yes
charlesdevice:2recorded_video_vieweris charles related to device:2 as recorded_video_viewer?Yes
diannedevice:2recorded_video_vieweris dianne related to device:2 as recorded_video_viewer?Yes
charlesdevice:2device_renameris charles related to device:2 as device_renamer?No
diannedevice:2device_renameris dianne related to device:2 as device_renamer?Yes

05. Disallow Direct Relationships to users​

Notice that despite following Step 03, anne and beth still have direct relations to all the actions they can take on device:1.

Updating the authorization model​

anne is a live_video_viewer by both her position as security_guard as well as her direct relationship assignment. This is undesirable. Imagine anne left her position of security_guard and she will still have live_video_viewer access to device:1.

To remedy this, remove self from live_video_viewer, recorded_video_viewer and device_renamer. This denies direct relations to live_video_viewer, recorded_video_viewer and device_renamer from having an effect. To do this:

type device
  relations
    define it_admin as self
    define security_guard as self
    define live_video_viewer as it_admin or security_guard
    define recorded_video_viewer as it_admin or security_guard
    define device_renamer as it_admin
type device_group
  relations
    define it_admin as self
    define security_guard as self
info

Notice that any reference to the direct relationship keyword (self in the friendly Syntax - or this in the api syntax) has been removed. That indicates that a user cannot have a direct relationship with an object in this type.

With this change, anne can no longer have a live_video_viewer permission for device:1 except through having a security_guard or it_admin role first, and when she loses access to that role, she will automatically lose access to the live_video_viewer permission.

Verification​

Now that direct relationship is denied, we should see that anne has live_video_viewer relation to device:1 solely based on her position as security_guard to device:1. Let's find out.

To test this, we can add a new user emily. Emily is not a security_guard nor an it_admin. However, we attempt to access via direct relations by adding the following relationship tuples:

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: [
      { user: 'emily', relation: 'live_video_viewer', object: 'device:1'},
      { user: 'emily', relation: 'recorded_video_viewer', object: 'device:1'},
      { user: 'emily', relation: 'device_renamer', object: 'device:1'}
    ]
  }
});

Now try to query is emily related to device:1 as live_video_viewer?. The returned result should be emily is not related to device:1 as live_video_viewer. This confirms that direct relations have no effect on the live_video_viewer relations, and that is because the direct relationship keyword (self) was removed from the relation configuration.

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: 'emily',
    relation: 'live_video_viewer',
    object: 'device:1',
  },});

// allowed = false

Query on the other relationships and you will see:

UserObjectRelationQueryRelation?
emilydevice:1recorded_video_vieweris emily related to device:1 as recorded_video_viewer?No
emilydevice:1device_renameris emily related to device:1 as device_renamer?No

Summary​

In this post, you were introduced to fine grain authentication and Auth0 Fine Grained Authorization (FGA).

Upcoming posts will dive deeper into Auth0 Fine Grained Authorization (FGA), introducing concepts that will improve on the model you built today, and tackling more complex permission systems, with more relations and requirements that need to be met.

IoT

Explore the IoT sample on the Auth0 FGA Playground

Exercises for You​

  • Try adding a second group tied to devices 4 and 5. Add only Charles and Dianne to this group, then try to run queries that would validate your model.
  • Management has decided that Security Guards can only access live videos, and instituted a new position called Security Officer who can view both live and recorded videos. Can you update the authorization model to reflect that?

Have Feedback?

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