Modeling Authorization for an IoT Security System with OpenFGA

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

​

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. It would be helpful to have an understanding of some concepts of OpenFGA before you start.

OpenFGA concepts

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

• Some OpenFGA 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

​

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:

​

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: To add Anne as recorded_video_viewer of device:1 Likewise, we will add Beth’s relationship with 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. On the other hand, Anne does not have device_renamer relationship with device:1. Now, check the other relationships fore Anne and Beth.

​

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

​

Verification

We can now verify whether charles is related to device:1 as live_video_viewer. Check the other relationships for anne, beth, charles and dianne.

​

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: With this change, the full authorization model becomes:

​

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

​

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? Type any of the following queries in the TUPLE QUERIES section and press ENTER on your keyboard to see the results.

​

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:

​

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: 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. Query on the other relationships and you will see:

​

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?