Introducing Remote Table Authorization: Write permission rules across all your data

In the ever-evolving world of data management, allowing complex access control becomes paramount for business success. We are thrilled to introduce our latest feature: Remote Table Authorization.

With Remote Table Authorization, you can now use data from different sources to perform authorization checks on any table.

This innovative project was born out of a pressing need raised by our Cloud Team and AI Innovations team. The use case is not only common but also incredibly powerful, as evidenced by its recent showcase in the HasuraCon 2023 AI talk through an ad-hoc PoC (Proof of Concept).

Hasura's permission system has always excelled in filtering data, treating permissions as a special case of filtering. However, a significant challenge emerged when it came to filtering based on fields from remote relationships.

Consider you have two tables on your database as follows:

Defining a permission based on this setup was already easy with Hasura when the 2 tables are in the same data source, or as long as there is a column in the target table to compare with.

ie. you could add a row access permission logic on posts that check for user_id equals to x-hasura-user-id as follows

But, as we see the data growing and getting distributed across different systems, you may notice the individual data units could be managed by different teams or even different tools.

Now imagine the posts table, which is mentioned above, is coming from an external CRM system, where the user_id is different, and you don’t have the luxury to modify the posts table schema or add an additional column to it.

Usually in such cases what we will do is, to create a column mapping on existing user table to accommodate the crm_user_id which the CRM is using as follows, and add a Hasura remote relationship as follows.

Now that we have the next set of problems, how do we write the permission for posts?

This is where the Remote Table Authorization helps!

You can now define permissions across data sources and reference remote relationship row values to contain the permission rule.

So in this example, let’s define a remote relationship as follows:

and now we will be able to define a permission on the posts table with the remote relationship that we created as follows:

As you can see, the permission rule is agnostic on the crm_user_id (id on the posts table), and it uses the user_id from the user table to grant access to the posts.

So if you are a data architect, you don’t have to think about the access permissions logic, as it is already taken care of by Hasura. Previously this could not be done directly.

And the developers can simply query as:

query MyPosts {
  posts {
    id
  title
    author_id
    content
  }
}

Now, let's make it more interesting!  

Imagine the column author_d in the table posts, is something you don’t want in your API layer- say it's an internal reference or some sensitive identifier.

Now, we can remove column select permissions of user_id from posts table and crm_id from users table so that these fields are not visible in the API layer but play a critical role in granting access to the posts.

Imagine this scenario where each table resides in a different source. A remote relationship permission (on Table A) might appear as follows:

{
  "relAB": {
          "id_B": {
              "_eq": "X-Hasura-User-Id"
          }
      }
}

To evaluate this permission expression, we follow these steps:

• Retrieve all the id values from table B where id_B equals X-Hasura-User-Id.
• Then, the boolean expression for table A is id_B in the result set from step 1.

So, to evaluate any remote relationship permission, we need to perform these steps. It involves evaluating the inner node and then working our way up, generating a boolean expression for the table on which the permission is defined.

While Remote Table Authorization unlocks exciting possibilities, we acknowledge certain limitations:

• As we explained the execution, it fetches the remote relationship side first and then the actual table- this means if the response from the remote relationship table is too long, the query to RHS would also be a lengthy `in` query. This has to be considered while using this solution with many-to-many sort of relationship permissions.
• Currently, the console will show this option for GDC-based data sources by default, if you want to see the console for native data sources, you can enable the “Data Tab Performance Mode” feature flag from the settings.

With Remote Table Authorization, Hasura continues to lead the way in simplifying and enhancing data access control in GraphQL APIs. We're excited to empower you with the ability to define intricate permissions for remote relationships, offering a robust solution for your most complex data access scenarios.

Discover more about Remote Table Authorization by exploring our documentation and giving it a try in your projects.

Sign up now to unlock the full potential of your data relationships with Hasura if you are not on Hasura yet!