Fusion doesn't work if both subgraphs and Fusion servers use authorisation about graphql-platform HOT 10 CLOSED

Its not a bug as we have not implemented any authorization on the fusion gateway. At the moment its not supported. With the current version authorization is supposed to be handled by the subgraph.

We have a feature for authorization on the backlog for version 13.8.

I am closing this issue as it is by design that the gateway has no authorization capabilities as of now.

This is expected:

I had header propagation configured and it works fine when subgraph has authorisation and fusion server does not.

from graphql-platform.

You need to configure header propagation

from graphql-platform.

https://thecodeblogger.com/2021/05/25/request-header-propagation-in-net-core-web-applications/

from graphql-platform.

I had header propagation configured and it works fine when subgraph has authorisation and fusion server does not. The problem is when the fusion server also has authorisation. In my repro steps no request is even sent to subgraphs and problems occur. The fusion server can't even be initialised because the ApplyPolicy enum type appears twice in the fusion graph (or at least that is how I understand it from the log).

from graphql-platform.

Thanks for reopening. I'm wondering if this should be marked as a bug rather than a question?
Can you give us a rough estimate of when we can expect a fix?
Thanks

from graphql-platform.

We are also not sure yet if there should be authorization in the gateway as this would duplicate logic that is already executed on the subgraphs. We are still discussing this topic internally. Join the fusion channel on slack as we are constantly posting the current roadmap there and giving hints as to how we implement certain aspects of the roadmap.

from graphql-platform.

slack.chillicream.com

from graphql-platform.

Thanks for the answer.
I think authorisation on the fusion server side would be beneficial. It would be nice to have a global common authentication and authorisation and not have to repeat it (or use it) on every subgraph/application. So the need is to have authentication/authorisation (at least the common part) on the gateway side and not on the subgraph side.

from graphql-platform.

Ps:
I'm writing from the perspective of a larger company that has a cloud platform and many products around it with a single point of access.

from graphql-platform.

@michaelstaib referring to your comment about Fusion and authorization, on Jul 30 you said authorization for fusion was on the backlog for 13.8. I see now that we've jumped from 13.7 to 14.0 preview. Does the preview have authorization? Also as far as contacting you via Slack, which you mention in your class as well as in this thread, my company does not allow slack in house so unfortunately ATM this is my best known way of communicating with you. Any better alternatives?

from graphql-platform.