Agenda
- Review Client side security with Web Socket and X509 certificates - Bertrand WILLIAMSRIOUX
- Review security signing with Vault transit engine - Pritam Singh
- Welcome new mentee Harsh Sharma
Update on the web-socket based identity provider for fabric. First step in implementing a simple CLI for an external client application that interacts with the web-socket server hosted by the fabric identity provider. Pritam Singh Kamlesh Nagware Si Chen Robin Klemens
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 30, 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
6 Comments
Bertrand WILLIAMSRIOUX
Si Chen Started building a CLI to illustrate the web-socket identity provider interaction
See the video posted above
Si Chen
Bertrand WILLIAMSRIOUXNice demo.
Can it be set up so that the web socket server is not in the test but available to receive web socket requests, like the typescript server? It could be but doesn't have to be inside Cactus.
The admin public key should be configured in the server, but then all the other operations should be done without hardcoding public addresses on the server. For example, we should be able to
This should be the same as the typescript which currently accepts the requests with a Fabric userid. In fact we could even replace the typescript with the web socket if everybody agrees this is the right approach.
Bertrand WILLIAMSRIOUX
First, you're correct the pub key will not be stored on the server, this was a quick fix as the test I was running is missing the following logic:
The admin pub key could also be broadcast in this way for admin operations, but for security storing it locally might make more sense.
Second, yes I will working on a live fabric server to showcase the process described above - this was a quick demo.
Regarding the utility emissions channel not sure it makes sense to build in the web socket identity provider without using the cactus integrator after the changes made so far. Pritam Singhyour thoughts on this?
Pritam, we should still wok on publishing our fabric identity solutions as a separate package independent of Cactus for reference and ease of use. That said, we still need the powerful cross ledger features provided by cactus for the full carbon accounting project.
Pritam Singh
Bertrand WILLIAMSRIOUX Nice demo
Have some points to make
Thought on providing this a separate pkg : Adding to an existing connector was a quick job. And also we ware already using the cactus for eth and HL Fabric , so it was most viable approach . But that being said I think we should create a separate project/pkg which will support Identity type = Default , Vault , gRPC , WebSocket (transport) . And one extension which can use WS or gRPC to connect with the server. Also we could also provide wrapper sdk for various programming languages (starting with nodejs) (for which fabric sdk is available). But I don't think we could include these task in our mentorship.
Bertrand WILLIAMSRIOUX
Pritam Singh
On the last points, let me see if I understand. The server tells the client it is waiting for a web socket connection and a signature to authenticate it:
I built a method for the server's web-socket client to verify incoming signatures. just need to set up the incoming connection authentication described above.
Thanks for your comments. I'll work on a puml digram when i find the time, and we can debate best approach.
Si Chen
Bertrand WILLIAMSRIOUX Pritam SinghThanks for your feedback. A few thoughts: