Webhooks Service Authentication/Authorization

[winklerj]

Description
We would like the ability to authenticate requests sent to the webhooks service. Currently there are 3 types of authentication we would expect to use (HMAC digest , OIH IAM Bearer token, OIH IAM Basic auth)

1. HMAC digest
   1. Support for both hex and base64 digest
   2. Need access to the request raw body to correctly generate the HMAC digest
   3. The comparison HMAC header name should be configurable per flow
2. OIH IAM Bearer token - This should be straightforward using the existing iamutils library to introspect the token
3. OIH IAM Basic auth - The iamutils login can be used for this

• Currently, HMAC digest type is our highest priority.
• The authentication type used by the webhooks service should be configured per flow
• You should be able to configure multiple types of authentication, which when it fails tries the next type configured
• Unauthenticated requests should still be supported if no authentication is configured for the flow
• Secrets need to be supported from the secret service to provide the private key. We need to be able to use existing secret types since the private key is also used to access an API. For example we are using the API_KEY type. If there is an HMAC specific type we would have to find a way to duplicate the secret.
• Secrets should be configured per flow and would be separate from credentials_id on a component step
• Best practice on HMAC verification is that it is done before returning a response before any processing is done

Solution Proposal

• I envision the webhooks service providing a list of predefined authentication types and a flow configuration providing the type(s) used for a particular flow. The flow configuration would contain an ordered array of authentication types and any configuration needed for that type. For example HMAC needs a private key from the secret service and the comparison HMAC header name. I had started down this path before running into the complexity of maintaining a secret ID per flow. Here is example code of supporting multiple types overriding the authorize function: https://github.com/openintegrationhub/openintegrationhub/compare/master...blendededge:feature/webhook-authentication?expand=1
• From previous discussions I understand that it may make sense to do the HMAC verification in the secret service. This would eliminate the need to provide the webhooks service access to raw secrets. I assume the webhooks service would provide the secretId from the flow since it already listens to flow.started and flow.stopped.

Other Approaches Evaluated for HMAC

• Code component verification - there isn't access to the request raw body and you aren't able to validate before returning a response
• Performing HMAC verification in webhooks service - This approach would be viable, but the webhooks service would need access to the raw secrets. Secret ID's would still come from the flow configuration
• Creating a custom webhooks service implementation - this isn't very scalable/sustainable approach to write code each time or maintain a fork of the service
• Perform HMAC verification in iam service - This would create a dependency to the secret service which doesn't currently exist. It does fit that the other types of authentication are performed in this service though.

[heggert]

I tend to the second solution proposed which places HMAC auth functionality into secret service. It seems reasonable to have one service dedicated to cryptographic issues.

I assume the webhooks service would provide the secretId from the flow since it already listens to flow.started and flow.stopped

It could be useful to add a flowId as a property to an HMAC secret instead. This way the webhook service just has to pass a flowId to trigger HMAC verification.

[weberjm]

@heggert,

It could be useful to add a flowId as a property to an HMAC secret instead.

Since HMAC is generally performed at a tenant/client level per service, this might result in lots of duplicate secrets. For instance, a company that wants to do a variety of flows based on Shopify webhooks would not want to have to store their Shopify shared HMAC key X number of times.

[heggert]

Then it makes perfect sense to store a secretId within a flow.

Therefore we need to extend flow models in at least flow repository and webhooks service.