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


zoom_0.mp4

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

web-socket identity provider for farbic.mp4



Hyperledger is committed to creating a safe and welcoming

community for all. For more information

please visit the Hyperledger Code of Conduct.


Time:


Dial-In Information:  [ZOOM]

You can join either from your computer or from your phone:




  • No labels

6 Comments

  1. Bertrand WILLIAMSRIOUX

    Si Chen Started building a CLI to illustrate the web-socket identity provider interaction

    See the video posted above

    1. 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

      • enroll user as the admin user by providing the user's public key
      • perform operations as the user by providing the user's public key 

      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.

  2. 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:

    1. Form requests sent by the user to the server include its active public key
    2. The fabric server responds by setting up a new web socket identity provider/server.
    3. It waits for an incoming web socket connection from the client with the matching pub key 
    4. It can proceed with requesting signatures to proceed with the form request (sign CSR, enroll user, send transaction)

    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.



  3. Pritam Singh

    Bertrand WILLIAMSRIOUX Nice demo

    Have some points to make 

    1. Public key of the client enrolled with a org's ca will be stored in some cert database which will be accessible to typescript_app. Cert of each client will be stored with their entitlementID  (are unique for a org's ca )as `key` . So now in each request made by a client , he/she will have to give the username and typescript_app will fetched the public key from the cert database. 
    2. `It waits for an incoming web socket connection from the client with the matching pub key` This is a good security feature but is it practically  feasible in a actually server  ?
    3. I think my first point can solve this waiting of connection from a known public key. Because now client having their certificate store with server can only open a connection.
    4. To add more security I would say , when a client open a connection he/she will have to give two field 1.  entitlementID 2. signature proving the ownership of the private key corresponding to public key stored inside cert database with provided `entitlementID` as label.

    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.  

    1. Bertrand WILLIAMSRIOUX

      Pritam Singh

      1. Yes, you're right. Once registered and enrolled the external client provides a unique user name to fetch the identity from the cert-store. In the getUserContext method, I am extracting the pub key from the cert, assuming it had already been retrieved. The manually inserted pubkey is only used in the first enrolment stage.
      2. The server has to wait for an incoming connection at some point. however it can prompt the user to connect before form requests can be submitted. Whatever configuration is used, security depends on how signature requests are managed between the server/client. E.g., require the client to approve each signature like in Metamask, or a pre-approved sequence of signatures before the connection is closed... still thinking about this.

      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:

      1. The server broadcasts a unique/random web socket session id for the clients public key and expects a signature of it in the incoming web socket connection.  
      2. It verifies the signature to keep the web socket connection alive for the client. 
      3. The server pulls the identity file (for enrolled users only) to initialize a user for the identity provider. The identity could also be sent by the client, as long as the signature is authentic.

      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.

      1. Si Chen

        Bertrand WILLIAMSRIOUX Pritam SinghThanks for your feedback.  A few thoughts:

        1. It's nice to have a username associated with a public key, but then you'd have to be able to support several operations in addition to just enrolling a public key as a user, such as add an additional public key to an enrolled user and remove a public key from a user.  Is it worth doing all this right now?
        2. Is the web-socket connection separate from the regular typescript API requests, or will it the typescript API requests be passed in web socket?
        3. I still think there needs to be a way to access Fabric requests without going through the Cactus plugin.  Cactus is great but not everybody needs it.