How to design model for resource specific access and also allowing access to all the resources?

[prsanjay]

Hi Everyone,

I have a multi-tenant app where we first create the account and then add users to it. We also create the groups and roles under the account. The same user can be present in multiple accounts, but groups and roles are owned by a specific account and can not be shared across accounts.

Currently we are having authorization mechanism where users can create their custom roles by selecting the fine-grained permissions. Here role is a collection or container of the related permissions. If I take the example of a resource fund, then fund.create, fund.read, fund.update, fund.delete are the permissions, and users can create custom roles by selecting those permissions. The user can only assign those roles to the group and not to the users. When user logs in and try to create the fund, we check if the user is present in the group which has the role that contains fund.create permission, and if so, then only allow to create the fund. If user creates a custom role called Fund Manager and select all the above permissions and assign that role to say Group Fund Manager within that account then all the users present in that group for that account would be able to create the funds, update all the funds present in the account, read all the funds and delete all the funds present in the account. But along with this we also have a scenario where lets say we have a resource called questionnaires, and questionnaires are having a sections. Now, here we want to make sure only Group-1 can have section.read and section.write permission on section-1 and group-2 has access of section-2. Right now, we store section_id, group_id and role_id mapping to the database for this and then checking the access resource specific checks.

We also have a concept of modules where we assign the modules to the accounts and when we add users to the account we select which module access the user should have and when the user tries to access the module first we check if the user really have access of that module and if so then we perform other regular authorization checks.

Now, we want to use OpenFGA to remove the manual checks we are doing, and I designed the model as below. I have 2 questions

1. Is the model below designed correctly? I am completely new to OpenFGA
2. Can I check module access for the user and regular authorization check in a single request? If so, how? I am not able to come up with model design for that.

model
  schema 1.1

type user

type account
  relations
    define belongs_to: [user]

type group
  relations
    define member: [user]

type role
  relations
    define assigned: [group#member]

type section
  relations
    define section_delete: [role#assigned]
    define section_edit: [role#assigned]
    define section_read: [role#assigned] or section_edit
    define section_update: [role#assigned]

type fund
  relations
    define fund_create: [role#assigned]
    define fund_delete: [role#assigned]
    define fund_update: [role#assigned]

type module
  relations
    define subscribed_to: [account] # anything else should go here?

Your help will be greatly appreciated. Many Thanks

[aaguiarz]

Hi @prsanjay

The model looks good! Regarding module, is there a way you can relate it to other types? E.g. does a section/fund belong to a module?

[prsanjay]

Hi @aaguiarz, Thanks for the prompt reply. And yes, all the resources, like section/fund belongs to specific module.

[aaguiarz]

Would something like this work?

type module
  relations
    define subscribed_to: [account] 

type section
  relations
    define module : [module]
    define section_delete: [role#assigned] and subscribed_to from module
    define section_edit: [role#assigned]  and subscribed_to from module
    define section_read: [role#assigned] or section_edit  and subscribed_to from module
    define section_update: [role#assigned]  and subscribed_to from module

type fund
  relations
    define module : [module]
    define fund_create: [role#assigned]  and subscribed_to from module
    define fund_delete: [role#assigned]  and subscribed_to from module
    define fund_update: [role#assigned]  and subscribed_to from module

[prsanjay]

Hi @aaguiarz Thanks again. In my case the whole scenario for module access is as below.

1. The Account-A is created and assigned say module-A and module-B
2. The Account-B is created and assigned say Module-A and Module-C
3. User John is added to Account-A and given the access of only module-B
4. Same User John is added to Account-B and given the access of only module-C

When John logs in-to the Account-B and tries to access Module-A -- the request should be denied as John#Account-B does not have Module-A access.

How to model this?

[aaguiarz]

You'd need to resort to a contextual tuple to express the fact that a user is logged in on a specific account.

You can run the file below with the CLI, that demos the scenario you describe. Let me know if that makes sense.

model: |
  model 
     schema 1.1

    type user

    type account
      relations
        define belongs_to: [user]
        define user_in_context : [user] and belongs_to

    type module
      relations
        define subscribed_to: [account] 
        define has_access: [user] and user_in_context from subscribed_to

tuples:

# The Account-A is created and assigned say module-A and module-B
- user: account:A
  relation: subscribed_to
  object: module:A

- user: account:A
  relation: subscribed_to
  object: module:B

# The Account-B is created and assigned say Module-A and Module-C
- user: account:B
  relation: subscribed_to
  object: module:A

- user: account:B
  relation: subscribed_to
  object: module:C

# User John is added to Account-A and given the access of only module-B
- user: user:john
  relation: belongs_to
  object: account:A

- user: user:john
  relation: has_access
  object: module:B

# Same User John is added to Account-B and given the access of only module-C
- user: user:john
  relation: belongs_to
  object: account:B

- user: user:john
  relation: has_access
  object: module:C


tests:
    - name: When user John is logged in to account A should access only module B
      tuples:
        # This tuple is sent as a contextual tuple
        - user: user:john
          relation: user_in_context
          object: account:A
      check:
        - user: user:john
          object: module:A
          assertions:
            has_access: false

        - user: user:john
          object: module:B
          assertions:
            has_access: true            

        - user: user:john
          object: module:C
          assertions:
            has_access: false                  

    - name: When user John is logged in to account B should access only module C
      tuples:
        # This tuple is sent as a contextual tuple
        - user: user:john
          relation: user_in_context
          object: account:B
      check:
        - user: user:john
          object: module:A
          assertions:
            has_access: false

        - user: user:john
          object: module:B
          assertions:
            has_access: false            

        - user: user:john
          object: module:C
          assertions:
            has_access: true        

[prsanjay]

Hi @aaguiarz This is great. Looks like it solves the problem. Many thanks.

Now, I just have below 3 questions

1. Will adding the module access check directly into the regular authorization check (by defining and has_access from module and belongs_to from account for each resource type) cause any performance issues? Or would it be better to separate the module access check into its own API call, keeping the regular authorization check independent?
2. In the regular authorization check, I also need to verify whether the resource being accessed belongs to the same account as the logged-in user's account. I’ve defined an account relationship (belongs_to from account) for this purpose and applied it to each resource type. Is this the correct and recommended approach?
3. Could you please review the model definition below and confirm if it looks appropriate and correctly structured?

Final model look like this

model
  schema 1.1

type user

type account
  relations
    define belongs_to: [user]
    define user_in_context: [user] and belongs_to

type group
  relations
    define account: [account]
    define member: [user]

type role
  relations
    define account: [account]
    define assigned: [group#member]
    
    # Who can manage roles
    define can_aceess: [user] and user_in_context from account
    define can_create: [user] and user_in_context from account
    define can_update: [user] and user_in_context from account
    define can_delete: [user] and user_in_context from account

type section
  relations
    define module: [module]
    define account: [account]
    define section_delete: [role#assigned] and has_access from module and belongs_to from account
    define section_edit: [role#assigned] and has_access from module and belongs_to from account
    define section_read: [role#assigned]  or section_edit
    define section_update: [role#assigned] and has_access from module and belongs_to from account

type fund
  relations
    define module: [module]
    define account: [account]
    define fund_create: [role#assigned] and has_access from module and belongs_to from account
    define fund_delete: [role#assigned] and has_access from module and belongs_to from account
    define fund_update: [role#assigned] and has_access from module and belongs_to from account

type module
  relations
    define subscribed_to: [account]
    define has_access: [user] and user_in_context from subscribed_to

[aaguiarz]

In general, you would try to model all permission in the model and avoid doing two checks. Sometimes is not possible, but in this case it is. Evaluating the permission will be more expensive, but still pretty fast.

About the model in relations like the one below, has_access from module already evaluates belong_to from account, because user_in_context is defined as [user] and belongs_to:

define section_delete: [role#assigned] and has_access from module and belongs_to from account

You can just write it as:

define section_delete: [role#assigned] and has_access from module and belongs_to from account

The same everywhere you have has_access from module

[prsanjay]

I'm also a bit unclear on how to properly model the resource.create permission.

In my use case, only specific user groups should be allowed to create resources. For example, members of Group-1 should have permission to create funds, sections, and other resource types.

Here’s how it currently works:

When a user attempts to create a fund within account-1, the backend checks if the user belongs to a group under account-1 and whether that group has a role assigned which includes the fund.create permission (similarly for other resources).

While actions like edit, delete, and read can be scoped to specific resource instances, I'm not entirely sure how to handle the create action — since it’s performed at the collection level rather than on a specific object.

The same question applies to actions like list, where I’d like to restrict which users can view the list of funds within an account.

Thanks in advance

[aaguiarz]

Hi @aaguiarz, do you mean just write as below?

define section_delete: [role#assigned] and has_access from module

instead this?

define section_delete: [role#assigned] and has_access from module and belongs_to from account

Yes

[aaguiarz]

I'm also a bit unclear on how to properly model the resource.create permission.

In my use case, only specific user groups should be allowed to create resources. For example, members of Group-1 should have permission to create funds, sections, and other resource types.

Here’s how it currently works:

When a user attempts to create a fund within account-1, the backend checks if the user belongs to a group under account-1 and whether that group has a role assigned which includes the fund.create permission (similarly for other resources).

While actions like edit, delete, and read can be scoped to specific resource instances, I'm not entirely sure how to handle the create action — since it’s performed at the collection level rather than on a specific object.

The same question applies to actions like list, where I’d like to restrict which users can view the list of funds within an account.

Thanks in advance

You would define the permission at a higher level, e.g. the Account :

type account
  relations
     define can_create_found: [role#assigned] and belongs_to

[prsanjay]

Thanks, @aaguiarz. However, I also need to make sure that the user has fund module access while checking can_create_fund, as I did for resource sections. Can I define relation like below to achive this?

type account
  relations
    define module: [module] # This is newly added
    define belongs_to: [user]
    define user_in_context: [user] and belongs_to
    define can_create_fund: [role#assigned] and has_access from module # this is newly defined

Tuple will be like this

user: module:fund
relation: module
object: account:a

[prsanjay]

Also, another question is, when the module access is revoked for the user for the specific account, we will have to remove that tuple entry from the OpenFGA store, but as per above model, when module access is given to the user, we create the below tuple

user: user:john
relation: has_access
object: module:fund

Here, we do not have any user account context. So, how to know which tuple needs to be removed for the user:john here? Because user:jon can be present in multiple accounts(using that belongs_to relation) and he may have got the module access via those accounts. So basically we want to remove the module access tuples for the user:john when he is removed from the account OR we also need to remove the module access tuple when module access is revoked for the user:john for the specific account.

[aaguiarz]

re: can_create_fund maybe it needs to be at the module level instead of the account level?

type account
  relations
    define belongs_to: [user]
    define user_in_context: [user] and belongs_to
    define can_create_fund: [role#assigned]\\

type module
  relations
    define subscribed_to: [account]
    define has_access: [user] and user_in_context from subscribed_to
    define can_create_fund : has_access and can_create_fund from subscribed_to

[aaguiarz]

re: module access,

You'll need to figure out when to delete that tuple on your application side. How do you decide that currently? E.g. if a user was granted access to a module directly, how do you decide to revoke that access when a user is removed from an account?

[prsanjay]

Hi @aaguiarz Right now the module access is not given directly to the user. It is given to user_account I have these tables. users, accounts, user_accounts, modules there is many-to-many relationship between users and accounts table. When the user is created inside account at that time module is selected for that user_account and we store that mapping inside user_account_modules table where we keep user_account_id and module_id. When the module is rovoked for the user_account we remove the record from user_account_module table.

[prsanjay]

Hi @aaguiarz I am thinking to define new type user_account as below but not sure how to setup relationship with module type. Your help will be much appreciated.

type user_account
  relations
    define user: [user]
    define account: [account]

[aaguiarz]

You'd do something like this:

type account
  relations
    define belongs_to: [user]
    define user_in_context: [user] and belongs_to

type user_account
  relations
    define user: [user]
    define account: [account] 
    define user_in_context: user and user_in_context from account

type module
  relations
    define user_account: [user_account]
    define has_access: user_in_context from user_account

The user_account tuples would be like:

- user: user:anne
   relation: user
   object: user_account:anne_acme # you need to find an ID for the user_account
- user: account:acme
   relation: account
   object: user_account:anne_acme
- user:user_account:anne_acme
   relation: user_account
   object: module:A

[prsanjay]

Thanks a lot.

[prsanjay]

Hi @aaguiarz, Thank you so much for your help so far.

A quick question, according to the model, I need to create all the granular resources in the OpenFGA to check if they belong to the correct account and have correct module access in a single API call. If I do this, then the number of tuples will increase significantly in a very short time. For example, I need to create all the sections, funds, and many other tuples in the OpenFGA store by setting up the relation between account and module as below

- user: account:acme
   relation: account
   object: section:123
- user: account:acme
   relation: account
   object: section:124
- user: account:acme
   relation: account
   object: section:125
- user: account:acme
   relation: account
   object: section:126

... And many more such for other resources as well.

Also need to create similar tuples for the module as well as below

- user: module:a
   relation: module
   object: section:123
- user: module:a
   relation: module
   object: section:124

... and so on

Do you think this approach could lead to a bottleneck quickly? I want to ensure the authorization check API call completes within a few milliseconds.

[aaguiarz]

Hi @prsanjay

Yes, that is the way that OpenFGA and Relationship Based Access Control works. You can have billions of tuples on an FGA database.
You need to provide the data first so the authorization checks are very fast.

If you don't want to synchronize the data, you can use OpenFGA's Contextual Tuples https://openfga.dev/docs/modeling/token-claims-contextual-tuples and send some of those tuples in each request to FGA.

[prsanjay]

Thanks a lot @aaguiarz for the confirmation

[prsanjay]

This answers all my questions. Thanks a lot.