0

I would like to create a custom loopback server to handle the hyperledger composer cards associated to the users.

In the scenario that I want to create there are different users which are able to execute transactions in the blockchain.

The user should be able to log in to web portal and submit the transaction.

This requires that the credentials of the web portal (username and password) are stored in a database, while the cards are in the file system of the server.

Once the user has been logged in, the server should recognize him and select the correspondent card associated to this specific user.

enter image description here

Does anyone know which could be the best approach to implement this?

Ahmed Ashour
  • 5,179
  • 10
  • 35
  • 56
Leonardo Carraro
  • 1,532
  • 1
  • 11
  • 24

1 Answers1

0

  1. you might well consider using a Cloud store location for your business network cards, that contain the blockchain identities (but your chosen strategy overrides that, eg cards persisted to a REST server instance) - a business network card (for the designated user) is then accessible to that application user (once authenticated, see item 4 below) to be able to connect to, then interact with, the protected business network, and ledger - as the specified identity. An example of one cloud strategy is shown here - more info on cloud wallets here

  2. You would create participants in Composer (the class(es) for which are defined in your model file) in the business network, and issue identities through Composer (mapped to the participant above) - or indeed from your CA server, as an administrator (eg the user goes through some application user registration process then activates the account, their blockchain identity, via a link to their email id etc etc or as suits) . Your Composer identity (in the business network) could possibly map to the web portal user id in some way (meaning: whether you want that to be direct or indirect, you'll know your security architecture better).

  3. Some of what you are asking about is answered in this Stack -> Hyperledger Composer Web application user authentication

  4. You would obviously use an authentication strategy to authenticate your web app users - for example if your app is consuming the Composer REST APIs to interact with the business network on the blockchain. See this Google OAUTH2 (client auth-based) tutorial for an example -> https://hyperledger.github.io/composer/latest/tutorials/google_oauth2_rest .

Paul O'Mahony
  • 6,740
  • 1
  • 10
  • 15
  • Thanks for your answer, it is very useful. Do you suggest to proceed with custom loopback implementation or configure the default composer-rest-server? – Leonardo Carraro Aug 29 '18 at 09:25
  • I can't answer that - you may have specific APIs you want to hide, or require added, custom API functionality over and above the Composer REST server. Or you may find the default Composer REST server is adequate for your needs. – Paul O'Mahony Aug 29 '18 at 10:23
  • Since I'm only experimenting, I would like to use the default composer-rest-server with a passport-local strategy and the composer cards stored in a database. In particular I would like to be able to store the cards and the credentials for the passport local strategy on a cloudant DB instance in IBM Cloud. – Leonardo Carraro Aug 29 '18 at 10:29