I'm struggling with identity management on a peer node using the newer OU approach to credentials. I'm close to having it working, but there's some concept or something that I'm missing.
Where I'm stuck is with trying to issue a peer channel join command on the peer.
I've tried this 2 ways:
I've registered an identity as a peer and used its enrollment to create the local MSP on the node. With this identity, when I try to join the channel, I get the following error: "The identity is not an admin under this MSP"
I've registered an identity as a admin and used its enrollment to create the local MSP on the node. With this identity, when I try to join the channel, it succeeds
However, running the peer node as an admin can't be the right answer. The documentation is clear:
An identity should be classified as a client if it transacts on the network.
An identity should be classified as an admin if it handles administrative tasks such as joining a peer to a channel or signing a channel configuration update transaction.
An identity should be classified as a peer if it endorses or commits transactions.
An identity should be classified as an orderer if belongs to an ordering node.
How can the peer node act as both a peer for "endorsing and committing transactions" and an admin for "handling administrative tasks"? What am I missing here? How do I setup a peer identity that has admin rights to its peer node?
I also want to make sure that the credentials stored on the peer only allow admin commands on that specific peer node and do not provide admin rights to the broader network.
Thanks in advance.
You should only use the Admin's MSP to run peer channel join, but your peer's CORE_PEER_ADDRESS.
export CORE_PEER_MSPCONFIGPATH=$ADMINMSP
export CORE_PEER_ADDRESS=$YOURPEERADDRES
peer channel join -b /path/to/block
The peer is already up using its own peer MSP, so it will not use the Admin's MSP to run on the network. It is just for this operation.
You don't need to register a peer as an admin, but you must have an admin user to take care of these functionalities. It is strongly advised to not use the Org Admin MSP (Channel MSP) for any operation rather than on the channel configuration, so just enroll a new admin user and use it for admin operations. It is not necessary to store admin files on a peer, just have a convenient way to use the Admin MSP when it is needed.
Regarding the confusion, in Fabric you can have an admin act as a peer but not the other way around.
Related
Would you please help me to understand the below questions. These questions are internals of fabric architecture and have not been very well documented in the fabric docs.
Whenever an identity is issued to an user it could be either type of peer, orderer, admin and client. How does the endorsing peer will check or confirm if submitting client signature is valid [Assuming client signed the proposal using private key and the endorsing peer will have the client public key to verify, but still the integrity is not assured]
How does each endorsing peer ensures that the transaction submitter satisfies the channel’s Writers policy. Submitter here is client who has rights to submit a transaction proposal.
The genesis block does not contains application client certificates and they can be generated and issued in later stage also. So that means Endorsing peer would have a mechanism to understand a valid certificate issued by CA who is also part of the network whom it can trust. I am not able to these intrinsic mechanism created and implemented in fabric.
Thanks in advance.
There is a component called msp(membership service provider) which stores the keys and certs used in the blockchain network. It is present on all participating nodes. Take a look at this https://hyperledger-fabric.readthedocs.io/en/release-2.2/msp.html.
Endorsing peer is having the root certificate of the organization's CA. Peers receive them when their organisation joins the channel using genesis block. The transaction proposal has the client's signature and it's X.509 certificate. Endorser can verify if client's identity (X.509 certificate) is coming from the organisation's CA using the root certificate of the CA.
Channel policy and the root CA certificates are available inside genesis block. Genesis block is generated using the channel configuration file(configtx.yaml). This genesis block is used at the time of joining channel.
I am performing chaincode invoke under following scenario:
I have a Hyperledger Fabric network running end-to-end till querying of the chaincode.
I have an admin identity which was added to channel configuration at the time of channel creation.
The chaincode invoke operation is set to Admins policy which states: "OR('Org1MSP.admin')"
I create another admin identity (with OU=admin and hf.Type=admin) under Org1MSP.
So now, can I use this new admin identity to invoke the same chaincode without configuring any changes to my channel?
If your organization's MSP configuration uses NodeOUs, it should work, as your certificate contains OU=admin.
If you have NodeOUs disabled, the second client is not an admin (only user certificates under admincerts MSP folder are). Then, you should update your channel with configtxlator, etc.
https://hyperledger-fabric.readthedocs.io/en/release-1.4/msp.html#identity-classification
I have created my fabric network which includes 2 Orgs having 2 peers each and used Fabric-CA for generating crypto material for peers and orderer.
how to enroll and register users which will do the transactions (invoke/query the ledger) using Fabric-CA node sdk? I have gone through the "balance-transfer" sample app but in that sample, key-store path for storing user credentials is hard-coded and keys gets generated inside the project directory.
I assume, there will be some way possible to enroll users and store their credentials inside the peer containers of organization(as other peer related certificates/keys are also getting stored inside the container of the peer).
let me know if my assumption is correct or wrong. If correct, then how to achieve this using fabric-ca node sdk. Else how to store user credentials outside the containers securely. One way can be maybe using HSM?
I learn about Hyperledger Fabric but in the part of Channel MSP I still have some questions. Channel MSP is the combination of local MSP and when a client access to channel, how can a peer verify identity of a client? Does a peer need to access to Channel MSP and check a client's identity by himself or he invokes a specific Chaincode to verify?
how can a peer verify identity of a client?
Client request could be in context of some specific channel, for example chaincode invocation. In such case peer will verify clients access rights based on Channel MSP. In case clients request not in context of specific channel then peer will be consulting local MSP to verify clients identity.
Does a peer need to access to Channel MSP and check a client's identity by himself or he invokes a specific Chaincode to verify?
As explained above, chaincode invocation done in context of certain channel hence peer will leverage channel MSP to verify client's identity. Peer will do it directly, e.g. without calling additional chaincodes.
Since I searched through fabric node sdk also composer-rest-server, they provided the MSP class also MSP manager in Fabric-ca-client and Fabric-client. Ex: in case of Hyperledger Composer beside you start network in Fabric-dev-server, you can find lib where building business network listen, call and loopback is in Node_Modules (home/$User/.nvm/versions/node/v8.12.0/lib/node_modules). In conclusion, a peer no need to invoke a specific chaincode for check ACL also client's identity. He can call an existing code in the composer-rest-server.
I have the doubt of the certificates generation and usage.
While doing the network setup, for each organization we are creating admin user and additional user certificates.
We are mapping the CA certificates and using in cli bash
While using fabric client, we are creating a new keystore and creating and enrolling admin for users again.
What is the usage of Admin user we create for peer and organization using crytp-config.yaml file and crytpgen tool?
As far as i know, in the examples there are three Roles/Users created in the examples.
an Admin, this is the admin for a given organization
a User, this is an identity used to interact with the peer
a PeerAdmin, this is an identity used to interact with the peer with the additional permissions of being able to create a channel, join other peers and installing chaincode