Auth Webhook should support multiple roles X-HASURA-ROLES

[olragon]

It's normal that the user can have many roles. Eg: user = john can be contributor & admin

When using Auth Webhook, as of #1420 (comment), developers should resolve multiple user roles to a particular role.

To do that, developers must somehow resolve GraphQL operation name (can't be trusted), variables, and query (pass as string from webhooks) to the GraphQL data -> the user's role -> return to Hasura. I think the point of Hasura is to reduce friction for developers to adopt GraphQL, and it defeats the point of using Hasura.

The straightforward way is for developers to return all user roles using X-HASURA-ROLES and lets Hasura handle the rest like JWT Auth.

Auth Webhook's POST request

{
  "headers": {
    "header-key1": "header-value1",
    "header-key2": "header-value2"
  },
  "request": {
    "variables": {
      "a": 1
    },
    "operationName": "UserQuery",
    "query": "query UserQuery($a:  Int) {\n  users(where:  {id:  {_eq:  $a}}){\n    id\n  }\n}\n"
  }
}

[iosifnicolae2]

I need this functionality too. Inherited Roles does not work for my use-case..
I want to allow non-technical users to pick the permissions they want to grant to the API user, so I would like to create multiple roles like allow-record-select, allow-record-insert and so on, and the user will pick these roles and the webhook will pass them to Hasura as @olragon described above.

[raarts]

I have a similar use-case. I need the web-hook to return the allowed roles, and the client to specify the one that the user has picked. The user gets a drop down that has all his allowed rules in it.

This currently does not work, as hasura requires a role from the web-hook, and returns "4400: Connection initialization failed: x-hasura-role not found in session variables". Even though I provide a header with the current role.

EDIT: Note this comment only pertained to my situation i.e. websockets. In the mean time I found out that it's not possible from a browser to add headers to a websocket call, so it's not even possible to add an X-Hasura-Role to that.

Maybe we all could standardize on a method to send information randomly to the server (like the current user role) with having to close/reopen the connection? Thanks.

[Kaelten]

I'd suggest that the answer is already present in the JWT auth pathways. having x-hasura-allowed-roles and x-hasura-default-role be respected from the webhook handles this safely.

query inspection is just not viable.

[raarts]

@Kaelten Can you expand on your comment a bit? Maybe with an example?

[Kaelten]

My problem is I have auth requirements that are not possible with just JWT validation. Thus I have a auth webhook that is validating one or more JWTs that come in on the request and then return an effective claim.

Ideally, I'd like to be able to return x-hasura-allowed-roles = "user,maker,staff" and let hasura figure out what the correct role or roles to use for the request.

After reading more it appears this isn't how it'd work currently either as we'd also need the client to ask for a specific role for the request. I've seen some back and forth in various tickets and discord threads but it's unclear to me if this is something I should keep an eye out for or if I should try to find a work around.