Implementing Authorization for Organization-based, Team-based, or Tenant-based Apps in Hasura
Table of Contents
This blog post is the first in a 2-part series that aims to outline how to model a common organization-based permission system in Hasura. Keep your eyes peeled for the second part for a walkthrough of a clonable sample repo that you can use to model similar permissions systems.
The problem being solved is:
"In my application, I have a 'group' and entities that belong to group(s)."
"Each entity in the group should only be able to see/interact with other entities in the same group(s)."
This is a common pattern in applications and in this article we'll take a look at one of the ways you can solve it. Our solution will use nothing but Hasura's standard permissions system and authorization rules.
This approach and principle works for any "group"-like structure, such as:
- Tenants in a Multi-tenant app
- Chat group-messages, & more!
Let's assume that you have some table structure like the following:
|Table Name||Columns||Foreign Keys|
Here we have example users:
Janebelong to Organization ID
Frankbelong to Organization ID
We create the following database records:
We create the following relationships on our data:
And provision the permissions like such:
Now when we query with our
X-Hasura-User-Id set as User
3 respectively, we can see only those users in our own organizations:
- Querying as
John(User ID 1, Org 1)
- Querying as
Frank(User ID 3, Org 2)
Voila! We've successfully implemented an organization-based authorization system using Hasura!
The previous article in our authorization cookbook explains how to implement a hierarchical Google Drive-style permission system in Hasura using ACL.