Skip to main content

Managing Relationships Between Objects

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 give a user access to a particular object through a relationship with another object.

When to use

Giving user access through a relationship with another object is helpful because it allows scaling as the number of object grows. For example:

  • organization that owns many repos
  • team that administers many documents

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 followingauthorization model

  • a repo type that can have a admin relation
type repo
relations
define admin 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 Auth0 FGA

Step by Step

For the current model, a user can be related as an admin to an object of type repo. If we wanted to have Anne be related to two repos, repo:1 and repo:2, we would have to add two relationship tuples, like so:

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: 'admin', object: 'repo:1'},
{ user: 'anne', relation: 'admin', object: 'repo:2'}
]
}
});

In general, every time we wanted to add a new admin relationship to a repo we'd have to add a new tuple. This doesn't scale as the list of repos and users grows.

01. Modify authorization model

Another way of modeling this is to have an authorization model as follows:

type repo
relations
define admin as self or repo_admin from owner
define owner as self
type org
relations
define repo_admin as self

In this model, we have:

  • added a new type org with one relation repo_admin.
  • added a new relation owner for type repo.
  • re-defined the relation admin for repo. A user can be defined as an admin directly, as we have seen above, or through the repo_admin from owner clause. How this works, for example, is that if user is related as repo_admin to org:xyz, and org:xyz is related as owner to repo:1, then user is an admin of repo:1.

02. Adding relationship tuples where user is another object

With this model, we can add tuples representing that an org is the owner of a repo. By adding following relationship tuples, we are indicating that the xyz organization is the owner of repositories with IDs 1 and 2:

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: 'org:xyz', relation: 'owner', object: 'repo:1'},
{ user: 'org:xyz', relation: 'owner', object: 'repo:2'}
]
}
});

03. Adding relationship tuples to the other object

Now, imagine we have a new user Becky. If we wanted to have Becky be the admin of all repos without having to add one tuple per repo, all we need to do is add one tuple that says that Becky is related as repo_admin to org:xyz.

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: 'becky', relation: 'repo_admin', object: 'org:xyz'}
]
}
});

04. Validating user access

We can now verify that Becky an admin of all the repos owned by org:xyz:

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: 'becky',
relation: 'admin',
object: 'repo:1',
},});

// 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: 'becky',
relation: 'admin',
object: 'repo:2',
},});

// allowed = true

05. Revoking access

Suppose now that we want to prevent users from being an admin of repo:1 via org:xyz. We can delete one tuple:

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({
deletes: {
tuple_keys : [
{ user: 'org:xyz', relation: 'owner', object: 'repo:1'}
]
}
});

With this change, we may now verify that Becky is no longer an admin of repo: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: 'becky',
relation: 'admin',
object: 'repo:1',
},});

// allowed = false
Modeling Parent-Child Objects

Learn about how to cascade relationships from parent object to child object.

Modeling Object to Object Relationships

Learn about modeling patterns on objects that are not specifically tied to a user.

Modeling GitHub

An example of object to object relationships.

Have Feedback?

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