Table of Contents

• Introduction
• Example Data
• Relationships
• Permissions
• Query Results

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:

• Teams
• Organizations
• Tenants in a Multi-tenant app
• Chat group-messages, & more!

Let's assume that you have some table structure like the following:

Here we have example users:

• John & Jane belong to Organization ID 1
• Frank belong to Organization ID 2

We create the following database records:

• user

• organization_user

• organization

We create the following relationships on our data:

• user

• organization_user

• organization

And provision the permissions like such:

• user

• organization_user

• organization

Now when we query with our X-Hasura-User-Id set as User 1 and 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.

If you have any questions or want to share your thoughts on the topic, reach out to us on Twitter / Discord / GitHub Discussions.