How To: User permissions when having multiple groups with different roles for each

[GiamBoscaro]

We are logging in and authorizing users in our platform from LDAP through Keycloak, generating a JWT that will be consumed by Hasura to authorize operations in the tables and filter the rows as needed.
The users are identified and authorized using two parameters: their role, and the organizations they are into.

Example:

admin -> can see and edit any info
manager -> can see and edit any data related to the org he is into
user -> can see and change just its data

This works perfectly good in Hasura, setting up the permissions based on x-hasura-role, x-hasura-user-id and a custom claim named x-hasura-org-ids (this is a list).

Problems are arising now since we need more fine grained control over the permissions. It is possible that a user is into multiple organization, but a different role is assigned to the user in each organization.

Example:

User A

• org 1 -> user
• org 2 -> manager
• org 3 -> none
  This is the problem. See at the bottom.

User B

• org 1 -> user
• org 2 -> user
• org 3 -> none
  In this case, Hasura role based authorization works totally ok. The org 3 data is filtered out in the permissions with:
  {"orgs":{"org_id":{"_in":"x-hasura-org-ids"}}}, then the user data is filtered with {"user_id":{"_in":"x-hasura-user-id"}} so the user can only see its own stuff.

User C

• org 1 -> admin
• org 2 -> user
• org 3 -> none
  In this case, in our system this user will be considere a full admin. Orgs here do not matter anymore. No a problem for Hasura, all the queries are unfiltered.

User D

• org 1 -> manager
• org 2 -> manager
• org 3 -> none
  Same as User B, in this case the role will be manager so there is no need to filter for the user id, but just for the user orgs.

So, the problem here is User A. User A is a manager in org 2, but a simple user in org 1. In this case, User A should be able to see and edit all informations about org 2, but only its own stuff for org 1. In Hasura though, you can just have one, so this user will actually have: x-hasura-role: manager, x-hasura-org-ids: { org1, org2 }, and thus he will be a manager also for org 2.

Solution 1: Inherited Roles (Not Feasible)

I was trying to understand if I could use Inherited Roles to solve this problem, but I think I cannot. I should create one role for each org, and then one role for each user role. Then I could create all the Inherited Roles combining all user roles with all the orgs roles.

Example:

org1_user
org1_manager
org2_user
org2_manager
...

This though would not solve the problem, because you still can pass Hasura one single role. In case of User A, I would need an Inherited Roles like org1_user_org2_manager. That is crazy, and impossible to manage.

Solution 2: Manual Filtering on Queries and Mutations (Ugly, Hardly Mantainable, Errors Prone)

Another solution would be to change all the GraphQL queries I have, and manually filtering based on the LDAP groups that the users have (so not even using x-hasura-org-ids and x-hasura-role coming from the JWT.

Example:

From LDAP:
org2_manager, org1_user
Mapped in the JWT as:
x-hasura-role: manager, x-hasura-org-ids: {org1, org2 }
These permissions are too weak, so instead forward LDAP groups to the JWT claims (x-hasura-ldap-groups: {org2_manager, org1_user }). Manually filter on queries based on these groups.

query MyQuery($user_id: uuid!, $user_orgs: [String!], $manager_orgs: [String!]) {
  my_table(where: {
    _or: [
      # This shows the user owned entries, for orgs where he is only a user
      {_and: [{user_id: {_eq: $user_id}}, {orgs: {org_id: {_in: $user_orgs}}}]},
      # This shows all entries related to orgs where he is a manager
      {orgs: {org_id: {_in: $manager_orgs}}},
    ]}) {
    id
  }
}

This is absolutely ugly, and a mess to mantain. Moreover it requires some pre processing for each query to map the LDAP groups into user_orgs and manager_orgs. I would like to avoid this.

Solution 3: Manual Filtering in the Permission (similar to solution 2 but baked into permissions)

This solution would follow the same principles as the previous one, but the filtering is made in the user permissions. The manager role in particular should have the kind of filtering seen in the query above.
To do this, it would be necessary to create some new tables in the Database, and insert the user role associated to the org when the user logs into the system. Having this information in the database, it means that in some way a permission can be setup to filter the database entries. This does not require and processing since the data is processed and saved at login, and doesn't require a change in the query and mutation on the client since everything is done in Hasura. It does require a new table and some data duplication between LDAP and Hasura. Also, it mostly renders the JWT claims useless since now all the data is filtered using the information contained in the Hasura DB, after recognizing the user from x-hasura-user-id .
This might be the best solution that I have found at the moment, but it is still very ugly imho, and I still have to test this anyway to understand if it is feasible.

Example:

New Table:
user_id: uuid! -> fk to users.id
role: String! -> fk to roles.value (just an enum table, not mandatory)
org_id: Int! -> fk to orgs.id

{
   "_or":[
      {
         "user":{
            "orgs":{
               "_and":[
                  {
                     "role":{
                        "_eq":"manager"
                     }
                  },
                  {
                     "org":{
                        "_in":"X-Hasura-Org-Ids"
                     }
                  }
               ]
            }
         }
      },
      {
         "user":{
            "_and":[
               {
                  "user_id":{
                     "_eq":"X-Hasura-User-Id"
                  }
               },
               {
                  "orgs":{
                     "org":{
                        "_in":"X-Hasura-Org-Ids"
                     }
                  }
               }
            ]
         }
      }
   ]
}

Again also in this case the permissions are getting fairly complex and hard to comprehend, making maintenance harder and also future changes more complex.

Solution 4: New Claims with list of orgs per role

Another solution that I have found is that instead of using x-hasura-org-ids to list all the organizations, I could create multiple claims, one for each role, that contains the list of organizations per role. This could be something like:

x-hasura-manager-orgs: list of organization where the user is a manager
x-hasura-user-orgs: list of the organization where the user is a normal user

At this point, x-hasura-role would still be the highest role available, but then the database entries can be filtered more by using these new claims. The permissions should be much easier at this point.

{
  "_or": [
       // Either the entry is from an organization where the user is manager, so he can see and edit it
    {
      "org": {
        "_in": "X-Hasura-Manager-Orgs-Ids"
      }
    },
       // Or the entry is from an organization where the user is a normal user, so also the user ID needs to match
    {
      "_and": [
        {
          "user_id": {
            "_eq": "X-Hasura-User-Id"
          }
        },
        {
          "org": {
            "_in": "X-Hasura-User-Org-Ids"
          }
        }
      ]
    }
  ]
}

This does not even required to copy information in the database, and does not require the new table to connect orgs to role and user. This could be the optimal solution, requires only more processing during the creation of the JWT.