ELI5 please. Why ACL policies in example https://github.com/hyperledger/fabric/blob/release-1.2/sampleconfig/configtx.yaml specified in different places (in "organizations", "orderer", "channel" and "application" sections)? What does mean these levels? What is the difference?
In which cases which one should I use? And why in some blocks only policies defined, but in other policy + ACL ("application" section)?
PS: what the difference between channel and org, orderer policies? For example, what happens when I specify "MAJORITY admins" on channel section, "ANY members" on channel and "ANY admins" on org section? What will change in this case for me as an application developer?
ACL(Access Control List) policies are defined as per different logical structures (namely channels,orderers etc.) so you have more control for each of these logical structures and you can define which identities on your network can do what kind of operations ( for simplicity considering them to be Writing, Reading or Admin Related Operations) for each of these units separately.
So as an application developer too, you need to be specific of the policies you define. The keywords(ImplicitMeta policy definers) ANY, ALL and MAJORITY define how many signatures you need to satisfy the policy. For example, if you want to add an organization to your channel in an already running network, you will be needing a few signatures from Admins (which is defined as admin identities from SampleOrg in your cited link). The number of these few signatures depend on the choice of this keyword at network bootstrap time, if you use ANY , even a single signature would do your job whereas MAJORITY would require signatures from a majority of the specified existing identities and ALL would require signatures from all the desired existing identities. Failing in getting the desired number of signatures would leave the policy unsatisfied and hence this operation/transaction won't be successfull.
As in the above case we were trying to make a change at channel level,we can also make changes at orderer level or so and hence we have separate policies for the Access Control. You might get a clearer view on this via the official docs :Here
the ACL policies are written to refer to the policies in the channel configuration. The channel/application path is is the section of the configuration. The syntax is a bit obscure, but channel/application/readers refers to allowing the readers on the channel to access the resource governed by the policy, while channel/application/writers restricts the resource to writers on the channel.
You can learn more about the ACLs and their syntax here: https://hyperledger-fabric.readthedocs.io/en/latest/access_control.html
Related
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 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.
I am new to hyper ledger and was going through the documentation to get some insight of hyperledger especially in Channel Configuration (configtx) section.
There they defined that
Channel configuration has the following important properties:
Versioned: All elements of the configuration have an associated version which is advanced with every modification. Further, every
committed configuration receives a sequence number.
Permissioned: Each element of the configuration has an associated policy which governs whether or not modification to that element is
permitted. Anyone with a copy of the previous configtx (and no
additional info) may verify the validity of a new config based on
these policies.
Hierarchical: A root configuration group contains sub-groups, and each group of the hierarchy has associated values and policies. These
policies can take advantage of the hierarchy to derive policies at one
level from policies of lower levels.
Can somebody explain me the third point with some example?
Here is the link for above paragraph http://hyperledger-fabric.readthedocs.io/en/release-1.0/configtx.html
The most important way that the channel configuration is hierarchical has to do with policy evaluation. There is a policy type called an "implicit meta policy". This policy type's evaluation depends on the evaluation of policies deeper in the tree.
Take for example the /Channel/Admins policy. The default value for this policy is an implicit meta policy with a rule of MAJORITY Admins. This rule implies that a majority of the sub-groups must have a policy named Admins, which evaluates to true for the /Channel/Admins policy to evaluate to true. In standard application channel, there are two sub-groups: Application and Orderer. Each of these have an Admins policy which is, by default, also MAJORITY Admins. The /Channel/Application/Admins policy will require that the Admins policy of each of the sub-groups evaluates to true. These sub-groups are application organizations, each of which has a default Admins policy which may be satisfied by a signature from one of their admin certs.
So, the end result of this hierarchy is that to satisfy the /Channel/Application/Admins policy, it requires that a majority of the application organizations admins agree. To satisfy the /Channel/Orderer/Admins policy, it requires a majority of the orderer organizations to agree. And finally to satisfy the /Channel/Admins policy requires that both a majority of the orderer organizations and a majority of the application organizations agree.
Finally, with these policy behaviors in mind, hopefully the natural organization of the configuration as 'hierarchical' makes sense. Configuration elements near the root of the configuration generally require agreement from the entire network to modify. As elements get further from the root and closer to the leaves, the number of stakeholders diminishes, and modifications can be made with less agreement. For instance, an organization may modify its own CRL or CAs without requiring agreement from any other organizations in the network.
I do want to implement my own identity version of MSP. I mean instead of default PKI based Identity validation, signature verification, I would like to do that using token based identity validation and signature verification.
Please let me know if it is possible to override the default certificate based authentication/validation with custom authentication and validation in MSP.
Regards,
vdr
Yes, it is possible to support multiple types of MSPs. The design is to support multiple types of identities (i.e. MSP types) concurrently, not just one at a time. This means that one organization may use the default X509-based type of identities, another organization may use the idemix (short for "Identity Mixer") type of identities, and another organization may use yet another type. These three organizations can transact on a single channel.
An idemix MSP type is currently being implemented which supports advanced crypto based on zero-knowledge proof. You can look at fabric/msp/idemixmsp.go in the master branch to get a feel for how to implement your own MSP type. But before starting, I would encourage you to see if idemix will meet your needs. You could also ask more specific questions on the #fabric-crypto rocket chat channel if you want to learn more about idemix.
Just to re phrase my question:
I am actually working on policy combination and conflicts resolution for distributed networks. As distributed open systems, digital resources can be protected by a
collection of security policies created by different entities which have a different copy
of the resource.
After searching in the web, I used key words such as "Access Control policies", "security policy conflict resolution", but I didn't find many results or even a survey of all different methods
Some approaches to combine policies & resolve conflicts that I found included: "Negative policies prevails", "assign priorities to policies" e.t.c. but not a way to combine or encompass them.
Are there any different current directions to apply AC policies or is just a question of choice between classic policies such those mentioned above?
Thanks in advance!
You need to look at research done in the space of policy-based access control. Look at papers on:
policy-based access control
attribute-based access control
OASIS XACML which implements policy-based access control and policy combining algorithms.
Academics in this field include:
Elisa Bertino from Purdue (DBLP)
Theo Dimitrakos from BT/Kent(DBLP)
Ludwig Seitz from SICS (DBLP)
NIST have also done some extensive research in this space which you can find on their dedicated websites:
Role-based access control
Attribute-based access control