Skip to main content

Modeling Authorization for an IoT Security System with OpenFGA

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

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

Before you start

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

OpenFGA concepts

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

Direct access

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 be modeling

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

The goal by the end of this post is to ask OpenFGA: 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 OpenFGA 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 OpenFGA.

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 OpenFGA 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 OpenFGA, the authorization model for the device would be:

model
schema 1.1

type user

type device
relations
define live_video_viewer: [user]
define recorded_video_viewer: [user]
define device_renamer: [user]

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
// ApiTokenIssuer, ApiAudience, ClientId and ClientSecret are optional.
// import the SDK
const { OpenFgaClient } = require('@openfga/sdk');

// Initialize the SDK with no auth - see "How to setup SDK client" for more options
const fgaClient = new OpenFgaClient({
apiUrl: process.env.FGA_API_URL, // required, e.g. https://api.fga.example
storeId: process.env.FGA_STORE_ID,
authorizationModelId: process.env.FGA_MODEL_ID, // Optional, can be overridden per request
});

await fgaClient.write({
writes: [
{"user":"user:anne","relation":"live_video_viewer","object":"device:1"}
],
}, {
authorization_model_id: "01HVMMBCMGZNT3SED4Z17ECXCA"
});

To add Anne as recorded_video_viewer of device:1

Initialize the SDK
// ApiTokenIssuer, ApiAudience, ClientId and ClientSecret are optional.
// import the SDK
const { OpenFgaClient } = require('@openfga/sdk');

// Initialize the SDK with no auth - see "How to setup SDK client" for more options
const fgaClient = new OpenFgaClient({
apiUrl: process.env.FGA_API_URL, // required, e.g. https://api.fga.example
storeId: process.env.FGA_STORE_ID,
authorizationModelId: process.env.FGA_MODEL_ID, // Optional, can be overridden per request
});

await fgaClient.write({
writes: [
{"user":"user:anne","relation":"recorded_video_viewer","object":"device:1"}
],
}, {
authorization_model_id: "01HVMMBCMGZNT3SED4Z17ECXCA"
});

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

Initialize the SDK
// ApiTokenIssuer, ApiAudience, ClientId and ClientSecret are optional.
// import the SDK
const { OpenFgaClient } = require('@openfga/sdk');

// Initialize the SDK with no auth - see "How to setup SDK client" for more options
const fgaClient = new OpenFgaClient({
apiUrl: process.env.FGA_API_URL, // required, e.g. https://api.fga.example
storeId: process.env.FGA_STORE_ID,
authorizationModelId: process.env.FGA_MODEL_ID, // Optional, can be overridden per request
});

await fgaClient.write({
writes: [
{"user":"user:beth","relation":"live_video_viewer","object":"device:1"},
{"user":"user:beth","relation":"recorded_video_viewer","object":"device:1"},
{"user":"user:beth","relation":"device_renamer","object":"device:1"}
],
}, {
authorization_model_id: "01HVMMBCMGZNT3SED4Z17ECXCA"
});

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
// ApiTokenIssuer, ApiAudience, ClientId and ClientSecret are optional.
// import the SDK
const { OpenFgaClient } = require('@openfga/sdk');

// Initialize the SDK with no auth - see "How to setup SDK client" for more options
const fgaClient = new OpenFgaClient({
apiUrl: process.env.FGA_API_URL, // required, e.g. https://api.fga.example
storeId: process.env.FGA_STORE_ID,
authorizationModelId: process.env.FGA_MODEL_ID, // Optional, can be overridden per request
});

// Run a check
const { allowed } = await fgaClient.check({
user: 'user:anne',
relation: 'live_video_viewer',
object: 'device:1',
}, {
authorization_model_id: '01HVMMBCMGZNT3SED4Z17ECXCA',
});

// allowed = true

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

Initialize the SDK
// ApiTokenIssuer, ApiAudience, ClientId and ClientSecret are optional.
// import the SDK
const { OpenFgaClient } = require('@openfga/sdk');

// Initialize the SDK with no auth - see "How to setup SDK client" for more options
const fgaClient = new OpenFgaClient({
apiUrl: process.env.FGA_API_URL, // required, e.g. https://api.fga.example
storeId: process.env.FGA_STORE_ID,
authorizationModelId: process.env.FGA_MODEL_ID, // Optional, can be overridden per request
});

// Run a check
const { allowed } = await fgaClient.check({
user: 'user:anne',
relation: 'device_renamer',
object: 'device:1',
}, {
authorization_model_id: '01HVMMBCMGZNT3SED4Z17ECXCA',
});

// 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:

model
schema 1.1

type device
relations
define it_admin: [user]
define security_guard: [user]
define live_video_viewer: [user] or it_admin or security_guard
define recorded_video_viewer: [user] or it_admin or security_guard
define device_renamer: [user] 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
// ApiTokenIssuer, ApiAudience, ClientId and ClientSecret are optional.
// import the SDK
const { OpenFgaClient } = require('@openfga/sdk');

// Initialize the SDK with no auth - see "How to setup SDK client" for more options
const fgaClient = new OpenFgaClient({
apiUrl: process.env.FGA_API_URL, // required, e.g. https://api.fga.example
storeId: process.env.FGA_STORE_ID,
authorizationModelId: process.env.FGA_MODEL_ID, // Optional, can be overridden per request
});

await fgaClient.write({
writes: [
{"user":"user:anne","relation":"security_guard","object":"device:1"},
{"user":"user:beth","relation":"it_admin","object":"device:1"},
{"user":"user:charles","relation":"security_guard","object":"device:1"},
{"user":"user:dianne","relation":"it_admin","object":"device:1"}
],
}, {
authorization_model_id: "01HVMMBCMGZNT3SED4Z17ECXCA"
});

Verification

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

Initialize the SDK
// ApiTokenIssuer, ApiAudience, ClientId and ClientSecret are optional.
// import the SDK
const { OpenFgaClient } = require('@openfga/sdk');

// Initialize the SDK with no auth - see "How to setup SDK client" for more options
const fgaClient = new OpenFgaClient({
apiUrl: process.env.FGA_API_URL, // required, e.g. https://api.fga.example
storeId: process.env.FGA_STORE_ID,
authorizationModelId: process.env.FGA_MODEL_ID, // Optional, can be overridden per request
});

// Run a check
const { allowed } = await fgaClient.check({
user: 'user:charles',
relation: 'live_video_viewer',
object: 'device:1',
}, {
authorization_model_id: '01HVMMBCMGZNT3SED4Z17ECXCA',
});

// 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: [user]
define security_guard: [user]

With this change, the full authorization model becomes:

model
schema 1.1

type user

type device
relations
define it_admin: [user, device_group#it_admin]
define security_guard: [user, device_group#security_guard]
define live_video_viewer: [user] or it_admin or security_guard
define recorded_video_viewer: [user] or it_admin or security_guard
define device_renamer: [user] or it_admin

type device_group
relations
define it_admin: [user]
define security_guard: [user]

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
// ApiTokenIssuer, ApiAudience, ClientId and ClientSecret are optional.
// import the SDK
const { OpenFgaClient } = require('@openfga/sdk');

// Initialize the SDK with no auth - see "How to setup SDK client" for more options
const fgaClient = new OpenFgaClient({
apiUrl: process.env.FGA_API_URL, // required, e.g. https://api.fga.example
storeId: process.env.FGA_STORE_ID,
authorizationModelId: process.env.FGA_MODEL_ID, // Optional, can be overridden per request
});

await fgaClient.write({
writes: [
{"user":"user:charles","relation":"security_guard","object":"device_group:group1"},
{"user":"user:dianne","relation":"it_admin","object":"device_group:group1"}
],
}, {
authorization_model_id: "01HVMMBCMGZNT3SED4Z17ECXCA"
});

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
// ApiTokenIssuer, ApiAudience, ClientId and ClientSecret are optional.
// import the SDK
const { OpenFgaClient } = require('@openfga/sdk');

// Initialize the SDK with no auth - see "How to setup SDK client" for more options
const fgaClient = new OpenFgaClient({
apiUrl: process.env.FGA_API_URL, // required, e.g. https://api.fga.example
storeId: process.env.FGA_STORE_ID,
authorizationModelId: process.env.FGA_MODEL_ID, // Optional, can be overridden per request
});

await fgaClient.write({
writes: [
{"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"}
],
}, {
authorization_model_id: "01HVMMBCMGZNT3SED4Z17ECXCA"
});

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
// ApiTokenIssuer, ApiAudience, ClientId and ClientSecret are optional.
// import the SDK
const { OpenFgaClient } = require('@openfga/sdk');

// Initialize the SDK with no auth - see "How to setup SDK client" for more options
const fgaClient = new OpenFgaClient({
apiUrl: process.env.FGA_API_URL, // required, e.g. https://api.fga.example
storeId: process.env.FGA_STORE_ID,
authorizationModelId: process.env.FGA_MODEL_ID, // Optional, can be overridden per request
});

// Run a check
const { allowed } = await fgaClient.check({
user: 'dianne',
relation: 'live_video_viewer',
object: 'device:2',
}, {
authorization_model_id: '01HVMMBCMGZNT3SED4Z17ECXCA',
});

// 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 [user] 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:

model
schema 1.1

type user

type device
relations
define it_admin: [user, device_group#it_admin]
define security_guard: [user, device_group#security_guard]
define live_video_viewer: it_admin or security_guard
define recorded_video_viewer: it_admin or security_guard
define device_renamer: it_admin

type device_group
relations
define it_admin: [user]
define security_guard: [user]
info

Notice that any reference to the direct relationship type restrictions 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
// ApiTokenIssuer, ApiAudience, ClientId and ClientSecret are optional.
// import the SDK
const { OpenFgaClient } = require('@openfga/sdk');

// Initialize the SDK with no auth - see "How to setup SDK client" for more options
const fgaClient = new OpenFgaClient({
apiUrl: process.env.FGA_API_URL, // required, e.g. https://api.fga.example
storeId: process.env.FGA_STORE_ID,
authorizationModelId: process.env.FGA_MODEL_ID, // Optional, can be overridden per request
});

await fgaClient.write({
writes: [
{"user":"user:emily","relation":"live_video_viewer","object":"device:1"},
{"user":"user:emily","relation":"recorded_video_viewer","object":"device:1"},
{"user":"user:emily","relation":"device_renamer","object":"device:1"}
],
}, {
authorization_model_id: "01HVMMBCMGZNT3SED4Z17ECXCA"
});

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 type restriction was removed from the relation configuration.

Initialize the SDK
// ApiTokenIssuer, ApiAudience, ClientId and ClientSecret are optional.
// import the SDK
const { OpenFgaClient } = require('@openfga/sdk');

// Initialize the SDK with no auth - see "How to setup SDK client" for more options
const fgaClient = new OpenFgaClient({
apiUrl: process.env.FGA_API_URL, // required, e.g. https://api.fga.example
storeId: process.env.FGA_STORE_ID,
authorizationModelId: process.env.FGA_MODEL_ID, // Optional, can be overridden per request
});

// Run a check
const { allowed } = await fgaClient.check({
user: 'user:emily',
relation: 'live_video_viewer',
object: 'device:1',
}, {
authorization_model_id: '01HVMMBCMGZNT3SED4Z17ECXCA',
});

// 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 OpenFGA.

Upcoming posts will dive deeper into OpenFGA, 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.

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?