Agenda
- Demo of Cactus integration with Vault Transit Engine - Pritam Singh
Recording
Pritam's Demo:
What this demo shows:
- Create a manager role in Vault, get a password for the manager
- Use the manager's password to get a token
- Login with the manager's token
- Create a role of client1, get a password for client1
- Use client1's password to get a token
- Enroll and then register client1 with "adminpw"
- Register and enroll client2 with secret key
- Post transactions in Fabric to query and record emissions
- Store Ethereum public and private key in Vault
- Tokenize Fabric records on Ethereum (hardhat) using public and private keys stored in Vault
How Vault can externally be used to manage client's identities.
- This will allow orgs to opt for authentication of their own choice, which isn't possible in demo 1
- Will also allow support for both Vault-X.509 and Ws-X.509 identity support for the application.
Steps:
Command for starting a vault server (for development) : `docker run --rm --name vault -d --cap-add=IPC_LOCK -p 8200:8200 -e 'VAULT_DEV_ROOT_TOKEN_ID=tokenId' -e 'VAULT_DEV_LISTEN_ADDRESS=0.0.0.0:8200' vault:1.8.1`
Hyperledger is committed to creating a safe and welcoming community for all. For more information please visit the Hyperledger Code of Conduct. |
---|
Time:
- Monday, August 13, 2021 at 09 AM Pacific
- Add Climate Action and Accounting SIG calls to your calendar
Dial-In Information: [ZOOM]
You can join either from your computer or from your phone:
- From computer: https://zoom.us/j/6223336701?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09
- From phone: +1(855)880-1246 (toll free US number) or view International numbers
Meeting ID: 622 333 6701
17 Comments
Si Chen
Robin Klemens Kamlesh Nagware Bertrand WILLIAMSRIOUXPlease take a look at Pritam's video and post your comments.
Si Chen
Pritam SinghThanks for making this demo. It looks like you've made a lot of progress. I do have some questions:
Pritam Singh
1 . when using X509 , the private key and certificate will be stored together , in a certDatabase. In case of Vault-X.509 only certificate will be stored in certDatabse ,and private key inside vault transit key (which allow signing of fabric tx at vault itself ). This will be up to the organisation managing their `typescript_app` to allow which kind of identity. There is one environment variable field in .env file `LEDGER_FABRIC_IDENTITY_SUPPORT='default,vault'`, this takes comma separated list of identity type to be supported by the application. Once web-socket support is added cactus then this env variable can also take web-socket.
2. a . Storing of secrets , creation of key can be done with Vault UI, but by connecting vault server with typescript app, we will also be able to provide a authentication to the typescript_app . Vault UI has limitations of its own. (since UI is just a front end which make use of endpoint supported by vault server). correct me if I am wrong , don't this typescrip_app is going to be used with some kind of front end? if so then front end can simple connect with just the typescript_app.
2.a. Do you want me to take micro-service (wherein each service has its own responsibility) based approach. And if we did separate it out , then typescript_app will require talking to vault management service. And this might increase the complexity.
3 . In video you might have seen that when I registered the client1 with the fabric , server returned an error `saying client1 is already registered` that is why I created a new client2. And this the flow for registering a client
3.a , Manager calls : POST /im/identity , returns username and password for vault identity, basically this endpoint creates a identity for the client inside vault.
3.b Manager send the returned password to client, client will use this password to login into the app.
3.c Manager calls : POST /utilityemissionchannel/registerEnroll/register with enrollmentID same as above username of vault identity , returns fabric enrollmentSecret
3.d Manager send the returned enrollmentSecret to the client , client will use this to enroll itself with fabric ca.
3.e Client logged in, calls POST /utilityemissionchannel/registerEnroll/enroll with enrollmentSecret received from manager.
Si Chen
OK thanks Pritam Singh for these answers. A little bit more:
Pritam Singh
Thank You
Si Chen
OK that sounds good. Could you please make an updated video to show how to manage identity with vault, and then use vault tokens in the typescript app?
Bertrand WILLIAMSRIOUX
Pritam Singh thanks for this demo. Sorry I just saw it this morning.
I agree with point 2 if we plan on supporting multiple identity provider types within the typescript app. Key pairs/ passwords for each type are responsibility by external client, and identity provider configuration for typescript requires bare minimum:
I have posted a PR to include the WS-X.509 in cactus and adding this to the app. approval will take some time, but Peter offered to publish my branch on an alternative dist tag. Pritam Singhwe could use our own for now..
I'll put together a WS-X.509 demo with the CLI I built for next week, and then start implementing the actual browser extension.
Si Chen
Hi Pritam Singhthanks for showing the Vault demo.
How do we get a token from vault and then use it in signing Fabric? Was that already in your other demo, or are you working on that?
Pritam Singh
It was already working, at the end of the 2nd demo, I mentioned that after getting the token from vault. The token can be passed to the typescript for interacting with fabric.
Pritam Singh
client-tmpl.hclmanager.hcl
Robin Klemens
Pritam Singh thanks a lot for the two demos! It's great to see the progress you and Bertrand WILLIAMSRIOUX have made so far!
In terms of a real world application:
Pritam Singh
Si Chen
Pritam Singh
Is your second approach (demo 2) it is the external-vault-identity.mp4 demo?
So in this case, the user supplies the token. Vault is still used to store the user's identity and interact Fabric. So even if the user doesn't use Vault, Vault is part of the internal infrastructure for authenticating with Fabric and Cactus?
Similarly, Bertrand WILLIAMSRIOUX, is that how your web socket client is set up? It generates the token, but then it will still be stored internally in Vault to access Fabric?
Pritam Singh
Yes, signing of tx with vault is internal and cannot be bypassed, if we want to support signing of fabric tx with key stored on vault, without having to bring it to the `typescript_app` server to sign the tx.
Bertrand WILLIAMSRIOUX
Si Chen, yes I also use the same PluginKeychainVault (cactus plugin) setup as the certificate store. Other options could be offered. E.g., When using a WS-X.509 identity external client could store certificates themselves with their offline private key, and send it to the CA each time a signing session is started.
This would make sense if the organization prefers or needs it employees to carry their own digital identity (and private keys) registered with the CA, rather than hosting them centrally. tradeoffs for the organization, with more responsibility on the employee.
Si Chen
Bertrand WILLIAMSRIOUXbased on our call yesterday, you'll be separating the web socket server from the typescript server, so the user authentication server is running on its own.
Bertrand WILLIAMSRIOUX
Correct. fixing the current setup with the socket server running within the typescript app to authenticate and traffic WS.X509 clients. Could be what was causing the context connection error i reported yesterday). will also try and setup a prototype browser extension for the external client based on my simple CLI.