Graphql-engine: Permissions for Remote Schemas

[tirumaraiselvan]

v1 (wip #2690):

Schema masking: Role-based types for query_root, mutation_root and subscription_root fields
Deep schema masking: Role-based type for anything (object type, input object type, scalars?).

v2:

Input argument presets.

[leoalves]

Hi @tirumaraiselvan,

One idea, that I think would be easier, is to let the Remote Schema generate different schemas, for each role.

If Hasura sends the role, in the headers, when doing the introspection query. The Remote Schema could return different schemas, based on each role.

I created an issue about that a while ago.
https://github.com/hasura/graphql-engine/issues/2139

[tirumaraiselvan]

@leoalves Cool, 1) is actually the exact duplicate of #2139 .

I will let both these issues open and use this as an umbrella issue for remote schema permissions.

[jadiaheno]

Anything new regarding that?

It would be great to have authorization at a single place, which is at the hasura level. If not, I will have to implement authorization to every remote schemas I have (10)

[tirumaraiselvan]

@bobberkarl This is WIP currently. It would be great if you could explain some more details of what kind of permissions you expect for Remote Schemas. Does the description of this issue satisfy your use-cases?

[cjonestcgsi]

@tirumaraiselvan Answering for a different company/use case.. In the case of an integration with Stripe - we would want to let a user see their own transactions and balance and certain status related details - such as the 'requirements' that Stripe may have for them, so we would want to query the remote schema using the stripe-customer-id, associated with the X-Hasura-User-Id, and to allow queries to certain tables and columns, where we force it to return results only for that particular stripe-customer-id.

[leoalves]

@cjonestcgsi
I think the use case you explained will be solved with Remote Joins, when that gets released.
https://hasura.io/remote-joins

[tirumaraiselvan]

@cjonestcgsi leoalves is right. Remote joins allows you to join tables with remote data. So if you have access to only stripe-customer-id (which is x-hasura-user-id) then you will get joined data corresponding to only that. The stripe use-case is also presented here: https://hasura.io/blog/remote-joins-a-graphql-api-to-join-database-and-other-data-sources/

[jacdx]

My use case is to extend the same header-based role permissions that I use across Hasura to my remote schema, which doesn't provide any usable access control other than CORS and tokens. I wish I could go into Data, see the entities from my Remote Schemas there, and be able to at least set high level query, mutation subscription permissions per entity. The closer it is to what Hasura does for it's own tables, the better.

[tirumaraiselvan]

@jacdx That's what we will aim to provide as well :)

[FickleLife]

Just wondering where this is sitting in the list of priorities? Thanks

[jorisw]

Will Remote Schema Permissions allow us to entirely hide part of our graph from public vs private clients (via roles)? We're trying to do this:

Roles

• Public consumer (i.e. a web app)
• Internal Service (non-Hasura GraphQL service)

Schemas to be unified:

• Internal Service A
• Internal Service B
• Internal Service C

Desired permissions:

• Internal services see the entire graph, unifying A, B, C's graphs
  
  
  
  • Internal services use Hasura's unified graph to call each other
  
  
• Public consumers can only see the graph of Internal Service A
• Public consumers don't see anything Service B or C related when introspecting the graph
  
  
  
  • Therefore public consumers can't directly call operations on Service B or C
  
  

Will Remote Schema Permissions facilitate this?
Or will Remote Schema Permissions only disallow _operations_ on a field level?