My question is on access control in hyperledger fabric composer.
Assume you have a business network, in which you have the following participants:
Sellers
(Potential) Buyers
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:
right to install and start the business network
right to control changes to the system made by the other system administrator (e.g. if the Daimler system administrator changes the code of the application, then the General Electric administrator must approve those changes before they can become effective)
Read Access to employees of one's own company
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
Related
In Hyperledger, does the decentralization ends at the organization level?
or can it be also extended after the organization level i.e in the peers and client level?
According to what I understand -> if he/she wants then the Admin of an organization is able to control everything and take control of any Peer/ Client/ Member and can access their rights and do transactions by their name.
can we say that the Admin completely owns the organization?
Not sure you can say that an Admin completely owns the organization. What an admin or non-admin user can do is determined by access control lists. These determine who can do what. When combined with endorsement policies, one can ensure that changes require decentralized agreement.
I want to use Access control functionality in Fabric (like permission.acl in Hyperledger Composer), so how to achieve this in Fabric? and how to specify the user while accessing chaincode to test the Access controls provided for that user from node SDK.
eg:(like Tuna-network example in Composer) I want to give different CRUD access to chaincode functions to different participants/users.
There is no direct equivalent in hyperledger fabric for the Composer ACL functionality.
First you should look at access control lists in fabric to ensure that your fabric network has the correct level of security
https://hyperledger-fabric.readthedocs.io/en/release-1.3/access_control.html
(You would have to have done this anyway as even if you used composer ACLs to ensure a participant could not read something, if that pariticpant had the ability to query the ledger or is able to listen for block events they could still infer the data, unless encrypted, regardless of the Composer ACL denying read access).
The other fabric capability you could look at is what's termed "Attribute Based Access Control". This is where attributes with values are associated with a certificate and the fabric shims for each language provide a utility library to allow chaincode to extract those attribute values and then the chaincode implementation can make a decision on whether the identity making the request has the appropriate authority to perform whatever it has requested.
More details can be found here
https://hyperledger-fabric.readthedocs.io/en/release-1.3/chaincode4ade.html?highlight=client%20identity#chaincode-api
I wanted to understand how are participants tied with Organization when we define the model.
For example if I have 3 participants(Grower, Shipper, Trader) and have a network of 3 organization(OrgGrower,OrgShipper, OrgTrader)
then will adding participants how is the one to one relationship mapped between Participants and Organization.
I want to do all this via Web site and give access to administrator for adding only there participants and but also want to
have a super admin which has access to all the organization. Is this achievable via Hyperledger composer
Answered same posting on Rocket Chat:
In Composer a Participant is just a data item, specifically an object in a Participant Registry. A Participant cannot access the Business Network on the Fabric until an Identity has been Issued to and bound to that Participant. Identities are generated by the CA which belongs to an Organisation. A user (administrator) with an Identity can create Participants if they have the ACL access to do so, but only an Identity with specific rights in the CA can issue Identities. This doc describes Participants and Identities in more detail: https://hyperledger.github.io/composer//managing/participantsandidentities
I don't know if CAs can 'cross certify' to allow your Super Admin to issue identities for the 3 CAs (Organizations). There is a #fabric-ca channel that should be able to answer that question.
In our application, we can have a lot of users. (10000 ++)
We would like to give our users the opportunity to sign their transactions, list their assets, in a private environment.
They have their own end users and assets, and will be able to manage them through the network.
At first, our users would use our network, and then we hope to be able to offer them a higher level of privacy by allowing them to interact with their own network. (via the ledger)
We have built a system using composer where our end users (our customers) have their own identities. But we need to be sure we will not have any limitations. Knowing that with this scheme, the number of participants can become huge and the management of identities could become a nightmare
We searched, but we did not find information related to the limitations of such a system built with hyperledger composer.
We understand that a business network is private, but in the case of a SAAS application what would be your recommendations?
So it sounds like you want to give organisations access to a SaaS application and (ultimately) maintain separation (privacy) of the ledger - for an individual organisation (and its users).
You can deploy the SAME business network (smart contract and deployed business model) on separate channels (as in Fabric channels) so then each organisation will have its own ledger. Furthermore, you as the SaaS provider can either issue identities from a central CA registrar in the SaaS network - or - more likely - each has access to their own CA to issue identities (ie certificates) - however that's configured - so that their users can sign transactions (eg from the application).
Those users would connect to their business network (and access that ledger) via business network cards - the 'card' contains the identity information and connection metadata to connect to the deployed business network (from the application in question, eg via the APIs). After an end-user signs in, a check can be made to see if they have a busness network card, to be able to interact with the ledger.
Its likely that the SaaS provider or individual organisations would (through some UI or management capability) issue the cards and have them persisted/stored centrally/securely - ie so the SaaS application running in the end-user's browser(say) can access the user's wallet in that org, which contains the business network card and identity info - just one possible implementation example).
The building of / issuing of cards can be automated (as can the creation of a participant in Composer - which maps to an identity). A CA server will issue a certificate for each identity registered, and each unique identity would therefore have a unique business card (miniscule footprint ie < 1k). Does that help ? So I don't see a major 'limitation', nor a major overhead in what you propose.
Looking at securing confidential information in Hyperledger Composer
If assets and transactions in a business network have ACL's to prevent a competitor participant (non-owner) from viewing confidential information, what access can the competitor have to assets and transactions owned by another participant?
Can the competitor access the underlying Fabric ledger to view assets/transactions?
Can the competitor view the transaction processing function?
Can the competitor view the logs of the transaction processing function?
How secure are ACLs?
I don't know if there is some documentation covering this already, or how much is about the security of Fabric rather than Composer.
Dan Selman suggested on RocketChat to ask here.
Thanks
Andrew
Composer's Access Control Engine prevents transaction processor functions written in Javascript from accessing the data in the ledger, based on the type of access requested, the current participant, and the transaction being processed.
The ACL engine does not encrypt the data on the ledger, or attempt to filter the chaincode container logs to remove information.
So, I would say in its current incarnation it is not a suitable mechanism to prevent someone who has physical access to a peer (world state, or the blockchain itself) from viewing information they should not have access to. Modifications are obviously much harder, due to the immutable nature of the blockchain.
In many ways this is similar to access control logic for a relational database. Someone who has physical access to the database files on disk can likely circumvent all access control rules on tables/views etc.
I do believe that we need to go further than this, but first I think we need more detail on the requirements.