Skip to main content

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 OpenFGA store.

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 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 OpenFGA Concepts.

OpenFGA concepts​

  • A Relation: Defined in the type definition of an authorization model, a relation is a string 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 OpenFGA 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 OpenFGA
  • A Contextual Tuple: 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

model
  schema 1.1

type user

type branch
  relations
    define account_manager: [user]

type account
  relations
    define branch: [branch]
    define account_manager: account_manager from branch
    define customer: [user]
    define viewer: customer or account_manager
    define can_view: viewer

type transaction
  relations
    define account: [account]
    define can_view: viewer from account

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:

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: [
      // Anne is the Account Manager at the West-Side branch
      {"_description":"Anne is the Account Manager at the West-Side branch","user":"user:anne","relation":"account_manager","object":"branch:west-side"},
      // Caroline is the customer for checking account number 526
      {"_description":"Caroline is the customer for checking account number 526","user":"user:caroline","relation":"customer","object":"account:checking-526"},
      // The West-Side branch is the branch that the Checking account number 526 has been created at
      {"_description":"The West-Side branch is the branch that the Checking account number 526 has been created at","user":"branch:west-side","relation":"branch","object":"account:checking-526"},
      // Checking account number 526 is the account for transaction A
      {"_description":"Checking account number 526 is the account for transaction A","user":"account:checking-526","relation":"account","object":"transaction:A"}
  ],
}, {
  authorization_model_id: "01HVMMBCMGZNT3SED4Z17ECXCA" 
});

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:

  1. 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
  1. Extend the Authorization Model to take time and ip address into consideration
  2. Use contextual tuples for context related checks.

Understand relationships without contextual data​

With the Authorization Model and relationship tuples shown above, OpenFGA 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.

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: 'can_view',
    object: 'transaction:A',
  }, {
  authorization_model_id: '01HVMMBCMGZNT3SED4Z17ECXCA',
});

// allowed = true

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

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:caroline',
    relation: 'can_view',
    object: 'transaction:A',
  }, {
  authorization_model_id: '01HVMMBCMGZNT3SED4Z17ECXCA',
});

// allowed = true

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

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: [
      // Mary is an account manager at the East-Side branch
      {"_description":"Mary is an account manager at the East-Side branch","user":"user:mary","relation":"account_manager","object":"branch:east-side"}
  ],
}, {
  authorization_model_id: "01HVMMBCMGZNT3SED4Z17ECXCA" 
});
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:mary',
    relation: 'can_view',
    object: 'transaction:A',
  }, {
  authorization_model_id: '01HVMMBCMGZNT3SED4Z17ECXCA',
});

// allowed = false

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.


type timeslot
  relations
    define user: [user]

type ip-address-range
  relations
    define user: [user]

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

  1. 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:


type branch
  relations
    define account_manager: [user]
    define approved_ip_address_range: [ip-address-range]
    define approved_timeslot: [timeslot]
    define approved_context: user from approved_timeslot and user from approved_ip_address_range
  1. 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:


type account
  relations
    define branch: [branch]
    define account_manager: account_manager from branch
    define customer: [user]
    define account_manager_viewer: account_manager and approved_context from branch
    define viewer: customer or account_manager_viewer
    define can_view: viewer
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:

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: 'can_view',
    object: 'transaction:A',
  }, {
  authorization_model_id: '01HVMMBCMGZNT3SED4Z17ECXCA',
});

// allowed = false

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.
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: [
      // 11am to 12pm is within the office hours of the West-Side branch
      {"_description":"11am to 12pm is within the office hours of the West-Side branch","user":"timeslot:11_12","relation":"approved_timeslot","object":"branch:west-side"},
      // 12pm to 1pm is within the office hours of the West-Side branch
      {"_description":"12pm to 1pm is within the office hours of the West-Side branch","user":"timeslot:12_13","relation":"approved_timeslot","object":"branch:west-side"},
      // The office VPN w/ the 10.0.0.0/16 address range is approved for the West-Side branch
      {"_description":"The office VPN w/ the 10.0.0.0/16 address range is approved for the West-Side branch","user":"ip-address-range:10.0.0.0/16","relation":"approved_ip_address_range","object":"branch:west-side"}
  ],
}, {
  authorization_model_id: "01HVMMBCMGZNT3SED4Z17ECXCA" 
});

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

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: [
      // Anne is connecting from within the 10.0.0.0/16 ip address range
      {"_description":"Anne is connecting from within the 10.0.0.0/16 ip address range","user":"user:anne","relation":"user","object":"ip-address-range:10.0.0.0/16"},
      // Anne is connecting between 12pm and 1pm
      {"_description":"Anne is connecting between 12pm and 1pm","user":"user:anne","relation":"user","object":"timeslot:12_13"}
  ],
}, {
  authorization_model_id: "01HVMMBCMGZNT3SED4Z17ECXCA" 
});

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.

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: 'can_view',
    object: 'transaction:A',
  }, {
  authorization_model_id: '01HVMMBCMGZNT3SED4Z17ECXCA',
});

// allowed = true