sidebar_position	slug	description
8	/modeling/contextual-time-based-authorization	Checking relations that depends on certain dynamic or contextual data (such as time, location, ip address, weather) that have not been written

import { AuthzModelSnippetViewer, CardBox, CheckRequestViewer, DocumentationNotice, Playground, ProductConcept, ProductName, ProductNameFormat, RelatedSection, RelationshipTuplesViewer, UpdateProductNameInLinks, WriteRequestViewer, } from '@components/Docs';

Contextual and Time-Based Authorization

This section explores some methods available to you to tackle some use-cases where the expected authorization check may depend on certain dynamic or contextual data (such as time, location, ip address, weather) that have not been written to the store.

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

Concepts

A : 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 : is a call to the check endpoint that returns whether the user has a certain relationship with an object.
A : a grouping consisting of a user, a relation and an object stored in
A : a tuple that can be added to a Check request, and only exists 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 WeBank Inc.

In order for an Account Manager at WeBank Inc. to be able to access a customer's account and its transactions, they would need to be:

An account manager at the same branch as the customer's account
Connected via the branch's internal network or through the branch's VPN
Connected during this particular branch's office hours

We will start with the following Authorization Model

We are considering the case that:

Anne is the Account Manager at the West-Side branch
Caroline is the customer for checking account number 526
The West-Side branch is the branch that the checking account number 526 has been created at
Checking account number 526 has a transaction, we'll call it transaction A
The West-Side branch’s office hours is from 8am-3pm UTC

The above state translates to the following relationship tuples:

Requirements

By the end of this guide we would like to validate that:

If Anne is at the branch, and it is 12pm UTC, Anne should be able to view transaction A
If Anne is connecting remotely at 12pm UTC but is not connected to the VPN, Anne should not be able to view transaction A
If Anne is connecting remotely and is connected to the VPN
- at 12pm UTC, should be able to view transaction A
- at 6pm UTC, should not be able to view transaction A

Step By Step

In order to solve for the requirements above, we will break the problem down to three steps:

Understand relationships without contextual tuples. We will want to ensure that

the customer can view a transaction tied to their account
the account manager can view a transaction whose account is at the same branch

Extend the Authorization Model to take time and ip address into consideration
Use contextual tuples for context related checks.

Understand Relationships Without Contextual Data

With the Authorization Model and relationship tuples shown above, has all the information needed to

Ensure that the customer can view a transaction tied to their account
Ensure that the account manager can view a transaction whose account is at the same branch

We can verify that using the following checks

Anne can view transaction:A because she is an account manager of an account that is at the same branch.

Caroline can view transaction:A because she is a customer and the transaction is tied to her account.

Additionally, we will check that Mary, an account manager at a different branch cannot view transaction A.

Note that so far, we have not prevented Anne from viewing the transaction outside office hours, let's see if we can do better.

Take Time And IP Address Into Consideration

Extend The Authorization Model

In order to add time and ip address to our authorization model, we will add appropriate types for them. We will have a "timeslot" and an "ip-address-range" as types, and each can have users related to it as a user.

We'll also need to introduce some new relations, and modify some others.

On the "branch" type:

Add "approved_timeslot" relation to mark than a certain timeslot is approved to view transactions for accounts in this branch
Add "approved_ip_address_range" relation to mark than an ip address range is approved to view transactions for accounts in this branch
Add "approved_context" relation to combine the two authorizations above (user from approved_timeslot and user from approved_ip_address_range), and indicate that the user is in an approved context

The branch type definition then becomes:

On the "account" type:

Add "account_manager_viewer" relation to combine the "account_manager" relationship and the new "approved_context" relation from the branch
Update the "viewer" relation definition to customer or account_manager_viewer where "customer" can view without being subjected to contextual authorization, while "account_manager_viewer" needs to be within the branch allowed context to view

The account type definition then becomes:

:::note On the "transaction" type:

Nothing will need to be done, as it will inherit the updated "viewer" relation definition from "account"

:::

Add The Required Tuples To Mark That Anne Is In An Approved Context

Now that we have updated our authorization model to take time and ip address into consideration, you will notice that Anne has lost access because nothing indicates that Anne is connecting from an approved ip address and time. You can verify that by issuing the following check:

We need to add relationship tuples to mark some approved timeslots and ip address ranges:

:::note

Here we added the time slots in increments of 1 hour periods, but this is not a requirement.
We did not add all the office hours to keep this guide shorter.

:::

Now that we have added the allowed timeslots and ip address ranges we need to add the following relationship tuples to give Anne access.

If we have the above two tuples in the system, when checking whether Anne can view transaction A we should get a response stating that Anne can view it.

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 to evaluate them, which means that:

For the case of the IP Address, we are not able to truly authorize based on the context of the request. E.g. if Anne was trying to connect from the phone and from the PC at the same time, and only the PC was connected to the VPN, how would know to deny one and allow the other if the data is stored in the state?
On every check call we have to first write the correct tuples, then call the Check api, then clean up those tuples. This causes a substantial increase in latency as well as incorrect answers for requests happening in parallel (they could write/delete each other's tuples).

How do we solve this? How do we tie the above two tuples to the context of the request instead of the system state?

First, we will need to undo adding the stored relationship tuples where Anne is connecting from within the 10.0.0.0/16 ip address range and Anne connecting between 12pm and 1pm

For Check calls, has a concept called "". Contextual Tuples are tuples that do not exist in the system state and are not written beforehand to . 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.

When Anne is connecting from an allowed ip address range and timeslot, will return {"allowed":true}:

When Anne is connecting from a denied ip address range or timeslot, will return {"allowed":false}:

Summary

Final version of the Authorization Model and Relationship tuples

:::caution Warning Contextual tuples:

Are not persisted in the store.
Are only supported on the and . They are not supported on read, expand and other endpoints.- If you are using the ReadChanges API endpoint to build a permission aware search index, note that it will not be trivial to take contextual tuples into account.
If you are using the to build a permission aware search index, note that it will not be trivial to take contextual tuples into account.

:::

Taking It A Step Further: Banks As A Service Authorization

In order to keep this guide concise, we assumed you were modeling for a single bank. What if you were offering a multi-tenant service where each bank is a single tenant?

In that case, we can extend the model like so:

Related Sections

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

contextual-time-based-authorization.mdx

contextual-time-based-authorization.mdx

Contextual and Time-Based Authorization

Before You Start

Concepts

Scenario

Requirements

Step By Step

Understand Relationships Without Contextual Data

Take Time And IP Address Into Consideration

Extend The Authorization Model

Add The Required Tuples To Mark That Anne Is In An Approved Context

Use Contextual Tuples For Context Related Checks

Summary

Taking It A Step Further: Banks As A Service Authorization

Related Sections

Files

contextual-time-based-authorization.mdx

Latest commit

History

contextual-time-based-authorization.mdx

File metadata and controls

Contextual and Time-Based Authorization

Before You Start

Concepts

Scenario

Requirements

Step By Step

Understand Relationships Without Contextual Data

Take Time And IP Address Into Consideration

Extend The Authorization Model

Add The Required Tuples To Mark That Anne Is In An Approved Context

Use Contextual Tuples For Context Related Checks

Summary

Taking It A Step Further: Banks As A Service Authorization

Related Sections