Graphql - Support for security headers from OpenAPI spec using autogeneration

[nmnellis]

Gloo Edge Product

Enterprise

Gloo Edge Version

v1.16

Is your feature request related to a problem? Please describe.

Today we create all our graphql schemas using the autogenerated feature to convert OpenAPI spec to graphql endpoints but it does not support the authorization headers defined in the security spec of OpenAPI.

We need support for Authorization and X-App-Client-ID headers.

Here is a sample spec

{
  "openapi": "3.0.1",
  "info": {
    "title": "Entity Data Service",
    "version": "1.0.0"
  },
  "security": [
    {
      "bearer": []
    },
    {
      "clientId": []
    }
  ],
  "components": {
    "securitySchemes": {
      "clientId": {
        "type": "apiKey",
        "description": "Paste the X-App-Client-Id from your welcome mail into the box below and click 'Authorize'",
        "name": "X-App-Client-Id",
        "in": "header"
      },
      "bearer": {
        "type": "http",
        "description": "Retrieve bearer token by clicking on the 'Get Token' tab in the main page. Enter your username and password as supplied in your welcome mail. Copy the returned token and paste it into the box below and click 'Authorize' to use the 'Try it out' capability.",
        "scheme": "bearer",
        "bearerFormat": "JWT"
      }
    }
  }
}

Describe the solution you'd like

No response

Describe alternatives you've considered

I can manually edit the schema after the fact but anytime its regenerated these headers will disappear.

Additional Context

No response

[DuncanDoyle]

A "scripted" workaround would be to use yq against the GraphQLApi CR, like so:

#!/bin/sh

####################################################################################################
#
# Patch the GraphQLAPI CR and add standard headers to all operations.
#
####################################################################################################

INPUT_FILE=mocks-graphql-api-source.yaml

yq -i '.spec.executableSchema.executor.local.resolutions["*"].restResolver.request.headers += {"Authorization": "'{\$headers.Authorization}'","X-app-client-Id": "'{\$headers.X-app-client-Id}'"}' $INPUT_FILE

If we consider auto-generating the header passing, we should consider making that an opt-in, as it could be that the headers that the resolver should pass to the backend services should not come from the headers on the GraphQL request at all, or that headers have different names and/or formats across different services used in a larger graph. Both those use-cases would not work with auto-generated header passing ... in fact, it might actually be a security risk to automatically do that.