You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Eryph clients issue commands that run on backend components. Therefore, if the command needs to access a resource on the genepool, the authentication to the genepool must be done on the backend and not by the client.
This proposal describes a concept for providing these credentials for eryph-zero, server and in multi-tenant scenarios:
Identity Module API Key Management
The API module should be extended to allow API keys for genepools to be associated with clients and, if added later, user identities.
A client could be associated with an API key on the genepool (cross-organization auth would be implemented by associating orgs on the genepool). Multiple identities may share the same API key.
The identity module will issue a claim containing the API key's id.
Controller API Key Lookup
The controller sagas that prepare access to the genepools must be extended to add a step that requests the API key by id from the identity module. If available, the API key is appended to the genepool access commands.
Identity Module API Key Command Handler
The identity module must be added to the message bus and implements a command handler that looks up the credentials of the genepool api key to provide them to the controller module.
Further considerations
Local Genepool
The local genepool currently assumes that all users have access to the cached genesets. With this change, this will no longer be the case. The local genepool needs to verify access to the geneset even if the geneset is available locally. However, this must also work in offline scenarios. Therefore, genepool orgs to which an API key allows access should also be cached.
Eryph clients issue commands that run on backend components. Therefore, if the command needs to access a resource on the genepool, the authentication to the genepool must be done on the backend and not by the client.
This proposal describes a concept for providing these credentials for eryph-zero, server and in multi-tenant scenarios:
Identity Module API Key Management
The API module should be extended to allow API keys for genepools to be associated with clients and, if added later, user identities.
A client could be associated with an API key on the genepool (cross-organization auth would be implemented by associating orgs on the genepool). Multiple identities may share the same API key.
The identity module will issue a claim containing the API key's id.
Controller API Key Lookup
The controller sagas that prepare access to the genepools must be extended to add a step that requests the API key by id from the identity module. If available, the API key is appended to the genepool access commands.
Identity Module API Key Command Handler
The identity module must be added to the message bus and implements a command handler that looks up the credentials of the genepool api key to provide them to the controller module.
Further considerations
Local Genepool
The local genepool currently assumes that all users have access to the cached genesets. With this change, this will no longer be the case. The local genepool needs to verify access to the geneset even if the geneset is available locally. However, this must also work in offline scenarios. Therefore, genepool orgs to which an API key allows access should also be cached.
AB#593
The text was updated successfully, but these errors were encountered: