> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fga.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Authorization Through Organization Context
> Modeling authorization through organization context
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.
**When to use**
Contextual Tuples should be used when modeling cases where a user's access to an object depends on the context of their request. For example:
* An employee’s ability to access a document when they are connected to the organization VPN or the api call is originating from an internal IP address.
* A support engineer is only able to access a user's account during office hours.
* If a user belongs to multiple organizations, they are only able to access a resource if they set a specific organization in their current context.
## Before You Start
To follow this guide, you should be familiar with some [Auth0 FGA Concepts](/fga-concepts.md).
### Auth0 FGA Concepts
* A [Relation](/fga-concepts.md#what-is-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](/fga-concepts.md#what-is-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](/fga-concepts.md#what-is-a-relationship-tuple): a grouping consisting of a user, a relation and an object stored in Auth0 FGA
* A [Contextual Tuple](/fga-concepts.md#what-are-contextual-tuples): 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/concepts/object-to-object-relationships.md)
* **Modeling Multiple Restrictions**: You need to know how to model requiring multiple authorizations before allowing users to perform certain actions. [Learn more →](/modeling/basics/multiple-restrictions.md)
[The Playground
Try this guide out on the Auth0 FGA Playground](https://play.fga.dev/)
### 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:
We are considering the case that:
* Anne has a project manager role at organizations A, B and C
* Beth has a project manager role at organization B
* Carl has a project manager role at organization C
* Project X is owned by organization A
* Project X is shared with organization B
The above state translates to the following relationship tuples:
### 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](#understand-relationships-without-contextual-data). For example, we need to ensure that Anne can view and delete "Project X".
2. [Take organization context into consideration](#take-organization-context-into-consideration). This includes [extending the authorization model](#extend-the-authorization-model) and a temporary step of [adding the required tuples to mark that Anne is in an approved context](#add-the-required-tuples-to-mark-that-anne-is-in-an-approved-context).
3. [Use contextual tuples for context related checks](#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
More checks
* Beth can view Project X
- Beth cannot delete Project X
* Carl cannot view Project X
- Carl cannot 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](/modeling/configuration-language.md#the-intersection-operator) 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:
2. 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
### Use Contextual Tuples For Context Related Checks
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](/fga-concepts.md#what-are-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](#add-the-required-tuples-to-mark-that-anne-is-in-an-approved-context) 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:
| User | Organization Context | Action | Allowed |
| - | - | - | - |
| Anne | Organization A | View | Yes |
| Anne | Organization B | View | Yes |
| Anne | Organization C | View | No |
| Anne | Organization A | Delete | Yes |
| Anne | Organization B | Delete | No |
| Anne | Organization C | Delete | No |
| Beth | Organization B | View | Yes |
| Beth | Organization B | Delete | No |
| Carl | Organization C | View | No |
| Carl | Organization C | Delete | No |
## Summary
Final version of the Authorization Model and Relationship tuples