How to get certificates for identities from CA in Hyperledger Composer - hyperledger-fabric

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

Related

What is the best way of storing the clients registration information off-chain in hyperledger fabric

I want to create an application with the Hyperledger fabric network and I'm unsure what the optimal way of processing and storing the clients information is. It is important for me that the personal information get stored off-chain to not slow down the network.
Right now this is the process I thought about:
Client fills out form in frontend
Application (backend) generates unique UUID
(registering enrolling UUID in the wallet) unsure about this step
Chaincode gets called which saves the UUID in the state database
The UUID and the personal information like Username, email, password get encrypted and saved in an off-chain database like postgreSQL.
That way the UUID can be connected to the personal information because the UUID is also stored off-chain and it is still totally anonymous.
But is it necessary to register and enroll the user through the Node SDK with the enroll and register function before being able to access the chaincode, because without the registration there would be no identity for the client in the network?
And I'm also cunfused if this function from the fabcar samples is the same as the enroll and register function from the node SDK?
Thanks for your efforts and helping me understand this matter.
The enroll code of fabcar is the enroll of node-sdk.
In other words, they are the same.
node-sdk/enroll
fabcar/enroll
const secret = await ca.register({
affiliation: 'org1.department1',
enrollmentID: 'appUser',
role: 'client'
}, adminUser);
const enrollment = await ca.enroll({
enrollmentID: 'appUser',
enrollmentSecret: secret
});
First, let's talk about fabric's SDK.
In general, in order to query/invoke chaincode on the fabric SDK, you need to obtain fabric client authority.
Suppose you register a specific user UUID as a Client of Fabric and call the chaincode through that Client.
In this case, the order you should perform is as follows.
enroll admin-client to Fabric-CA
register user-client by admin-client to Fabric-CA
chaincode invoke by admin-client or user-client to Fabric-Network(peers, orderers)
step 1, when Fabric-CA is first operated, the administrator ID and password can be specified through specified parameters. Based on the specified ID and password, a client key/certificate with admin authority is issued from Fabric-CA and stored.
(Fabric-CA is recommended to be operated in an organizational unit, and client authority is organization dependent.)
step 2, a new user can be registered through the admin-client key/certificate. Probably you would register the UUID as enrollmentID.
When the registration process is finished, the user-client's key/certificate is issued by enrolling in Fabric-CA, and it is stored.
step 3, the chaincode is query/invoke through the stored admin-client/user-client key/certificate. Of course, it can be performed only if the client is authorized, and this is defined in the genesis block of the channel in the blockchain network (that is, it must be set in the configtxgen process)
Overall, if you look at the scenario, you can see the two processes divided.
In case of separate authentication server
Build a new database(for off-chain).
When registering as a member, the user's information(UUID, password ...) is stored in the database
going through the fabric user-client registration process, the key and certificate are stored in the file system or database.
When logging in, based on the newly established database, authentication is performed.
When the chaincode of the fabric network is called while the user's validity is verified according to the authentication procedure, it operates based on the mapped key and certificate.
When using an organization as an authentication server within Hyperledger Fabric
User information is stored in the blockchain through PDC(Private Data Collection) provided by Fabric.
PDC is an off-chain technology, and only predefined organizations share data.
Through this function, validity of data can be performed by all organizations participating in the channel, but only organizations with permission can view/edit the actual sensitive information.
In the end, the process and procedure are the same, but all resources can be managed on the blockchain.
(Like all technologies, they have pros and cons, and trade-offs need to be taken care of.)
[NOTE]
If you are going to query/invoke the chaincode of the fabric network, fabric-client privileges are essential.
Of course, you can do some tricks.
for example)
register admin-client on the server.
After that, it operates the same as the existing authentication server/resource server.
If the chaincode of Fabric Network is called, and it is valid by the existing authentication server, the chaincode is executed through the admin-client authority issued in advance.
This does not require a separate user-client registration/management procedure.
However, the authority on the blockchain is all dependent on external certification authorities.

Admin & users created by "CA" vs Admin & users created by "cryptogen" in Hyperledger Fabric

I am a newbie to Hyperledger Fabric. I came across a very confusing part of fabric.
Cryptogen is used to generate certs and keys for users and admin in an organisation.
Talking specifically about fabcar,
A very similar thing is the done by:
enrolling an admin
enrolling and registering a user identity using CA, in fabcar chaincode.
Things got more confusing when I saw CA server creating a bootstrap
'admin' identity while starting of the container itself.
So what exactly is happening?
What is the flow?
What is the difference between these admins created again and again?
I see, CA server container has a volume mounted, pointing back to the crypto-config folder which already have certs and keys generated by cryptogen.
Why are we again creating bootstrap identity on fabric-ca-server start using -b flag? We already have admin certs and keys generated for admin by cryptogen and those are already mounted on the fabric ca server container.
Why are we again enrolling an admin in fabcar chaincode, we already have certs and keys for admin, don't we(from the volumes mounted on fabric ca server container)?
Why are we both registering and enrolling a new user in fabcar chaincode, we already have certs and keys for one user(in fabcar), don't we(from the volumes mounted on fabric ca server container)?
Similar existing answers is not what I am looking for. I want an in-depth insight.
Thanks.
Okay, so after digging around for continuous 1 week I found exact answer to the question.
First, I would like to lay down exact flow and structure of fabric samples applications.
Fabcar and Commercial Paper are two different applications being
provided by fabric as a part of fabric sample.
Fabcar uses first-network and Commercial Paper uses basic-network.
Fabcar has its chaincodes in chaincode folder while Commercial Paper has its chaincodes in contract folder within the two organisations.
After chaincodes are installed by administrators (don't confuse this admin with CA admin, this is simply a developer who is managing channel) using peer chaincode install and peer chaincode instantiate the contract becomes available to all the components of the respective channels.
Now we need to have certain application that will be invoking contracts known to the channel. Both Fabcar and Commercial Paper have their different applications in their respective application folders.
Applications can interact with our channel or say underlying fabric layer through a gateway.
The Hyperledger Fabric SDK provides a gateway abstraction so that
applications can focus on application logic while delegating network
interaction to the gateway. Gateways and wallets make it
straightforward to write Hyperledger Fabric applications. Find here in the docs
Our applications require some identity to be able to use underlying fabric layer. This identity's authenticity is checked by gateway before allowing access to the network.
Fabric uses concept of keys and signed certificates to perform this authentication.
Diving into a different concept here, fabric provides two kind of certification architectures (architecture might not be the correct word),
cryptogen - generally used for developement or testing purposes to generate keys and certificates
Certificate Authority - not a new concept, used by fabric to generate certificates. Any CA server requires to have admin to allow generating certificates.
While bringing up the server itself, this bootstrap identity is created using fabric-ca-server start with a -b option with username:password parameter.
Coming back to fabric, before starting any network (basic-network or first-network) fabric asks us to generate cryto-config.
Commercial Paper uses certificates and keys generated by this previously generated crypto-config by cryptogen to generate identities for the application.
Fabcar uses CA to generate certificates and keys. Admin was registered already when we brought up our CA server container in Fabcar. We simply gave him certs and keys on enrollment. New user require both registration and enrollment (done using CA admin identity).
The private and public key are first generated locally and the public
key is then sent to the CA which returns an encoded certificate for
use by the application. These three credentials are then stored in the
wallet, allowing us to act as an administrator for the CA. Find here in the docs
So it's not by design of fabric why Fabcar used CA and why Commercial-Paper used cryptogen, it's simply by choice.
I'll end my answer, quoting exact statement from the fabric documentation.
When we created the network, an admin user literally called admin
was created as the registrar for the certificate authority (CA).
Our first step is to generate the private key, public key, and X.509
certificate for admin using the enroll.js program. This process uses
a Certificate Signing Request (CSR) — the private and public key are
first generated locally and the public key is then sent to the CA
which returns an encoded certificate for use by the application.
These three credentials are then stored in the wallet, allowing us
to act as an administrator for the CA. We will subsequently register
and enroll a new application user which will be used by our
application to interact with the blockchain. Find here in the docs
addToWallet.js is the program that Isabella is going to use to load
her identity into her wallet, and issue.js will use this identity to
create commercial paper 00001 on behalf of MagnetoCorp by invoking
papercontract. Find here in the docs
Any corrections from experts are very welcome. These are my deductions from code observation.
I don't know what fabcar does, but maybe I can clarify some Hyperledger Fabric concepts to you.
cryptogen is a development tool using for generating all the (MSP and TLS related) cryptographic stuff you need initially for your development Fabric network.
For more serious deployments, you use Fabric-CA instead. Fabric-CA is a Certification Authority that maintains a database of the identities registered for your organization and allow your registered actors to enroll their certificates. You can also update identities, revoke identities and certificates, etc.
And then you have to distinguish a CA administrator from a organization administrator. You first enroll the CA administrator, otherwise you cannot register identities. And a organization admin is simply an identity with role admin for the organization.
Normally, the enrolled CA administrator generates all the identities. After that, later, in other place, the organization administrator (or any other identity) enrolls its certificate by specifying the user and password declared during registration.
Some Theory: cryptogen is just a tool written in golang and what it does is it will create a self-signed root ca and some signed certificates(org admin, users, entities)
Now when you start CA, if you want to use the same cert and key generated by cryptogen then you will use below command
fabric-ca-server start -b myorgadmin:myorgpw -d
ELSE if you do not want to use cryptogen generated certificates then you can use below command and you should forget about cryptogen generated certificates because they no longer use and you have to generate by yourself
fabric-ca-server init -b myorgadmin:myorgpw
DIFFERENCE is init command
Bootstrap CA server credentials are in order to authenticate for future
purposes
Ex: If you want to register a new user then you need to authenticate
with credentials
In future, you can use cryptogen generated user certificates or you can register different users by authenticating CA server

Client-side signing

I found following in the Composer docs. Is it ok? I thought that CA is for storing certificates/public keys but not private keys. Is it possible to sign messages on a client-side?
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.
Yes its possible. Composer stores the key/certificate in a wallet accessible by the client application user, so the user can sign transactions on the business network (using a Composer business network card to connect to it and which has the user's blockchain identity). This transaction is therefore signed by a certificate to say which identity is being used to submit the transaction.

Signing transactions with certificates on the go, in composer rest server

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

Hyperledger Composer and Authentication

i'm currently working on a POC application using hyperledger composer. I'm creating a mobile app which uses the client-SDK for interacting with my hyperledger network. I'm wondering how authentication works. Enrolling a new user works fine, i can enroll a new user being an admin and i receive the enrollmentID and enrollmentSecret. The documentation tells me the enrollmentSecret is used as confirmation for the CA to generate a certificate and corresponding keys.
The SDK gives me the idea that i'm authenticating by using only the enrollmentID and enrollmentSecret instead of the certificate and keys.
Quoting another answer i found:
When a participant enrols using the enrolment ID and secret, an enrolment certificate is generated and placed into their wallet (configured using the keyValStore property in the connection profile). Once the enrolment certificate has been generated, the enrolment secret is made invalid. The secret can be only used one time - it is not a password.
However what i want to do is give the "identity" total ownership of the certificate and keys so they can use it to authenticate on the network (maybe turn it into physical form / paper wallet). Looking at the SDK documentation this doesn't seem possible and i currently have no idea how it works if the only way to connect to the network is supplying the enrollmentId and secret.
Or does the SDK automatically store and use the certificate in the stored in keyValStore(connection profile) to authenticate? If so is it possible to manage this programmatically?
Thanks in advance
Hyperledger Composer issues new identities by using the Hyperledger Fabric certificate authority (CA) to register new enrollment certificates. The Hyperledger Fabric certificate authority generates an enrollment secret that can be given to the participating identity, who can then use the enrollment secret to request their enrollment certificate and private keys from the Hyperledger Fabric certificate authority.
See https://hyperledger.github.io/composer/unstable/managing/identity-issue.html
You then bind a participant (added to your business network) to that identity and that identity is used to submit transactions to the Fabric blockchain. So the authority to do so is via the metadata in the connection profile (pointer to the KeyValStore for the user in question) and the id's certificate in that KeyValStore.
Check out the Hyperledger Composer docs.
https://hyperledger.github.io/composer/unstable/managing/identity-bind.html

Resources