couch replication auth plugin for IBM IAM with refresh

[rnewson]

Overview

Teach the CouchDB replicator how to acquire an access token from an apikey from IBM's IAM authentication service.

Note that an access token has an expiration (currently one hour but subject to change).

The plugin fetches a new token 5 minutes before the currently held one expires.

Testing recommendations

will be covered by tests

Related Issues or Pull Requests

N/A

Checklist

• This is my own work, I did not use AI, LLM's or similar technology
• Code is written and works correctly
• Changes are covered by tests
• Any new configurable parameters are documented in rel/overlay/etc/default.ini
• Documentation changes were made in the src/docs folder
• Documentation changes were backported (separated PR) to affected branches

[nickva]

This is a good start. But I think we can simplify it by using the same pattern as in https://github.com/apache/couchdb/blob/main/src/couch_replicator/src/couch_replicator_auth_session.erl with a gen_server, also use a first type synchronous token fetch in init.

For ibrowse requests don't use the default lb pool, replicator has it's own connection pool so we'd be using that instead (see https://github.com/apache/couchdb/blob/main/src/couch_replicator/src/couch_replicator_auth_session.erl).

Also wondering how easy it would be to have this not just IBM-specific. We have JWT token auth for our server side. Maybe this can be adapted somehow to work in a more generic way so it could work with Azure, AWS, other IAM-like auth systems. But, perhaps configuring it then would be tricky and keeping the plugins separate just to be able to configure the token url, then maybe separate plugins is just easier.

For config and naming maybe we should use some indication this for a replicator auth plugin not some generic IBM integration (thinking of "ibm_iam" section).

[nickva]

It might be better to do a first time synchronous token fetch on init. So when the job starts we'd know right away it has an invalid creds

[rnewson]

I had that earlier but it entailed duplication of the 'get token' ibrowse code (one synchronous, the other not). so I simplified to one version.

[nickva]

That's why I think we can just use a similar structure as the session plugin and always use the synchronous version.

[rnewson]

I do want to think of a more generic thing, and we should maybe make it possible for an auth plugin to have application like semantics (so they can start a supervision tree etc). in that version things become simpler. the auth plugin would launch a gen_server that makes a public ETS table. each replication job would insert the apikey when it starts and then fetch the token in update_headers as needed. the gen_server could refresh all the tokens slightly in advance of their expiration, handle retries on timeout or 500's, etc.