Graphql-engine: [Feature request] Multiple admin-secret keys and secret key management

Created on 12 Apr 2019  路  6Comments  路  Source: hasura/graphql-engine

Currently, Hasura only allows 1 secret key as admin role.

This feature request suggests a tab on console for admin to add/edit/revoke more key-role pair:

  • Key is the access_key
  • Role is the role.
  • (optional) Expired time (default is forever)

So, this will allow bypass JWT authentication for specific client.

The default admin-secret should be immutable and showable for the first admin only.

API usage:

Client needs to send header x-hasura-secret-key to access hasura.

Use case:

  • I have some 3rd party applications which needs a key to access hasura.
  • A team could safely colloborate in console with many roles: dev, database administrators, manager,... with each role has only specific permissions.

Related issue:

https://github.com/hasura/graphql-engine/issues/587

With this feature, hasura will eventually support access console for all roles.

Alternative solution:

We need a table secret_keys with three columns above and a join table between secret_keys and the table you want to grant access. And use secret_keys in permissions settings.

ideas

Most helpful comment

@revskill10 I love your idea Or maybe more general if Hasura can support a simple user password authentication and merge that with jwt or webhook then admin users can use builtin authentication feature. (I think this approach is more dynamic than key/role approach and still we can use one specific user/password rather than key/password for specific client app)

In that case we also need some new permissions for example called:

  • access_data_tab
  • access_graphql_tab
  • access_remote_schema_tab
  • access_trigger_tab

To restrict access to each part of console app.

All 6 comments

@revskill10 I love your idea Or maybe more general if Hasura can support a simple user password authentication and merge that with jwt or webhook then admin users can use builtin authentication feature. (I think this approach is more dynamic than key/role approach and still we can use one specific user/password rather than key/password for specific client app)

In that case we also need some new permissions for example called:

  • access_data_tab
  • access_graphql_tab
  • access_remote_schema_tab
  • access_trigger_tab

To restrict access to each part of console app.

@mnlbox I think user management is a different issue.
This is all about secret keys management. Imagine you could grant some clients a secret key for them to access as a role. That client could be a user, or could be another server.

@revskill10 are you thinking more along the lines of allowing multiple admins specific keys to hit the API or console? I think that would be really useful as people leave teams/companies then you only need to remove that users admin key.

@jasonmccallister My main motivation for this feature is that, i need to integrate a 3rd client to access Hasura as a specific role. So the simplest solution is to grant an access_key for it.

Ok perfect, we have a huge need for this feature as well! Thanks @revskill10!

Also, I would say this falls into two buckets:

  1. Assigning admin keys to clients
  2. Assigning roles

We have a separate function that returns a JWT for a predefined role for the 3rd party client - that works well but of course it does not allow them to use the console in stage.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

leoalves picture leoalves  路  3Comments

bogdansoare picture bogdansoare  路  3Comments

coco98 picture coco98  路  3Comments

marionschleifer picture marionschleifer  路  3Comments

cpursley picture cpursley  路  3Comments