Open TsvetanG opened 7 months ago
@TsvetanG thanks for the proposal, so what i think we could do is make the wallet more plug-able/modular. we could make a spec that a wallet would need to implement, and a user could configure their console to use 1 of many wallets, which could include hashicorp. the actual wallet code would sit in it's own repository, and it would be pulled into a console build when we bundle the fontend js.
i like the idea of this plug-able wallet solution, because ALL users don't have to download code and get maintenance updates from every different wallet implementation, when they are only using 1 particular kind.
so next steps would be to define the wallet api spec, and make some stubs to bring in other wallets during our esbuild process
Yes, we are working on the technical details and a plan. Our existing impl is not using modules so we need to do a small re-work.
@dshuffma-ibm Do you think we should be adding the Wallet vault implementation inside the fabric operations console git repo or we should use a dedicated repository?
@TsvetanG a dedicated repository
Here are the technical details. In a nutshell the idea is to change the Fabric Operations Console front-end and backend so that it can support other identity storage (Hashicorp Vault). The following changes may achieve that:
Change in Fabric Operations Console front-end The current wallet is implemented in the front-end and uses the browser storage. Hashicorp Vault based wallet impl will be implemented in the backend. Hence the front-end should be able to use backend wallet API to perform the identity(wallet) related operations. The abstraction of the wallet impl will happen in the backend using modules (see further below). In order to keep the current browser based wallet impl working a new class IdentityStorageFactory will be introduced. The IdentityStorageFactory (based on a configuration) will either use the exisitng browser storage impl or call the wallet backend APIs. The new factory class will be used by the existing IdentityApi class.
Implementation of Wallet REST API on the backend of Fabric Operations Console Implement a new wallet API that will handle the requests from the front-end (in case the front-end it is configured to use the backend based Wallet APIs). The new endpoint handlers will use an external module which provides a wallet storage client. The client will be abstract. The proper specific wallet module configuration can be provided during build/deployment.
Implementation of a module which provides the wallet storage The implementation of the wallet can exist and be maintained outside the console. This module will be a separate node_module and will be installed in the console as an external module.
@dshuffma-ibm : let us know what you think.
@ckpaliwal What are your thoughts?
@TsvetanG I'm weighing my options and will let you know.
@ckpaliwal Do you have any update?
Discussed with @TsvetanG today. Current thinking is to keep the implementation simple by having console repository natively support both the browser storage and Hashicorp vault storage, with a simple configuration that determines which will be used.
Currently, the fabric operation console wallet implementation uses the local browser storage to store the user identities (cert and private key). The console user must download those identities locally to persist them. This can be a cumbersome process that requires additional steps to keep the downloaded data secure. Hashicrop Vault can be used to persist automatically the user identities and keep the data secure without the need to download and manage locally. The fabric operations console wallet can be extended to support Hashicorp Vault as a secure store of the user identities. The idea is to abstract the existing wallet implementation and introduce a new Hashicorp Vault based wallet. Furthermore, a configuration can be enabled to control what wallet impl to use based on the specific deployment needs. That way the console would support the current wallet impl and the new Hashicrop Vault based impl. My team at Senofi is willing to contribute the implementation to the project.