We had earlier covered writing permission rules for few popular use cases. In this post we will look at writing permission rules for a multi-tenant system.  

Authorization in a multi-tenant system usually means two things:

1. Each user needs to only have access to resources from that tenant.
2. A user's role depends on the tenant they are trying to access

If your use case does not require per tenant roles (i.e. does not require point 2. above), then have a look at this gist for a simpler implementation. We will loosely base this post on predefined roles in Google cloud platform's (GCP) role-based access control system. GCP's role-based access control system is an interesting use case because it is not only multi-tenant, the roles within each tenant are also hierarchical.

GCP roles overview

In GCP, every resource type has roles associated with it. For example: access to Google cloud storage buckets is controlled using storage_admin, storage_editor, storage_viewer roles. Similarly roles compute_admin, compute_editor, compute_viewer, etc control access to the compute engines.

Roles can be per resource as well. For eg: Each bucket has a storage_admin, storage_editor, storage_viewer role associated with it. So a storage_viewer for a given bucket can access only that bucket but a someone with a global storage_viewer role can view any bucket.

Both global roles and per resource roles are hierarchical i.e a Storage Admin can do anything a Storage Editor can do, etc.

Finally, every role is per project so a user can be storage_admin in one project but be storage_editor in another.

Setup

Database Schema

We will assume the following schema:

We have  a projects table and a users table to keep track of projects and users in the system. roles table has the list of all roles along with hierarchy information. user_project_roles maps users to their roles in a project and user_bucket_roles maps users to their roles for a given bucket.

We will also assume that we've created a one-to-one relationship user_bucket_roles from storage_buckets to user_bucket_roles. Note that keeping with the common convention, the relationship and the target table have the same name.

Note: While GCP has many resources, in the above schema we have only included the storage_buckets table. We will be looking at how to write permission rules for this table. Permission rules for other tables would be similar.

Creating a Storage Bucket in practice will probably involve coordinating between multiple services, allocating space, etc. The goal for this post is to only explain how to implement a system similar to GCP's role-based access control system. As such, we will conveniently ignore these complexities.

Flattening hierarchical roles

Similar to Example 3 in the previous post we will flatten user_project_roles and user_bucket_roles into flattened_user_project_roles and flattened_user_bucket_roles using the gist below. This allows us to not worry about the hierarchy in the roles.

For example if a user is assigned the storage_admin role in the user_project_rules table, flattened_user_project_roles will have 3 rows assigning them: storage_admin, storage_editor and storage_viewer.

Permission rules

Since we have modeled the roles in the database, we will use a single role called user in Hasura to define permissions rules. We will assume that the session variable X-Hasura-User-Id contains the user_id and X-Hasura-Project-Id contains the project that the user is trying to access.

Permission rules on storage_buckets

Select permissions:

A user can view a storage_bucket if they have the storage_viewer role on the given bucket or they have the global storage_viewer role.

We can implement the first rule with the following permission rule:

{
  "_and": [
    {
      "_exists": {
        "_table": {
          "schema": "public",
          "name": "flattened_user_project_roles"
        },
        "_where": {
          "_and": [
            {
              "user_id": {
                "_eq": "X-Hasura-User-Id"
              }
            },
            {
              "role_id": {
                "_eq": "storage_viewer"
              }
            },
            {
              "project_id": {
                "_eq": "X-Hasura-Project-ID"
              }
            }
          ]
        }
      }
    },
    {
      "project_id": {
        "_eq": "X-Hasura-Project-ID"
      }
    }
  ]
}

The above JSON uses the _exists operator to check if there is a row in the flattened_user_project_roles with the given role, project_id and user_id.

The second rule can be implemented as:

{
  "user_bucket_roles": {
    "_and": [
      {
        "user_id": {
          "_eq": "X-Hasura-User-Id"
        }
      },
      {
        "role_id": {
          "_eq": "storage_viewer"
        }
      }
    ]
  }
}

In the above rule user_bucket_roles is a many-to-many relationship between storage_buckets and user_bucket_roles. Hasura evaluates the rule by fetching user_bucket_roles for the current row and validating that user_id and role_id are equal to the given values.

We can now put the two in an _or clause for the final rule:

{
  "_or": [
    {
      "_and": [
        {
          "_exists": {
            "_table": {
              "schema": "public",
              "name": "flattened_user_project_roles"
            },
            "_where": {
              "_and": [
                {
                  "user_id": {
                    "_eq": "X-Hasura-User-Id"
                  }
                },
                {
                  "role_id": {
                    "_eq": "storage_viewer"
                  }
                },
                {
                  "project_id": {
                    "_eq": "X-Hasura-Project-ID"
                  }
                }
              ]
            }
          }
        },
        {
          "project_id": {
            "_eq": "X-Hasura-Project-ID"
          }
        }
      ]
    },
    {
      "user_bucket_roles": {
        "_and": [
          {
            "user_id": {
              "_eq": "X-Hasura-User-Id"
            }
          },
          {
            "role_id": {
              "_eq": "storage_viewer"
            }
          }
        ]
      }
    }
  ]
}

Update permissions:

Update permissions would look the same as the select permissions except we would be using the role_id storage_editor instead of storage_viewer

We also we need to prevent the user from updating the project_id column of a bucket:

Delete permissions:

Delete permissions would again look the same as the select permissions except we would be using the role_id storage_admin instead of storage_viewer

Insert permissions:

Only a user with a storage_admin role should be able to create a bucket:

{
  "_exists": {
    "_table": {
      "schema": "public",
      "name": "flattened_user_project_roles"
    },
    "_where": {
      "_and": [
        {
          "user_id": {
            "_eq": "X-Hasura-User-Id"
          }
        },
        {
          "role_id": {
            "_eq": "storage_admin"
          }
        },
        {
          "project_id": {
            "_eq": "X-Hasura-Project-ID"
          }
        }
      ]
    }
  }
}

We also want the project_id of the created bucket to be X-Hasura-Project-Id. We can do this using column presets:

Permission rules on user_project_roles and user_bucket_roles

We also need rules that allow certain users to assign or remove the roles of other users. We can have roles role_admin & role_viewer for being able to edit and view user roles respectively. Permission rules on user_project_roles and user_bucket_roles would then look similar to the insert permission rule on storage_buckets with the role name changed.

Conclusion

In this post we've seen how to implement permission rules for a full-fledged hierarchical multi-tenant system. Postgres Views and Hasura's Permission DSL make a rather powerful combination!

If you are using Hasura and need help with authorization, or want to share some interesting use cases you have implemented, ping us on Discord or tweet to us at @HasuraHQ!