Low code CDK: Conditional authenticator

[flash1293]

What area the feature impact?

None

Revelant Information

It's a common scenario to allow the user of a connector to choose from multiple possible authentication methods. Currently this is not reflected in the low code CDK.

By introducing a new component ConditionalAuthenticator, this can be made a properly supported feature:

type: ConditionalAuthenticator
authenticators:
  - condition: "{{ config.auth.type is "username_password" }}"
    authenticator:
      # ... 
  - condition: "{{ config.auth.type is "token" }}"
    authenticator:
      type: ApiKeyAuthenticator
      header: "X-Metabase-Session"
      api_token: "{{ config.auth.session_token }}"

Once this is supported, the existing LegacySessionTokenAuthenticator can be removed as it will be possible to re-create it using the conditional authenticator.

[maxi297]

+1 on Slack by Markos from Hackathon

[girarda]

Alternative interface that uses a selector instead of string interpolation:

type: OneOfAuthenticator
config_path:
 - auth
 - type
authenticators:
  token:
    type: ApiKeyAuthenticator
    header: "X-Metabase-Session"
    api_token: "{{ config.auth.session_token }}"
  username_password:
   type:
   # ...

I don't feel strongly about the use of a mapping vs array of authenticators, but avoiding string interpolation makes the interface simpler

Acceptance criteria

• low-code connector developers can create connectors that support multiple types of authentication mechanism without custom components
• source-retently does not use a custom authenticator
• Fine to swap with facebook-pages, zoom, or square if source-retently is not in a healthy state when this issue is implemented
• A follow up issue is created to add this functionality to the connector builder

[girarda]

grooming notes:

• if there are no authenticators that meet the condition: the source should raise an exception
• config_path is not an ideal field name. we should decide on something more descriptive. Idea: authenticator_selection_path

[keu]

the PR for retently #33536

[keu]

@girarda I've just realized that for affected connectors this is a backward incompatible change.
I.e. user has to specify new field in the connector config - auth.type
What is our strategy in such cases?

Migrate it one by one with boosting major version?