Api key support

[loneil]

Add plugin support for getting a token for a tenant via the API Key.

Modify Tenant UI login page to support both Wallet creds and API key options.

One caveat/discussion point for this is that there exists 2 token endpoints

• {wallet_id}/token
• {tenant_id}/token

Current token fetching via the tenant UI is the wallet_id one (a calling LOB could theoretically use either but we've generally gone with wallet_id).
What I modified here is the tenant_id endpoint, as that's the one that's actually in the Innkeeper plugin.
So what a caller would do is use the Tenant ID and API Key(s). Which is not totally ideal as it's a different ID than if they use the wallet ID.
But then I also kind of like it this way as it's a completely separate deliverable set of creds to a caller that don't associate with the wallet itself. It's tenant based, not wallet based... Probably some discussion to be had here. I think we should modify the {wallet_id}/token endpoint to support this as well, and fix a separate issue I've discussed with Sherman too around securing the call.

[github-actions]

Deployment	Resource	Location
Traction
	Tenant UI	https://pr-768-tenant-ui-dev.apps.silver.devops.gov.bc.ca
	Innkeeper UI	https://pr-768-tenant-ui-dev.apps.silver.devops.gov.bc.ca/innkeeper
Aca-Py
	Admin Swagger	https://pr-768-traction-acapy-admin-dev.apps.silver.devops.gov.bc.ca/api/doc
	Tenant Proxy Swagger	https://pr-768-traction-tenant-proxy-dev.apps.silver.devops.gov.bc.ca/api/doc

Deployment URLs ready for review.

[usingtechnology]

Just a comment. The tenant_id based token was added in traction because we cannot seed a wallet_id. So for the innkeeper tenant/wallet, we needed a way to fetch tokens with a known id. And wallet_id is not known until it is created. So that is really there for the innkeeper tenant itself to bootstrap.

[loneil]

Just a comment. The tenant_id based token was added in traction because we cannot seed a wallet_id. So for the innkeeper tenant/wallet, we needed a way to fetch tokens with a known id. And wallet_id is not known until it is created. So that is really there for the innkeeper tenant itself to bootstrap.

Thanks @usingtechnology .
It's a convenient endpoint to encapsulate token fetching with an API Key in the Innkeeper plugin. As well allows us to have API access use Tenant based values rather than wallet (although someone with an API Key token can get the wallet ID so not a security thing or anything).
So leaning towards keeping API access through that endpoint only rather than extending to wallet_id/token as well.

Any concerns you can think of with using {tenant_id}/token given it's original intent? Or think it's all good repurpose for this as well?

[usingtechnology]

No, no real issues except for possible confusion? May want to think about not allowing token fetch by wallet_id? So using traction is tenant based only. Or just leave it and document the API Key is only used with the tenant_id endpoint. And if you are guiding developers to using that tenant_id endpoint, then you should update the tenant-ui to use it. It's the best example of using traction apis.

[usingtechnology]

I didn't run it, but the code looks good to me!

[esune]

No, no real issues except for possible confusion? May want to think about not allowing token fetch by wallet_id? So using traction is tenant based only. Or just leave it and document the API Key is only used with the tenant_id endpoint. And if you are guiding developers to using that tenant_id endpoint, then you should update the tenant-ui to use it. It's the best example of using traction apis.

I think we could leave them both, but as suggested by @usingtechnology pivot teh Tenant Ui to use the tenant id and api-key where possible, as it provides a good abstraction layer for our users (something similar might be implemented for OIDC-based access btw). We can leave the "native" wallet id/key endpoint for specific use-cases (if any) and for compatibility reasons. We can always decide to enforce stricter rules in the future if we decide to go the way of fully managed tenants (i.e.: the tenant will not necessarily need to know wallet id/key to access their APIs).

[loneil]

No, no real issues except for possible confusion? May want to think about not allowing token fetch by wallet_id? So using traction is tenant based only. Or just leave it and document the API Key is only used with the tenant_id endpoint. And if you are guiding developers to using that tenant_id endpoint, then you should update the tenant-ui to use it. It's the best example of using traction apis.

Yeah I like this idea too.