Authorization alpha version #3439
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We introduce two new directives, `@authenticated` and `requiresScopes`, that define authorization policies for field and types in the supergraph schema. They are defined as follows: ```graphql directive @authenticated on OBJECT | FIELD_DEFINITION | INTERFACE | SCALAR | ENUM directive @requiresScopes(scopes: [String!]!) on OBJECT | FIELD_DEFINITION | INTERFACE | SCALAR | ENUM ``` They are implemented by hooking the request lifecycle at multiple steps: - in query analysis, we extract from the query the list of scopes that would be relevant to authorize the query - in a supergraph plugin, we calculate the authorization status and put it in the context: `is_authenticated` for `@authenticated`, and the intersection of the query's required scopes and the scopes provided in the token, for `@requiresScopes` - in the query planning phase, we filter the query to remove the fields that are not authorized, then the filtered query goes through query planning - at the subgraph level, if query deduplication is active, the authorization status is used to group queries together - at the execution service level, the response is formatted according to the filtered query first, which will remove any unauthorized information, then to the shape of the original query, which will propagate nulls as needed - at the execution service level, errors are added to the response indicating which fields were removed because they were not authorized
Co-authored-by: Lenny Burdette <[email protected]>
Definition: ```graphql directive @Policy(policy: String!) on OBJECT | FIELD_DEFINITION | INTERFACE | SCALAR | ENUM ``` `@policy` is designed for usage with coprocessors: - extract the list of policies relevant to the query, store them in the context - the coprocessor (or a rhai or native plugin) goes through the list of policies and marks them as successful or not - the router then filters fields from the query according to which policies were successful the `policy` argument could be the actual authorization policy to execute, in text form, or an index into a list of policies that the coprocessor knows how to execute. This will allow router authorization to leverage existing authorization systems, with custom policy languages, or ones that call into central state like a roles database. Field filtering and null propagation happens in exactly the same way as the other authorization directives, and can be used with them in the same schema
this uncovers an issue with type condition on fragments, fragment spreads and inline fragments: we should check if the type is authorized there
if we want rhai or a (future) coprocessor to modify the authorization status at the supergraph level, then the cache key metadata for authorization should be set up after those plugins have run
|
CI performance tests
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
DO NOT MERGE
This contains the following PR for an alpha version of the authorization feature: