My question is on access control in hyperledger fabric composer.
Assume you have a business network, in which you have the following participants:
A seller is an employee of a company that sells products to a buying company. A buyer is an employee of a buying company.
Example: The buying company is Daimler. Three employees of Daimler are registered as Buyers in the network. The selling company is General Electric. Two employees of General Electric are registered as Sellers in the network.
With hyperledger composer's Access Control Language, one can restrict the access rights of buyers and sellers at will.
But how is the situation regarding Access Control at the Node level?
There are not only buyers and sellers but also two system administrators: one system administrator responsible for the Daimler peer and one system administrator responsible for the General Electric peer.
By default, the system administrators have access to all data. That is, the Daimler system administrator has access to all data of the registered General Electric employees. Vice versa, the General Electric system administrator has access to all data of the registered Daimler employees.
Is it possible to restrict the access of the system administrators to a handful of rights, such as:
Fabric uses access control lists (ACLs) to manage access to resources by associating a Policy with a resource.
In Hyperledger Fabric, ABAC is used for restricting access to the specific user having the necessary attributes in their certificate.
Unfortunately, since August 29, 2019, the project has been deprecated due to increasingly irremediable differences between the Composer modeling approach and Fabric technology.
One of the significant differences between Hyperledger fabric vs Composer is that Fabric is a framework, and Hyperledger Composer is a tool. So, with Hyperledger Composer, you can create a new platform of framework similar to Hyperledger Fabric.
Access to a hyperledger fabric (for anything including interacting with a business network) is managed by hyperledger fabric MSPs. Hyperledger fabric, as part of the setting up of the hyperledger fabric network and channels, define which identities (created via the MSPs) have the authority to install chaincode onto peers and which identities have channel authority, to be able to instantiate or upgrade chaincode. It is possible to restrict Peer Install and Channel instantiate/upgrade to specific identities. Information about Hyperledger fabric MSPs for example can be found at this link https://hyperledger-fabric.readthedocs.io/en/release-1.2/msp.html but you will probably want to be familar with the complete operations section this section is part of.
Access control in Composer is done via participants and the business network ACL file. You control which participants can perform various actions on resources controlled by the Composer runtime. You need an identity (generated by your MSP) in order to be able to interact on a channel/chaincode (as required by hyperledger fabric) this identity has to be previously mapped to a specific participant in order to the interact on the business network. When a request is sent to a business network, composer will look up that specific participant based on the identity that made the request and use that participant and it's type to determine, through the information in the business network ACL file, what it is allowed to do.
Note that things like Peer install, channel instantiate/upgrade of chaincode is a fabric level capability, not a composer capability so you do not control these types of activity through composer ACL definitions
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With