Skip to main content

Modeling Google Drive permissions with OpenFGA

This tutorial explains how to represent Google Drive permissions model with OpenFGA.

What you will learn
  • Indicate relationships between a group of users and an object. See Modeling User Groups for more.
    Used here to indicate that all users within a domain can access a document (sharing a document within an organization).
  • Model concentric relationship to have a certain relation on an object imply another relation on the same object. See Modeling Concepts: Concentric Relationships for more.
    Used here is to indicate that writers are also commenters and viewers.
  • Using the union operator condition to indicate that a user might have a certain relation with an object if they match any of the criteria indicated.
    Used here to indicate that a user can be a viewer on a document, or can have the viewer relationship implied through commenter.
  • Using the type bound public access in a relationship tuple's user field to indicate that everyone has a certain relation with an object. See Modeling Public Access for more.
    Used here to share documents publicly.
  • Model parent-child objects to indicate that a user having a relationship with a certain object implies having a relationship with another object in OpenFGA.
    Used here is to indicate that a writer on a folder is a writer on all documents inside that folder.

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.

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 →

Modeling Object-to-Object Relationships

You need to know how to create relationships between objects and how that might affect a user's relationships to those objects. Learn more →

Used here to indicate that users who have access to view a folder have access to view all documents inside it.

Modeling Public Access

You need to know how to add a relationship tuple to indicate that a resource is publicly available. Learn more →

Concepts & Configuration Language

What You Will Be Modeling

Google Drive is a system to store, share, and collaborate on files and folders. Source

In this tutorial, you will build a subset of the Google Drive permission model (detailed below) in OpenFGA, using some scenarios to validate the model.

Note: For brevity, this tutorial will not model all of Google Drive's permissions. Instead, it will focus on modeling for the scenarios outlined below

Requirements

Google Drive's permission model is represented in their documentation.

In this tutorial, you will be focusing on a subset of these permissions.

Requirements:

  • Users can be owners, editors, commenters and viewers of documents
  • Documents can be shared with all users in a domain
  • Folders can contain documents and users with a certain permission on a folder have that same permission to a document in that folder
  • Documents and folders can be shared publicly

Defined Scenarios

There will be the following users:

  • Anne, who is in the xyz domain
  • Beth, who is in the xyz domain
  • Charles, who is in the xyz domain
  • Diane, who is NOT in the xyz domain
  • Erik, who is NOT in the xyz domain

There will be:

  • a 2021-budget document, owned by Anne, shared for commenting with Beth and viewable by all members of the xyz domain.
  • a 2021-planning folder, viewable by Diane and contains the 2021-budget document
  • a 2021-public-roadmap document, owned by Anne, available for members xyz domain to comment on and is publicly viewable

Modeling Google Drive's Permissions

01. Individual Permissions

To keep thing simple and focus on OpenFGA features rather than Google Drive complexity we will model only four roles (Viewer, Commenter, Writer, Owner).

At the end of this section we want to have the following permissions represented:

Image showing permissions

To represent permissions in OpenFGA we use relations. For document permissions we need to create the following authorization model:

model
schema 1.1

type user

type document
relations
define owner: [user]
define writer: [user]
define commenter: [user]
define viewer: [user]

The OpenFGA service determines if a user has access to an object by checking if the user has a relation to that object. Let us examine one of those relations in detail:


type document
relations
define viewer: [user]
info

The snippet above indicates that objects of type document have users related to them as "viewer" if those users belong to the userset of all users related to the document as "viewer".

This means that a user can be directly related as a viewer to an object of type "document"

If we want to say beth is a commenter of document:2021-budget we create this relationship tuple:

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":"commenter","object":"document:2021-budget"}
],
}, {
authorization_model_id: "01HVMMBCMGZNT3SED4Z17ECXCA"
});

We can now ask OpenFGA "is beth a commenter of repository document:2021-budget?"

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:beth',
relation: 'commenter',
object: 'document:2021-budget',
}, {
authorization_model_id: '01HVMMBCMGZNT3SED4Z17ECXCA',
});

// allowed = true

We could also say that anne is an owner of the same document:

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":"owner","object":"document:2021-budget"}
],
}, {
authorization_model_id: "01HVMMBCMGZNT3SED4Z17ECXCA"
});

And ask some questions to OpenFGA:

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: 'owner',
object: 'document:2021-budget',
}, {
authorization_model_id: '01HVMMBCMGZNT3SED4Z17ECXCA',
});

// allowed = true
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: 'writer',
object: 'document:2021-budget',
}, {
authorization_model_id: '01HVMMBCMGZNT3SED4Z17ECXCA',
});

// allowed = false

The first reply makes sense but the second one does not. Intuitively, if anne was an owner, she was also be a writer. In fact, Google Drive explains this in their documentation

Image showing roles

To make OpenFGA aware of this "concentric" permission model we need to update our definitions:

model
schema 1.1

type user

type document
relations
define owner: [user]
define writer: [user] or owner
define commenter: [user] or writer
define viewer: [user] or commenter
info

Let's examine one of those relations in detail:

objects of type document have users related to them as "viewer": if they belong to any of (the union of) the following:

  • the userset of all users related to the document as "viewer"
  • the userset of all users related to the document as "commenter"

With this update our model now supports nested definitions and now:

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: 'owner',
object: 'document:2021-budget',
}, {
authorization_model_id: '01HVMMBCMGZNT3SED4Z17ECXCA',
});

// allowed = true
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: 'writer',
object: 'document:2021-budget',
}, {
authorization_model_id: '01HVMMBCMGZNT3SED4Z17ECXCA',
});

// allowed = true

02. Organization Permissions

Google Drive allows you to share a file with everyone in your organization as a viewer, commenter or writer/editor.

At the end of this section we want to end up with the following permissions represented:

Image showing permissions

To add support for domains and members all we need to do is add this object to the OpenFGA authorization model. In addition, update the model to allow domain member to be assigned to document:

model
schema 1.1

type user

type document
relations
define owner: [user, domain#member]
define writer: [user, domain#member] or owner
define commenter: [user, domain#member] or writer
define viewer: [user, domain#member] or commenter

type domain
relations
define member: [user]
info

Objects of type "domain" have users related to them as "member" if they belong to the userset of all users related to the domain as "member".

In other words, users can be direct members of a domain.

Let's now create a domain, add members to it and make all members viewers of document:2021-budget.

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: [
// make anne, beth, charles a member of the xyz domain
{"_description":"make anne, beth, charles a member of the xyz domain","user":"user:anne","relation":"member","object":"domain:xyz"},
{"user":"user:beth","relation":"member","object":"domain:xyz"},
{"user":"user:charles","relation":"member","object":"domain:xyz"},
// make members of xyz domain viewers of document:2021-budget
{"_description":"make members of xyz domain viewers of document:2021-budget","user":"domain:xyz#member","relation":"viewer","object":"document:2021-budget"}
],
}, {
authorization_model_id: "01HVMMBCMGZNT3SED4Z17ECXCA"
});

The last relationship tuple introduces a new OpenFGA concept. A userset. When the value of a user is formatted like this objectType:objectId#relation, OpenFGA will automatically expand the userset into all its individual user identifiers:

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: 'viewer',
object: 'document:2021-budget',
}, {
authorization_model_id: '01HVMMBCMGZNT3SED4Z17ECXCA',
});

// allowed = true

03. Folder Permission Propagation

Permission propagation happens between folders and files: if you are a viewer in a folder, you can view its documents. This applies even when you are not explicitly a viewer in a document. Image

At the end of this section we want to end up with the following permissions represented. Note that a folder is an object in the document type, as we do not need a separate type:

Image showing permissions

We need to add the notion that a document can be the parent of another document. We know how to do that:

model
schema 1.1

type user

type document
relations
define parent: [document]
define owner: [user, domain#member]
define writer: [user, domain#member] or owner
define commenter: [user, domain#member] or writer
define viewer: [user, domain#member] or commenter
info

Notice the newly added "parent" relation in the configuration above.

We can indicate this relation 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: [
// Diane is a viewer of document:2021-planning
{"_description":"Diane is a viewer of document:2021-planning","user":"user:diane","relation":"viewer","object":"document:2021-planning"},
// document:2021-planning is a parent of document:2021-budget
{"_description":"document:2021-planning is a parent of document:2021-budget","user":"document:2021-planning","relation":"parent","object":"document:2021-budget"}
],
}, {
authorization_model_id: "01HVMMBCMGZNT3SED4Z17ECXCA"
});