Multi-issuer environment: Session credentials dynamic using plugins - with fallback to old behavior

[jensens]

The session credentials file (IAM authentication file for the Google Service Account) was static. Thus we were not able to serve multiple clients within one usage of this library. For security reason one should use for each environment a different Service Account.

To get dynamic credential-data a new protocol CredentialProvider was introduced using the same plugin mechanism as already known from the image handler and pass data provider. Any integration now can provide such an provider and lookup a credential file by issuer_id.

If there is no provider configured, fall back to fetch credentials from settings.

Additional we provide a method to directly pass the credentials (as parsed dictionary) to the API methods (api.py). If passed in, provider an fallback are bypassed.

The session was refactored to reflect this. Since we use AuthorizedSession each issuer now gets its own session per thread. Integrators need to take care to not explode the number of sessions.

[jensens]

TODO:

• write test for plugin CredentialProvider mechanism and for .session.SessionManager._credentials_for_issuer
• check overage for more places to add tests if needed

[rnixx]

@zworkb @loechel please add your review

[rnixx]

There was an error in save_link which was not easy to fix. We use this package in an async environment and delegate the API calls to a thread executor to avoid blocking. Turns out, using the sync dynamic settings plugin, there is no clean way hooking back up to the async world to fetch the credentials (which is required in our case). To avoid ugly hacks, the API has been extended to accept the parsed credentials as dict. This makes the dynamic settings plugin obsolete for now, at least in our environment.

Next, the dynamic plugin looks up the credentials by issuer id, which is fine as long as the system is set up to use a dedicated service account for each issuer id. Technically, a service account can be used to create passes for multiple issuers. If we want to keep the dynamic settings plugin as is, we have to add a description about it's restrictions to the documentation. The second case described is provided by passing the credentials file to the API calls.

For our major issue, the lack of async support, the API must be extended by async versions of all API calls. The google auth package provides an experimental aiohttp based implementation, which is subordinate due to the lack of HTTP2 support. There exists a pull request with a httpx based implementation here googleapis/google-auth-library-python#1255 . A possible solution may be to integrate the code from the PR in this package, as it not seems that there is much progress on the issue. But this is out of scope for me right now.

[rnixx]

Close in favor of #58