i have been reading the docs of hyperledger fabric but i have been stuck on something. what does this paragraph actually mean:
"The split between channel and local MSPs reflects the needs of organizations to administer their local resources, such as a peer or orderer nodes, and their channel resources, such as ledgers, smart contracts, and consortia, which operate at the channel or network level.
It’s helpful to think of these MSPs as being at different levels, with MSPs at a higher level relating to network administration concerns while MSPs at a lower level handle identity for the administration of private resources. MSPs are mandatory at every level of administration — they must be defined for the network, channel, peer, orderer, and users."
MSP is both a module in Fabric's nodes (peers and orderers) that validates identities and classifies them to principals, and also an instance of such a module.
So, you can have multiple MSPs in each peer/orderer and they all belong to some channel, or they just belong to the node itself.
Every instance of an MSP is used by Fabric policies and access control code to define who can do what.
The Fabric policy infrastructure, and all access control code, either directly or indirectly use MSPs.
So, if the node uses an access control check, or a policy evaluation in the context of some channel, it uses some MSP in that channel.
If it uses an access control check (or a policy evaluation) that is not related to any channel, it uses the local MSP.
Examples of when channel MSPs are used is - when a peer commits a block, it checks the endorsement policy of the transactions of chaincodes. The endorsement policy is fetched from the world state (which resides in the database) and then the policy string is converted to a policy instance, which uses a channel "MSP manager" which contains all MSPs defined for that channel. Every such MSP - belongs to some organization in the channel.
An Example of when the local MSP is used, is - when you install a chaincode on a peer - the operation is not in the context of any channel, so - the local MSP checks that the gRPC call comes with a signature that is signed by some peer administrator, and the definition of who is the admin is defined in the local MSP.
Related
According to most examples, there are logically minimum 3 organizations (org1, org2, orderer).
Actually there are only 2 physical organizations (org1, org2). Either one of the organizations or an agreed 3rd party has to hand over the orderer organization's responsibilities.
Q1: Who should be the owner of the "Orderer Organization" in Hyperledger Network?
Q2: Would there be a security flaw if an organization becomes the "Orderer Organization" and owns all of the orderer nodes (Raft) in the Hyperledger Network?
Q1: Who should be the owner of the "Orderer Organization" in Hyperledger Network?
Answer to first question is tricky. Just to give preface to answer, because Fabric’s design relies on deterministic consensus algorithms, any block validated by the peer is guaranteed to be final and correct. Ledgers cannot fork the way they do in many other distributed and permissionless blockchain networks like Bitcoin or Etherium. Orderer/Ordering node does this transaction ordering, which along with other orderer nodes forms an ordering service.
Just like peers, ordering nodes belong to an organization and everything that interacts with a blockchain network, including orderers acquires their organizational identity from their digital certificate and their Membership Service Provider (MSP) definition.
Every channel runs on a separate instance of the Raft protocol, which allows each instance to elect a different leader. This configuration also allows further decentralization of the service in use cases where clusters are made up of ordering nodes controlled by different organizations. While all Raft nodes must be part of the system channel, they do not necessarily have to be part of all application channels. Channel creators (and channel admins) have the ability to pick a subset of the available orderers and to add or remove ordering nodes as needed (as long as only a single node is added or removed at a time).
So Channel Creator and Channel Admins can choose subset of the available orderers or add/remove single orderer. Also multiple organizations can control cluster having ordering nodes. So it is upto you whom you call owner.
Q2: Would there be a security flaw if an organization becomes the "Orderer Organizaion" and owns all of the orderer nodes (Raft) in the Hyperledger Network?
Just some points to Note before answering definitively:
Orderers can not see transaction data, they only order the transactions.
Everything that interacts with a blockchain network, including peers, applications, admins, and orderers, acquires their organizational identity from their digital certificate and their Membership Service Provider (MSP) definition.
Although an organization can act both in an ordering and application role but it is a highly discouraged configuration. By default the /Channel/Orderer/BlockValidation policy allows any valid certificate of the ordering organizations to sign blocks. If an organization is acting both in an ordering and application role, then this policy should be updated to restrict block signers to the subset of certificates authorized for ordering.
Before any transaction(ordering) is authorized it is validated by peers and after validation consensus transaction is committed.
In Hyperledger Fabric, the blocks generated by the ordering service are final. Once a transaction has been written to a block, its position in the ledger is immutably assured. As we said earlier, Hyperledger Fabric’s finality means that there are no ledger forks and validated transactions will never be reverted or dropped.
Raft follows a “leader and follower” model, where a leader node is elected (per channel) and its decisions are replicated by the followers.
So if above points are considered in implementation with security consideration it should not be a security flaw since orderer is only doing ordering, can't see transaction, is validated by Peers before transaction is committed, Peers & orderers are different organisations and once transaction is committed in order it is final & immutable in it's order & position.
Sources:
https://hyperledger-fabric.readthedocs.io/en/release-2.0/orderer/ordering_service.html
https://hyperledger-fabric.readthedocs.io/en/release-2.0/Fabric-FAQ.html
https://medium.com/#kctheservant/add-a-new-organization-on-existing-hyperledger-fabric-network-2c9e303955b2
https://medium.com/swlh/hyperledger-chapter-6-hyperledger-fabric-components-technical-context-767985f605dd
It is possible to configure a single organization, to act both as peer and orderer organization, at the same time?
And also, if possible, can an example be provided?
More specifically, using the first-network from fabric-samples as template, with both cryptogen and cryptotxgen cli, to generate all the certificates, and also using docker-compose to bring the network up.
I've tried it out, but had some trouble instantiating the code at the peer node.
Yes, it is possible, but not recommended. From https://hyperledger-fabric.readthedocs.io/en/release-1.4/Fabric-FAQ.html#ordering-service:
Question: Can I have an organization act both in an ordering and application role?
Answer: Although this is possible, it is a highly discouraged configuration. By default the /Channel/Orderer/BlockValidation policy allows any valid certificate of the ordering organizations to sign blocks. If an organization is acting both in an ordering and application role, then this policy should be updated to restrict block signers to the subset of certificates authorized for ordering.
I have also experienced strange behaviours getting peers from those organizations join to channels they are not allowed to (although they are not able to synchronize with the channel later).
I have done using Fabric-CA. With cryptogen you probably have to declare those organizations as if they were orderers, so that peers will also have their cryptographic material under ../ordererOrganizations/.
On the endorsement policy syntax documentation on https://hyperledger-fabric.readthedocs.io/en/release-1.2/endorsement-policies.html
it is stated that principals are defined as MSP.ROLE where MSP is the MSP ID and the ROLE is either member, admin, client or peer
In the examples shown mostly member is used. It is states "MSP.member" would mean "any member", but what is a member? Currently, as most endorsement policy we use follow that syntax, we are assuming that it means any peer? But there is also the example of "MSP.peer".
And as this is an endorsement policy where it checks transactions have been endorsed, when are "admin" and "client" used?? (as it does not seem possible for an admin or client to endorse a transaction).
Is there a clear guide on when to use member, admin, client and peer for Endorsement Policies?
A Fabric network member is an user on the Blockchain network. Usually, a member indicates an organization.
The example below from the official docs means that in order for a transaction to be endorsed and sent to the orderer, a user from each organization must sign/endorse.
AND('Org1.member', 'Org2.member', 'Org3.member') requests 1 signature from each of the three principals
Admins are one level above a member. An admin can add and remove members from the network and modify member settings.
A peer can be an endorsing peer or a regular peer which does not endorse but commits transactions.
A client is usually an organization that invokes the smart contracts on the Blockchain network.
In your organization you will have roles, and every role will have their privileges. For policy endorsement, there are only 4 types of roles: member, client, peer and admin And the endorsement policy can be:
OR('Org1.admin', AND('Org1.member', 'Org1.member'))
That mean, a chaincode transaction previously instantiated in the Org1, can be endorsed by one admin or two members of the Org1. In a Fabric environment, you can set which peers can validate and endorse a transaction, and with the MSP provided by Fabric CA, you can set which role is allowed for your peer. You can read more about that here.
In Fabric CA you can register and enroll new identities in your Org. Every identity has a role and an attributes, for example, you as an admin of Amazon Programing Department, you can register,give a role and an attributes to enroll new users in the Programming Department. This works the same for peers, you can enroll new peer identity and give it a role (member, admin, client and peer) as found here
credits : Alexander Yammine
I think you could consider the answer in this thread link, and the document here
admin: a user role that has the ability to add/remove peers, deploy chaincode, create and join channels, etc. on behalf of that organization.
client: an identity should be classified as a client if it submits transactions, queries peers, etc. (e.g your application)
peer: an identity should be classified as a peer if it endorses or commits transactions. (e.g endorser, committing peer)
what is Application's own signature in this context, and how can someone using hyperledger fabric node SDK can set the application's signature?
the application that you are talking about is simply a client app which talks to the ledger. The issue here is not the client app, the issue here is that you need a proper endorsement policy which establishes how anything goes onto the ledger.
Imagine this scenario ...
you have 2 orgs, Org1 and Org2, both owning one peer, P1 belongs to Org1, P2 belongs to Org2 and both peers joined on a channel, let's call it defaultchannel.
you deploy and instantiate your chaincode and set a basic endorsement policy which is 1-Of.
Each org has a client application, running against their own peer. When Org1 submits a transaction to the ledger, its validity is endorsed by itself, but not by the second org, because your policy requires only one to accomplish this. Basically in any network where you have more than one org, you really want a proper endorsement policy. 2-Of would work in the case of our example as any transaction would need to be validated by both orgs and that gives the ledger much better integrity.
Bottom line, your fabric network needs to be properly built and protected, especially in a production environment and this allows it to be protected by any client apps which have rights to interact with it. Your network being protected means that it doesn't matter how a client app is built and what it tries to do, it won't be able to bypass mechanisms such as the endorsement mechanisms.
Following is given as part of hyperldedger fabric documentation for v1.1:
Switching between organizations to sign a config transaction (or to do anything else) is not reflective of a real-world Fabric operation. A single container would never be mounted with an entire network’s crypto material. Rather, the config update would need to be securely passed out-of-band to an Org2 Admin for inspection and approval.
Say we have 4 organizations Org1,Org2,Org3 and Org4 and we are in the process of creating Org5.
Let Org1 and Org2 belong to same cli whereas Org3 be in Org3cli and Org4 be in Org4cli
Let us say all initial steps to launch org5 into network has been done.
On coming to peer channel signconfigtx I first sign from cli using peers of Org1 and Org2.But I need one more signature as majority says 3.
I go to Org3cli as sign on behalf of org3 but since peer channel signconfigtx method is local cli (Containing Org1 and Org2) doesn't come to know about it.(result is not send to the orderer).
So given in a real world scenario that a single cli isn't expected to handle all configuration,How do u handle interaction between 2 different cli ?
As you have correctly interpreted, the documentation is telling you that setting up a multi-org network using a single control point which has access to the crypto material for multiple organizations is not reflective of how things work in the real world. We do this in the samples to make it easy to bootstrap a multi-org sandbox network.
In the real world, you would need to pass the serialized configuration (update) transaction out of band to all of the organizations who need to sign it based on the channel policy. Fabric currently does not provide any tools for handling the out of band communication ... this is left up to the members of the network to decide.
There are vendors out there that are providing governance and lifecycle management tools for Fabric as part of their offerings, but there are currently no Fabric-specific tools available in open source for this.