For the access tokens, do they work with the edit policies? Ie if person A does not have edit rights to a dataset and passes in a MCE/MCP about that dataset to :9002/api/gms with his access token, will he be rejected? also, if i do not allow users to generate their own token, can I still query for user's tokens in the backend (via custom UI code) and use it to ingest metadata on their behalf?

cc: @big-carpet-38439

@better-orange-49102 For now, privileges are limited to logical. We do not have access privileges for each specific aspect. Additionally, fine-grained access policies are only enforced when you are calling the GraphQL API -- Restli APIs used for ingestion are not managed with policies (though the framework can be extended to support it) What is the use case you're hoping to achieve in querying for another user's token? As detailed in this deep dive ( and the original metadata service auth design doc ), there is currently no authentication on the kafka ingestion path

Thanks for the detailed reply @big-carpet-38439! Actually there's no reason why I'll need to query for other people's token - that was a poorly phrased question. In my code I'll query for and get the page users' code to pass to a third party API which uses that to create a rest emitter with the user token. Is there a way to verify the token against the user, though? I want to avoid a case where the user copied his token but uses another identity. If there is a way to check if the token belongs to the user that would be immense for me. Ie, an endpoint that I can query with a token string to check the users identity and expiry date.

Got it. So one way is to hit the "me" endpoint in GraphQL, which will return the URN for the currently authenticated user

i think i'll just decode the jwt and verify that the token is who the person claims to be in my 3th party API (since i deployed it) in the meantime, and i'll slowly work my way to write operations as opposed to read in graphql. 🙂

correct!