Accessing the supergraph from a plugin?

[mbStavola]

I'm interested in moving authorization from each subgraph provider into the router itself by building a custom plugin to handle this.

The working idea is that since each subgraph will have authz directives annotating the various fields, the router should be able to pick out what directives are "in scope" for an inbound request and execute the appropriate authorization logic.

However, after poking around the custom plugin code a bit, I'm at a loss at how I might be able to access the supergraph from within any of the available tower services. Ideally I'd want my plugin to walk the supergraph on startup to path out the various directives and then trigger the auth logic if a request touches any of those paths.

Any pointers? I'm also open to alternatives to achieving the same goal 😄

[golfingal72]

Does your supergraph contain the authorization directives? In my case, i have custom authorization directives in my subgraph components, but the supergraph drops those directives (at least when i fetch from apollo studio) since the custom directives do not bubble up to the supergraph... This is not an answer :)

[mbStavola]

It seems rover does strip out the directives from the subgraphs when composing the supergraph, but I imagine that:

• in the future it could be possible to have rover not do that (seems that's what Compose user directives federation#1897 is aiming to solve)
• barring the above, it should be possible to manually add those directives to the supergraph (sucks, but it's a workaround)

[abernix]

in the future it could be possible to have rover not do that (seems that's what apollographql/federation#1897 is aiming to solve)

That is exactly what that PR is trying to solve! And indeed, once those are introduced into the supergraph itself, the Router will be working on an initiative to enable us to operate on those directives.

The working idea is that since each subgraph will have authz directives annotating the various fields, the router should be able to pick out what directives are "in scope" for an inbound request and execute the appropriate authorization logic.

In the general sense, what you're describing makes a lot of sense. Would you mind getting a bit more in depth with how you imagine this working though? Our near-term plans are trying to come up with a generalized way for such behavior to work that would de-necessitate you needing to write a custom plugin for it and build functionality that can benefit lots of users. Some sketches and description of how you'd like this to work would be really useful!

[mbStavola]

That is exactly what that PR is trying to solve! And indeed, once those are introduced into the supergraph itself, the Router will be working on an initiative to enable us to operate on those directives.

Awesome!

Really exciting to see what you're all building here and the fact that you're already thinking about this use case is really nice to see.

Would you mind getting a bit more in depth with how you imagine this working though?

(I apologize for the info-dump beforehand)

FYI: Our ideas weren't fully formed, we just had some interesting thoughts and I was doing some exploratory code to see what and how much we could accomplish. For our use case, we were aiming for something pretty specialized for our set-up and not something that was generally applicable. I don't know if you'll find any of this useful, but hopefully you can get at least something out of these ideas.

Anyway, the core concept is that we want to leverage directives in the supergraph to coordinate calls into the graph which can either a) directly validate a request or b) provide more context for an authorization step down the road. The rationale being that if you're handling this at the router level you can avoid a good chunk of cross-service authorization calls while processing the subgraph query. Additionally, since you're essentially seeing the whole request from the get-go, you could even potentially deduplicate some authorization calls.

For the plugin I was going to build, you'd pass in some config which mapped names of particular directives to an operation type and an ad-hoc query which actually carried out the operation. For example:

plugins:
  example.progressive_authz:
    directives:
      - "@authz_loggedin":
        operation: "no-op"
      - "@authz_owns_content":
        operation: "validate"
        q: |
          query ExecValidation($userId: ID) {
            result: doesUserOwnContent($userId: ID)
          }
      - "@authz_accountmember":
        operation: "upsert-jwt"
        q: |
          query ExecUpsert($userId: ID) {
            accountMemberships(userId: $userId) {
              id
              role
            }
          }

The available operations would be:

• do nothing (no-op)
  • the subgraph provider will probably handle the authorization later on
• update the jwt (upsert-jwt)
  • query subgraph and add response to the current JWT to provide additional context for the subgraph provider to perform authorization
• perform a validation (validate)
  • immediately execute a query which determines if a request can complete

The directive args + values would also be parsed from the subgraph and passed in as variables if you had a variable of the same name in the query. There'd also be some support for some common variables we might want to pass, like $userId or whatever.

I've have a contrived example that touches on a few of the things I was trying to accomplish. I have a simple schema that represents some (fake) supergraph with some directives used for authorization.

In the simplest case, we'd essentially just trip @authz_accountmember which the plugin's config has us execute a query and modify the request's JWT.

As mentioned before, we also want to make sure we're avoiding duplicated queries, so in this example you can see that we would trip @authz_internal_or_user twice but the plugin would only call it once-- it's the same call, after all.

Finally, while deduplication is great, we have to ensure that the plugin isn't removing things that might actually result in different auth behavior, which you can see in the final example where the same directive is kept if it has different args when called. Beyond this we might also want to think about coalescing; if you have the same directive multiple times with different args, maybe it's possible to do a batch call with every arg at once. I don't have an example of that because I'm not quite sure what it would look like.

My plan to accomplish this was basically:

• load the list of directives and operations from the config
• walk the supergraph on application startup
  • parse out the actual directive definition (pull out arg names and default values) for directive names that match what is in the config
  • record "paths" through the graph where a directive is present
    • essentially walk the types themselves to see how the fields resolve and what directives are present
    • ex: from the example graph, query:me would be recorded as mapping to @authz_loggedin for each incoming request and query:me:courses would be recorded as mapping to @authz_loggedin, @authz_internal_or_user, and @authz_owns_content
• walk the incoming query/mutation for each request
  • trace the "path" and do a lookup against the path to directive mapping
  • if we hit a directive we care about, record the directive and the args passed in(or the lack of)
  • at the end, "deduplicate" any directives that are the same (same name + same args)
  • iterate over the list of "hit" directives and execute the operation defined in the config

Again, I hadn't entirely thought this through but that was the idea I had in mind when discussing this with my team. Now, that's a good bit of work, so our initial scope for this is to just do the upsert-jwt op without doing any arg passing. It'd check off probably most of what we want initially and we figured we would eventually build out the other ops / more sophisticated operation as needed. I figured with that small-ish scope I could hack it out with a custom plugin, but hit the wall with the supergraph-- hence the issue 😄.

Hopefully this wasn't too much info / not super helpful!

[abernix]

This is super helpful and the right amount of information! Thank you very much for taking the time to share it.

I'll ping in some of the team — @Geal, @garypen — who have also been thinking about this. 😉