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
Related
What role am I operating from in the logic.js file composer? If I've defined permissions.acl such that two certain types of participant don't have any access to each other, may I still be able to, in my transaction handler (where both participants are involved by reference in the transaction body) inside logic.js, read/write any party's member variables arbitrarily?
Perhaps in other words, how is the "currentParticipant" determined by a transaction? Say I'm using the following started code for my app https://github.com/IBM/customer-loyalty-program/blob/master/web-app/app.js
The transactions are called by the nodejs runtime and not by a specific participant as far as I understand...
To interact with a hyperledger fabric network you will do as using an identity (certificate + private key). The composer runtime in the chaincode accesses that identity and then looks for the participant that it is mapped to. All identities must be mapped to a participant or you get a message saying the <common name> with identifier <unique id for the cert> has not been registered
Commands like composer network start, composer identity issue will bind an identity to a participant for you.
composer identity bind takes an existing identity and binds it to an existing participant.
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
I would like to know how either Fabric or composer can enforce Access Control Logic (ACL). As I read through the documents, ACL is a way to control permission to peers within a channel. When I, as a peer, have a local copy of the ledger, what would prevent me from reading the data that I locally have, although in ACL I am denied to have access? In this case I am talking only about ACL without using the new feature private data collections.
I appreciate any help.
Thank you very much.
Nothing can prevent you from reading the data that you have locally, if you have access to that data.
ACL enforcement in Hyperledger Fabric works via policy evaluation - an ACL is just a policy, and for every action that a network node (peer or orderer) performs - it consults the policy to determine if the requester of the data is eligible according to the policy.
Note, that any data segregation mechanism may be not enough by its own, if the data may be obtained via other actions that have permissive policies. A good example for that is if you have a chaincode that checks that the client originates from a certain organization, but that client's certificate satisfies the "channel readers" policy - then the client can just request the block from the ordering service itself - and just compute the data that the client wants on its own after reading the data blocks.
Every peer can read from his local data but when it comes to data that is stored on ledger peers can't read that data without permission. Actually you as a peer only can access and store some part of ledger that is available not the whole of that.
In the Fabric-ca-server-config.yaml, i see following comment in registry section
2) once authenticated, **retrieves the identity's attribute names and
# values which the fabric-ca-server optionally puts into TCerts
# which it issues for transacting on the Hyperledger Fabric blockchain**.
# These attributes are useful for making access control decisions in
# chaincode.
My question is how to make it compulsory for ca sever to add these attribute to Tcerts?
For the default setting roles and attributes are not included in the generated certificates
Although the fabric-ca-server supports putting attributes in tcerts (transaction certificates), the clients including SDKs do not yet support using tcerts. They currently always use ecerts (enrollment certificates). There is a jira item which would allow putting attributes into ecerts also. See https://jira.hyperledger.org/browse/FAB-3752. You can track the progress and make any additional requests via jira.
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.