graphql-shield and apollo managed federation

[petrovalex]

Hello,

currently, we'de like to use graphql-shield in managed apollo federation setup, together with apollo manager.
as we have a lot of services, it will be very time consuming to deploy graphql-shield to each service individually, so would like to use graphql-shield in apollo-gateway.

unfortunately, have not found any examples how to do it.
do you have any hints/examples on that?

Thanks!

[maticzav]

Hey @petrovalex 👋 ,

Thank you for opening up the question. I, sadly, can't help you much with Apollo Federation setup, but someone from the community might come across your issue and suggest an idea.

[quant-daddy]

Hi @petrovalex, as a federation user, I felt that it's best to have authorization layer (business logic) live in the same code base as the service itself because the service knows best what data to expose to the user. I wonder what your use case is to use shield at the gateway level.

[jgburet]

Hi @skk2142
I might be looking for the same as @petrovalex here.

I'd prefer to have the Apollo Gateway server to handle the authentication & the authorization. Indeed, I think it's best to have this part separated from the other services (that doesn't make sense to me to have the users & organizations logic duplicated everywhere). Also, I don't want these services to have to perform a call to the auth service on each request, but instead rely on accesses granted on the access token that I verified upfront.
That's why I thought having the authorization being done when the request reaches the gateway to be a good idea.

What I have in mind (and even started to do) is to define the needed permissions for a resolver in their service (same opinion as you have), but have the permissions check being done at the gateway level.
Does that make sense to you?

fyi, I'm using typegraphql
For example, this is what I'm looking to do:

// SomeService

@GQL.Resolver()
export class SomeResolver {
    @GQL.Authorized<AccessRules>({ self: 'SomeSpecialPermission', admin: true }) // I know I'll have to switch to Shield middleware instead
    @GQL.Mutation((_returns) => Boolean)
    async someCommand(): Promise<boolean> {
        // ...
    }
}

... while having the check either or not the access token grants SomeSpecialPermission to be done right from the gateway.

Do you advise something else?

[quant-daddy]

Also, I don't want these services to have to perform a call to the auth service on each request, but instead rely on accesses granted on the access token that I verified upfront.

I'm currently solving a similar problem. I have multiple services that need to know the membership of a user in some organization. I have an organization service and other services make a call to the organization service (service to service communication outside of federation). I do not think it is a problem to make this call because these calls should be cheap inside the same datacenter. The reason why I don't use this logic at the gateway is because what if I need to handle certain authorization error differently in a service (may be return an error message object as a part of the schema). Also what if the gateway cannot make a call to the authorization service because it is down: then you have to put that error handling logic inside the gateway which leads to leaking business logic at the gateway layer. What do you think?

[jgburet]

Well, I assumed that my auth service is the one responsible to persist my users & organizations and identify the relationship between each other.
And since I chose to have the gateway to auth every request, I packed the auth service inside it as Local service 🤔
So there's no call between the gateway and the auth service, as they are one.

what if I need to handle certain authorization error differently in a service (may be return an error message object as a part of the schema).

I think in this case the error you are returning would correspond to a 400, not a 403 🤔
The auth layer can't do anything about it

Also what if the gateway cannot make a call to the authorization service because it is down: then you have to put that error handling logic inside the gateway which leads to leaking business logic at the gateway layer.

Well, sort of. However I find that the way TypeGraphQL handles authorization is neatly decoupled. I only have to provide an authChecker function, which only has to check for what's inside the access token and the required permission. The rest is transparent.

As a side note, I find this interesting: apollographql/apollo-feature-requests#145

centralized logic in the gateway for functionality like unified authorization

[quant-daddy]

I see you case. I think it probably makes sense in your case. If i understand it correctly, you are intercepting each request, parsing the graph nodes it needs access to and attaching the authorization info required for all these nodes. In a simple case where each node needs access to the same authorization, it should work well.

In my case I have kept the gateway free of all the business logic. I only parse the authorization header at the gateway level, extract the userId and pass along that info to all the downstream services. Each graph field or object is responsible for making authorization queries to the auth service (cached using dataloader for each request).

[sbilello]

It would be great if we are able to apply rate-limiting logic at the gateway level. I was looking to find a way to integrate this library. https://github.com/teamplanes/graphql-rate-limit

[fullStackDataSolutions]

It's not hard to apply rate limiting at the gateway level, but I'm having trouble getting GraphQL Shield to work at the Gateway Level. Has anyone gotten this working?

This repo show's how to do rate limiting and validation rules:
https://github.com/arbytez/boilerplate-nexus-prisma-apollo-graphql-express

[fullStackDataSolutions]

I also need to use Shield at the Gateway layer with Federation. Has anything been done on this? I can't get it to work.

[quant-daddy]

I personally would avoid doing that because Shield is a business logic layer and gateway should not contain too much business logic.

[fullStackDataSolutions]

In our case it makes sense.

We are a small team and want to control all auth from one layer, and have all rules together. We also want to stop anything that not authenticated or authorized before it goes down any further.

If we had a team working on each sub service it would not. However we are connection many services, and have no need for duplicate auth rules in each service. When we do expend we can easily move it out into subserves. As GraphQL Shield is very easy to set up.

[quant-daddy]

Fair enough. You could also use a library to share logic between the codes. We, at Gully, are using 7-8 microservices and it's a very small team (only me tbh). Our gateway has almost no logic so we almost never make any changes to it. We expose data to unauthenticated users to at a field level so it's best to decide that at the service level but in your case this might not be the case.
To prevent any unauthenticated access, an alternative could be to just send http error before hitting graphql api.

[fullStackDataSolutions]

I can see the benefits fo doing it that way.

I work in the Block chain industry and I think we want to just have a service that handles this. We could make a middleware service, but that is what GraphQL Shield is essentially.

So we wanted our gateway to federate, which honestly isn't too much, and reject before it gets to any sub service. This allows us to manage from one place, and easily see all rules at once.

[quant-daddy]

I see yeah I can see the benefits.