Agenda

  • Demo of Cactus integration with Vault Transit Engine - Pritam Singh

Recording

Pritam's Demo:

Sep_14_Peer_Programming_vault_identity.mp4

What this demo shows:

  1. Create a manager role in Vault, get a password for the manager
  2. Use the manager's password to get a token
  3. Login with the manager's token
  4. Create a role of client1, get a password for client1
  5. Use client1's password to get a token
  6. Enroll and then register client1 with "adminpw"
  7. Register and enroll client2 with secret key
  8. Post transactions in Fabric to query and record emissions
  9. Store Ethereum public and private key in Vault
  10. Tokenize Fabric records on Ethereum (hardhat) using public and private keys stored in Vault

external-vault-identity.mp4

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:


Dial-In Information:  [ZOOM]

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




  • No labels

17 Comments

  1. Si Chen

    Robin Klemens Kamlesh Nagware Bertrand WILLIAMSRIOUXPlease take a look at Pritam's video and post your comments.

  2. Si Chen

    Pritam SinghThanks for making this demo.  It looks like you've made a lot of progress.  I do have some questions:

    1.  What is the difference between X509 and Vault X509?  Do we need both of them in the typescript api?
    2. Are all the /im requests are for interacting with the vault server to create and update users, their passwords, and Ethereum secrets, etc.?
      1. Why do we need these?  Could these operations be done in Vault directly with the Vault's UI?
      2. If not, could these /im requests be separated into a "vault management" app?
    3. What is the right sequence for registering and enrolling a client for Fabric?  It seems that you enrolled, then registsered client1 using "adminpw" but registered, then enrolled client2 using a secret key.  

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

      1. Si Chen

        OK thanks Pritam Singh for these answers.  A little bit more:

        1.  It seems the Vault x-509 is better for security.  Do you agree?  If so why do we need the regular x509 if we support vault x509?
        2. Typically I don't see an application also having access to the security server's credentials like passwords.  For example, if you signed up to another website, a lot of them say "Sign in with Google", but then you sign in with Google which gives the website a token.  If you go to a website which prompts you for your Google password to sign you in, then that's probably a phishing attack.  So I don't think this is a good pattern.  Can we have the typescript app simply use a token which the user gets somewhere (from Vault UI or another UI)?
        3. If we do not support UI with Vault in the typescript, how would register and enroll work?

        1. Pritam Singh

          1. Yes Vault-X.509 is more secure and there is not point in keeping simple x509
          2. I got this point and its a valid one, So what I will do his , remove vault identity part from typescript_app , and keep simple so that identity can be managed by other providers/vault also.
          3. Will also add docs explaining how one can manage identity with vault.
          4. Will also integrate Bertrand WILLIAMSRIOUX  work into typescript_app , and `LEDGER_FABRIC_IDENTITY_SUPPORT` will support vault-x.509 and ws-x509.

          Thank You

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

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

            1. Vault: issue token to open session on the typescript app
            2. Web-socket: external client passes pubKey to typescript server and get back a sessionId to open the connection

            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.

          3. 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?

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

  3. Pritam Singh

    client-tmpl.hclmanager.hcl

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

    • What keys/tokens would the user need to store privately?
    • Would a separate authentication mechanism also be required? Could the solution be integrate in OpenID Connect or similar?
    • How to rotate keys/tokens? 
    • What happens in case a user loses their keys/tokens?
    • How to revoke keys/tokens stored in vault? In the EU there is right to be forgotten (GDPR).

    1. Pritam Singh

      • For the first approach (demo 1) wherein an entity is created for each client and user/pass based authorization is done. So, in this case client will have to store their username and password privately. And In second approach (demo 2), typescript_app asks for vault token only. It doesn't understand anything about vault entity (JUST VAULT TOKEN).So, in this case client will have to keep their vault token privately.
      • For the First approach (demo 1) not required, it uses vault to do all the authorization and authentication. And it cannot be integrated to use any other auth method. But for second approach (demo 2 ), a authentication is required and OpenID can be integrated to it. POINT TO BE NOTED HERE IS : we can use any auth, but at the end, vault token is required to interact with fabric via cactus.
      • Vault support rotation keys and token. 
      • Each entity in vault are tagged with some ACL policies. In second demo, I showed that a client can only manage his/her key (example client1 cannot manage key of client2).  Similarly in an origination, a client (say admin) can have ACL policy to change password of other client. So, basically  admin can help clients to recover their token/password.
      • Revoking a vault key means admin deleting that client or removing the ACL policy which was allowing the client to sign message.

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

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

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

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

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