Summary

  • Reviewed using Web Socket and Vault authentication for Hyperledger Fabric


Time:


Dial-In Information:  [ZOOM]

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


Hyperledger is committed to creating a safe and welcoming

community for all. For more information

please visit the Hyperledger Code of Conduct.



  • No labels

14 Comments

  1. Si Chen

    Pritam Singh Bertrand WILLIAMSRIOUXPlease take a look at https://github.com/hyperledger-labs/blockchain-carbon-accounting/pull/336 and see if the documentation changes are correct.

    Also please confirm – are both Vault and Web socket authentication going through Cactus, which is now part of the Fabric application?

    1. Bertrand WILLIAMSRIOUX

      Si ChenYes both Vault and Web socket authentication go through cactus. Cactus PR 1333 for FabricSigningCredentialType.WsX509 was closed last week, and I will update the cactus package reference in our types ript (previously using a canary release while pr was reviewed by cactus maintainers)

      1. Si Chen

        OK please send a PR with this change.

  2. Si Chen

    Pritam SinghI'm still thinking about how a client application would use the Vault authentication with Fabric.  I think it must have a token authentication process similar to OAuth:

    1. Endpoint for client to check if its token is still valid – Does the "Authorize" on the Swagger Rest Api do that?
    2. If not, an Authenticate request which forwards the user to a page in the Vault application with a parameter for redirect URL
    3. The page is part of the Vault application.  It will say "An application from ${source domain}" is requesting a token for you and prompt the user to login with username and password.  Then if successful it will redirect the user back to the redirect URL with a parameter for vault token
    4. The client application picks up the vault token in the url and keeps it in its session.  It checks it like in step 1 and uses it for subsequent requests to the server. 
    5. There should be an endpoint in Vault Rest Api to invalidate the token.  The client application can then logout the user by invalidating the token and clearing it from its session.


    1. Pritam Singh

      1. Yes, it uses token based authentication. `POST api/token` endpoint of vault-identity server, lets you create a token by taking username & password of the user. 
      2. The steps 2-4 is already there in vault -identity server
      3. there is an endpoint : `DELETE api/token` which will invalidate a given token.

      1. Si Chen

        Pritam SinghOK Please implement this workflow as part of https://github.com/hyperledger-labs/blockchain-carbon-accounting/issues/313

  3. Si Chen

    Bertrand WILLIAMSRIOUXHow would a client application, let's say a mobile app or webap, us ws-wallet to connect to ws-identity on the server?  Should it offer a REST API?   Should it offer a page to prompt the user for authentication?

  4. Bertrand WILLIAMSRIOUX

    Si Chen The mobile app would include a package/code equivalent to ws-wallet (if not built in javascript/trypescript).

    The way it is setup the client app does not need to offer a rest API. 

    Our fabric typescript app provides a REST API for the "/identity/webSocket" path detailed in src/static/openapi.json. As alluded to in the demo the client app would:

    1. call this path to issue a session ticket (linked to the fabric app's IP). 
    2. authenticate (sign) the session ticket ...
    3. use sessionId/signature to connect a web-socket client pair (one for the client app wallet and one on the ws-identity server)

    Step 1/2 above is the authentication page - i.e., client app asks if user wants to sign sessionId with fabric app

    1. Si Chen

      Bertrand WILLIAMSRIOUXHow would the client mobile app ask the user and get a response from the user about whether to authenticate the Fabric transaction?  Wouldn't that require some actions to happen in the wallet, which should be outside of the client mobile app-- the way Metamask is outside of an Ethereum dApp?

  5. Bertrand WILLIAMSRIOUX

    Si Chen Sorry I misunderstood the question. A signature authentication protocol should be added to the user’s wallet. Recall, a given fabric transaction can take up to 5 signatures, requiring the user’s approval for each would be overkill. The wallet can be designed to request approval only for 'sensitive' signature requests, e.g., final commit (query) when writing to (reading from) fabric.

    This requires a slight modification to the messaging protocol of ws-identity so the user's wallet can interpret message digests and identify 'sensitive' requests. I can add this to ws-identity this week.

    For now the simple ws-wallet I built will sign any request sent over the open ws-identity server connection using the WebSocketKey (signed by the user). This is fine assuming the user keeps the key secure during an active session (of one or multiple transactions) ... additional approvals would improve security. 

    1. Si Chen

      Bertrand WILLIAMSRIOUXDo you think for now we should regard the ws-wallet as a wallet to be fully bundled inside of the client application, rather than an independent wallet like Metamask?  Then the client would handle all authentications to use the ws-wallet and use the ws-wallet to call Fabric?

      If so what languages or frameworks could ws-wallet be integrated into?

      For example, how would we use it in a python application like https://github.com/opentaps/opentaps_seas or in a mobile app, either HTML5 or native iOS or Android?

      1. Bertrand WILLIAMSRIOUX

        Si Chen Yes we should consider ws-wallet as bundled into a client application. this could be an independent client browser extension used by a browser web-app (like the metamask wallet), or built into a dedicated desktop or mobile app. 

        ws-wallet would be expressed as a client side protocol for using WS-X.509 identities in Fabric, with SDKs in different languages:




        1. Si Chen

          Bertrand WILLIAMSRIOUXCould you implement a single REST request for the ws-wallet which will pass a sessionId and URL, and then the ws-wallet will return the signature and session key.  Then a client application can use them to interact with Fabric?

          Also, we need to keep the private key encrypted while it is stored on the file system.

          So I think we should do the following:

          1.  when we-wallet generates a new key, it should prompt the user for a passphrase
          2. the key is stored encrypted with the passphrase
          3. when ws-wallet is asked to authenticate a session, it should ask the user for the pass phrase and then use it to decrypt and send back the key.
          4. The Ws-wallet could wait for the user to enter the pass phrase in the command line when it gets the request from the rest api and then respond when the user agrees.

          This wall serve as a basic demo of a client application using ws-wallet.

          I've created issues 342 and 343 on github for this.

          1. Bertrand WILLIAMSRIOUX

            Si Chen check PR 344 with REST endpoint for ws-wallet connection to ws-identity passing through the fabric app.

            I'll work adding the passphrase for issue 342 this weekend