Custom authenticator logic

[chris-smith-zocdoc]

Is your feature request related to a problem? Please describe.
I'd like to add custom authentication logic into our build of the collector, similar to how custom processors may be registered

The current auth module doesn't appear to support this at the moment.
https://github.com/open-telemetry/opentelemetry-collector/tree/master/config/configauth

Describe the solution you'd like
The simplest solution might be to write any custom authentication logic as a processor. I don't believe this is possible currently because the original request information (HTTP Headers) isn't accessible by the processors. If the headers were placed into the Context, then this would be the easiest path forward.

Describe alternatives you've considered
A more complicated alternative would allow custom builds of the collector to register new authentication modules that the existing receivers may use.

cc @jpkrohling

[jpkrohling]

The original design for the auth was indeed to be a processor, but we switched that to be something that people add to the receivers, so that unauthorized requests wouldn't cause data to flow down the pipeline.

What I think we could do is to expose a registry. Your logic would be an extension that would register itself. Do you think that would work for your case?

[chris-smith-zocdoc]

Yeah that should work

[jpkrohling]

@chris-smith-zocdoc even though this is assigned to me, would you like to give this a try? I'll probably not have time to work on this for the next few weeks, which means that it'll probably be done only next year.

[chris-smith-zocdoc]

@christopher-taormina-zocdoc from my team should be able to work on this. @jpkrohling can you provide links to the important sections of code we'll need to understand/modify. Any advice you have for structuring the prs for easier review+merge would also be appreciated.

[jpkrohling]

Sure. I'm out most of this week, so, here's just a short overview:

1. configauth would get a registry, AuthenticatorRegistry (map[string]Authenticator)
2. move the oidc authenticator to an extension, register it with the registry
3. configauth would only have a property, authenticator, with a value that should match the key from the registry
4. the authenticator is configured via the extension's config (the whole OIDC part from the configauth moves there)

For backwards compatibility, we might want to read the OIDC config on the last step and configure a new OIDC extension with it, if possible at all.

The whole configauth code is here: https://github.com/open-telemetry/opentelemetry-collector/blob/6b67312d590ca00542167c535794b1442558d422/config/configauth/

[christopher-taormina-zocdoc]

@jpkrohling In moving oidc to an extension, are we expecting the configuration to have the authenticator specified in both the receiver config and in the service config?

For example

receivers:
  somereceiver:
    grpc:
      authenticator: oidc

extensions:
  oidc:
    ...

service:
  exetnsions: [oidc]
  pipeline:
    traces/toSomewhere:
      recievers: [somereceiver]
      ...

[jpkrohling]

Yes, I believe so. The reason is that receivers might potentially have different authenticators.

[christopher-taormina-zocdoc]

Cool. To me, it seems a little cumbersome to have to also specify the auth extension in the service extensions as this would be very easy thing to overlook, tho I can't think.of a way to get around that without having a new component for auth layers.

[jpkrohling]

I can't think.of a way to get around that without having a new component for auth layers.

I think there's really no other way, at least for the moment.