Skip to main content
This section tackles cases where a user may have access to a particular resource through their presence in a particular organization, and they should have that access only when logged in within the context of that organization.

​
Before You Start

To follow this guide, you should be familiar with some Auth0 FGA Concepts.

​
Auth0 FGA Concepts

  • A Relation: is a string defined in the type definition of an authorization model that defines the possibility of a relationship between an object of the same type as the type definition and a user in the system
  • A Check Request: is a call to the Auth0 FGA check endpoint that returns whether the user has a certain relationship with an object.
  • A Relationship Tuple: a grouping consisting of a user, a relation and an object stored in Auth0 FGA
  • A Contextual Tuple: a tuple that can be added to a check request, and only exist within the context of that particular request.
You also need to be familiar with:
  • 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 →
  • Modeling Multiple Restrictions: You need to know how to model requiring multiple authorizations before allowing users to perform certain actions. Learn more →

​
Scenario

For the scope of this guide, we are going to consider the following scenario. Consider you are building the authorization model for a multi-tenant project management system. In this particular system:
  • projects are owned and managed by companies
  • users can be members of multiple companies
  • project access is governed by the user’s role in the organization that manages the project
In order for a user to access a project:
  • The project needs to be managed by an organization the user is a member of
  • A project is owned by a single organization
  • A project can be shared with partner companies (that are able to view, edit but not perform admin actions, such as deletion, on the project)
  • The user should have a role that grants access to the project
  • The user should be logged in within the context of that organization
We will start with the following authorization model:

​
Requirements

  • When logging in within the context of organization A, Anne should be able to view and delete project X.
  • When logging in within the context of organization B, Anne should be able to view, but not delete, project X.
  • When logging in within the context of organization C, Anne should not be able to view nor delete project X.
  • When logging in within the context of organization B, Beth should be able to view, but not delete, project X.
  • Carl should not be able to view nor delete project X.

​
Step By Step

In order to solve for the requirements above, we will break the problem down into three steps:
  1. Understand relationships without contextual tuples. For example, we need to ensure that Anne can view and delete “Project X”.
  2. Take organization context into consideration. This includes extending the authorization model and a temporary step of adding the required tuples to mark that Anne is in an approved context.
  3. Use contextual tuples for context related checks.

​
Understand Relationships Without Contextual Data

With the authorization model and relationship tuples shown above, Auth0 FGA has all the information needed to ensure that Anne can view and delete “Project X”. We can verify that using the following checks:
  • Anne can view Project X
  • Anne can delete Project X
Note that so far, we have not prevented Anne from viewing “Project X” even if Anne is viewing it from the context of Organization C.

​
Take Organization Context Into Consideration

Extend The Authorization Model
In order to add a restriction based on the current organization context, we will make use of Auth0 FGA configuration language’s support for intersection to specify that a user has to both have access and be in the correct context in order to be authorized. We can do that by introducing some new relations and updating existing relation definitions:
  1. On the “organization” type
  • Add “user_in_context” relation to mark that a user’s access is being evaluated within that particular context
  • Update the “project_manager” relation to require that the user be in the correct context (by adding and user_in_context to the relation definition)
  • Considering that Auth0 FGA does not yet support multiple logical operations within the same definition, we will split “project_editor” into two:
    • “base_project_editor” editor which will contain the original relation definition ([user] or project_manager)
    • “project_editor” which will require that a user has both the “base_project_editor” and the “user_in_context” relations
The “organization” type definition then becomes:
  1. On the “project” type
  • Nothing will need to be done, as it will inherit the updated “project_manager” and “project_editor” relation definitions from “organization”
Add The Required Tuples To Mark That Anne Is In An Approved Context
Now that we have updated our authorization model to take the current user’s organization context into consideration, you will notice that Anne has lost access because nothing indicates that Anne is authorizing from the context of an organization. You can verify that by issuing the following check: In order for Anne to be authorized, a tuple indicating Anne’s current organization context will need to be present: We can verify this by running a check request Now that we know we can authorize based on present state, we have a different problem to solve. We are storing the tuples in the state in order for Auth0 FGA to evaluate them, which fails in certain use-cases where Anne can be connected to two different contexts in different browser windows at the same time, as each has a different context at the same time, so if they are written to the state, which will Auth0 FGA use to compute Anne’s access to the project? For Check calls, Auth0 FGA has a concept called “Contextual Tuples”. Contextual Tuples are tuples that do not exist in the system state and are not written beforehand to Auth0 FGA. They are tuples that are sent alongside the Check request and will be treated as if they already exist in the state for the context of that particular Check call. That means that Anne can be using two different sessions, each within a different organization context, and Auth0 FGA will correctly respond to each one with the correct authorization decision. First, we will undo the temporary step and remove the stored tuples for which Anne has a user_in_context relation with organization:A. Next, when Anne is connecting from the context of organization A, Auth0 FGA will return {"allowed":true}: When Anne is connecting from the context of organization C, Auth0 FGA will return {"allowed":false}: Using this, you can check that the following requirements are satisfied:

​
Summary

WarningContextual tuples:
Check the following sections for more on how user groups can be used.