Graphql-engine: [RFC] Add role name as root field to graphql schema to make multiple roles easy from the client

[coco98]

TL;DR:
Hasura roles can become root graphql fields called asRolename. This can be optionally enabled as an env-var or on a different graphql endpoint served by hasura: v1/roles/graphql.

---

When setting up permissions with Hasura, each "role" can have a potentially different schema.

For example, as a user, I might fetch 2 fields on a document: id, title. As an owner, I might fetch id, title, secretInfo. Currently, to make a graphql query, the client needs to set a role x-hasura-role: user or x-hasura-role: owner and necessitates 2 separate queries.

It would be a better experience and easier to build UI for different roles (because different schemas will result in different UI anyway; an owner might have an Edit page, for example), if the roles were a part of the graphql query and not have to be sent as headers.

query {
  asUser {
    documents {
      id
      title
    }
  }

  asOwner {
    documents {  
      id
      name
      secretData
    }
  }
}

This example might return in a response that has a list of documents that are visible to the current client in asUser and only select documents in asOwner where the current client has owner permissions.

This will clear up a lot of issues in managing multiple roles from the client, esp as discussed in in #877.

Would love to hear comments, thoughts regarding this feature idea.

[valstu]

Oh, just wrote my thoughts on https://github.com/hasura/graphql-engine/issues/877#issuecomment-479808962

[PierBover]

This approach wouldn't really work for us, and I suspect for the vast majority of authorization systems. We do not really have an active role. We know a user has a number of roles, and in consequence a number of permissions, and we check those in our authorization system whenever the user interacts with the API.

As for the different schemas for different roles scenario in an authorization context, why not simply check the fields in the query and compare those to the fields in the role schemas and finally decide if a request is authorized to see those fields or not?

[evert-smit]

@coco98 it's an interesting approach and it could probably be useful in certain scenarios depending on your setup.

However, like @PierBover says, a lot of the times you might not even have a specified active role. In my opinion, the option mentioned in #877 - (this specific comment) should have priority over this approach, as that approach is (probably) more widely applicable.

[kapolos]

@coco98 How about this?

Add a new type of check in the permissions that would allow us to do static checks over the x-hasura-allowed-roles.

Suppose I have allowed roles of [user,manager] and a table bonus. As a manager, I should be able to write to the bonus table. Then my insert check would be something like 'manager' _in X-Hasura-Allowed-Roles.

In other words, if you extend the ability to define checks not only on fields but on arbitrary strings, then we have huge flexibility to create complex, multi-role permissions without having to sync the existing roles from wherever they are (keycloak, ldap, anything) into Postgres.