In comopser rest server I know its advisable to store network card with composer rest server. Now what if I dont want to store my network card in rest server wallet. How to sign transaction indvidually by passing my certificate during calls to rest server.
You can use Cloud-based wallets see -> https://hyperledger.github.io/composer/next/business-network/cloud-wallets available from v0.18.x onwards
You can use the Composer JS APIs to connect to the business network with a business network card, and then transact on the network, as that blockchain identity. Example here -> https://github.com/hyperledger/composer-sample-networks/blob/master/packages/pii-network/test/pii.js#L119 onwards (instead of MemoryCardStore shown here, you can use FileSystemCardStore to work with a card in your wallet store)
See also Hyperledger Composer Web application user authentication for more information
Related
I am trying to design a Hyperledger Fabric solution with following requirements
The users are signed-up with an organization
The user should however have their individual identities on Blockchain
The users would interact with Blockchain through a web application
The users should store their own private keys / certificates
Individual user's key / certificate should be used to sign the transaction going to Blockchain. The organization however should not have access to user's private key / certificate
Instead the web application should merely transfer the signed content of the transaction to Blockchain, making it tamper-proof
Are there any solutions available that would cater to these requirements, so that the users continue to work through the web application only?
Can node.js SDK for Fabric be used on the client side to sign the transaction using the locally stored private key / certificate on user's desktop / laptop?
As of right now, no, there are no solutions available to cater to these requirements as the node SDK does not currently support a separation of logic between signing transaction proposals and sending transaction proposals. Step 6 is not possible with the 1.2 SDK.
Separating that logic is slated for the 1.3 release.
I started composer rest server in multi user mode, using github oAuth authentication. I opened one session in chrome and one in firefox (to emulate as two different users) and authenticated using github. Now in one browser I wish to use one network card and in chrome another network card. Now when I import a network card in firefox same is reflected in Chrome as well. Doesn't it defeats purpose of authourisation ? So if one user is using its network card to perform transaction the other user will also be using the same network card as its been set as default for composer rest server. How to deal with scenario ?
The default is set at the REST Client - not the REST server. You're consuming the REST APIs as a client - as the two different blockchain identities (contained in each of your business network cards). Once a client has authenticated to the REST API, that client can add Blockchain identities to a wallet. The wallet is private to that client, and is not accessible to other clients. When a REST client makes a request to the REST server, a Blockchain identity in each clients wallet is used to digitally sign all transactions made by that client (because the identity is set as default, at the time).
The github authentication scheme is a 'delegated' authentication scheme and is using a client application (id and secret) authentication mechanism to enable a client to use the REST APIs and get a token, without needing to authenticate as a user every time.
I had this same problem. Configured the composer rest server with multi user using a jwt strategy, but I was seeing the same wallet (and the same default card) regardless of which user was logged in.
I found that the loopback-component-passport package which largely manages the wallet data was importing my users correctly, but they were all being associated with the same identity because the identity id was taken from the COMPOSER_PROVIDERS config and not the signing in user.
To fix it I modified loopback-component-passport/lib/models/user-identity.js.
Look in the UserIdentity.login method around line 100 where the userIdentity is being populated.
Change:
provider: provider,
to something like
provider: profile.sub,
depending on your payload / user profile.
After that each user will have their own identity registered in your loopback database and each signed in user should have their own wallet.
I was reading this pretty cool article this morning:
https://medium.com/#CazChurchUk/developing-multi-user-application-using-the-hyperledger-composer-rest-server-b3b88e857ccc
I am interested in the Rest Server features but I have a couple of questions on it:
How does the Rest Server knows which wallet to use for a specific logged-in client?
How to create channels and join peers from/using the Rest Server?
Thanks hackers!
Once a REST client (where the wallet is) has authenticated to the REST Server, that client can add Blockchain identities (one or more) to its own REST client wallet. The wallet is private to that client, and is not accessible to other clients. When a client makes a request to the REST server, a Blockchain identity in the clients wallet is used to digitally sign all transactions made by that client (and the REST server knows who that is on the business network as that identity is mapped to a participant).
Please note that this feature requires that clients trust the REST server. This trust is required because this feature requires that the REST server stores the clients Blockchain identities as part of the card. Therefore, it is strongly recommended that clients only use REST servers that are managed by a trusted party, such as an administrator within their organization.
All information regarding authenticated users and their wallets (containing each users business network cards when multiple user mode is enabled) is persisted in a LoopBack data source by using a LoopBack connector. You would normally set up a persistent store such as MongoDB and the REST server would use a Loopback adapter to access the MOngoDB store. REST clients that have authenticated via a strategy will normally get an access token (once they authenticate) and which is stored locally (such as in the browser for OAUTH2)
Channels and Peers (which come from Hyperledger Fabric) are configured in connection profiles (connection.json file) which are part of the business network cards built for a participant of the business network. The REST server itself doesn't 'join peers or channels' it knows about it because it is started with a business network card (and the definition of the channel and peers are known to the REST server that discovers the business network to which it relates). Obviously you can stand up many REST server instances to serve the different 'living' business networks deployed (on whatever channels (ledgers) or peers defined in the profile) in an organisation.
I have issued new participant id using Post operation of /system/identities/issue and got the card file having connection json and enrollment id and secret. Now how to generate certificate using that enrollment id and secret using the already created rest api by comopser-rest-server.
As you have found out, the Identity Issue results in a .card file (an archive containing the Connection, enrollment ID and Secret) The Secret is a one time secret and the first time the card is used the Certificates are downloaded and stored locally. After this the Secret is not valid. This works the same way for CLI, Playground and REST API.
For CLI and Playground the cards (and certificates) are stored in under the home directory of the logged in user ~/.composer/ .
For the REST server, you need to run the REST server in Multiuser mode and then there are some new endpoints under /wallet e.g. /wallet/import. The REST server stores the Cards (and certificates) in these Wallets. This is described in this document REST Server Multiuser.
A couple of additional notes: To run in Multiuser mode you also need to enable Authentication for the REST Server. When you stop the REST server the Wallets will be lost unless you persist a datastore for the REST server.
This parent doc has all the information for the REST server. REST Server Parent Doc
When following the documentation at here in order to issue identities in Hyperledger Composer, they say that:
The Hyperledger Fabric certificate authority generates an enrollment secret that can be given to the participant, who can then use the enrollment secret to request their enrollment certificate and private keys from the Hyperledger Fabric certificate authority.
I have successfully issued an identity and got the enrollment secret. However, it is not clear how to request the certificates from the CA.
Could anyone help?
that instruction is not entirely clear, will need to get this changed.
A Business Network Card is the definitive means to connect to a Composer business network, and a constituent part of that is identity that you issued (and which was mapped to a participant in Composer) - it is only possible to access a Composer business network through a valid Business Network Card. It consists of a connection profile, some metadata for the identity using it, and ultimately, a set of credentials (certificate/private key which get populated automatically to the user's wallet from where it is used to 'connect' - a 'ping' is also a connect). FYI an identity (linked to a participant in Composer) can have one or more cards (each to connect to one or more business networks).
The document you need to read to do that is https://hyperledger.github.io/composer/latest/reference/composer.identity.issue.html
you'll see it has a -f flag to create a card file - that is the file you import (eg using Composer Playground to import or composer card import -f ). If you've done that import from the CLI, do a composer network ping so that it will use the one-time enrolment secret to request the certificate/key from the CA server and then store it in the user's wallet under $HOME/.composer - the card should be listable using the command composer card list