Work with the platform to pass API keys to the Hydrocron API

[nikki-t]

In order to completely implement API keys in #186, we need to ensure that the user request API key is passed through our cloud infrastructure to our API endpoint. We will need to work with the platform to determine the best way to do this.

[nikki-t]

Created ticket: NASD-4324

[nikki-t]

Platform uses the x-api-key header as an authentication mechanism in their architecture. They are looking into solutions but did ask if we could use a different header to pass in the "trusted partner" or heavy user API key.

@frankinspace , @torimcd , @cassienickles - What do you think of asking our users to pass in an API key under a different header?

[frankinspace]

Would it be possible for the end-user to still provide x-api-key but at the platform API gateway they move it into something like x-api-key-passthrough header which is sent to the tenant API?

Just because x-api-key is the published "standard" so if we expose something else to the end-user it puts us in the place of needing to explain more than we might otherwise need to.

[nikki-t]

@frankinspace - That is a great idea. I also though it might be confusing to end users to have to use a different header to send an API key in their request. Let me update the NASD ticket and see if this is a possibility.

[nikki-t]

After talking with platform it might be easier to have our heavy users pass in a custom header (x-hydrocron-key) with a value of the "trusted partner" key.

I have confirmed that the header is passed to the Lambda authorizer and a truster partner IAM policy is returned. This counts against the trusted partner usage plan. I also confirmed that once the usage plan quota has been hit the API stops returning responses (an error message is returned).

I think this is the best way forward which will allow us to implement two API keys in the short term and explore the integration of EDL authentication in the long term.

[nikki-t]

Closing issue as we have found a solution and opened #189 to track future need and requirements for EDL authentication.