I am reading the HLF document,In document they have policy for channel and chain-code. HLF also have Access control list and Attribute based Access Control. What is major difference and when and where Attribute based Access Control will be used and how to implement it.
hyperledger fabric is permission based blockchain. So to achieve permissions fabric provide support for permission at network config level (Policies)as well as chaincode level(ABAC or Private Data).
first of all I will explain network config level:
Form Docs:policy is a set of rules that define the structure for how decisions are made and
specific outcomes are reached. To that end, policies typically describe a who and
a what, such as the access or rights that an individual has over an asset. We can
see that policies are used throughout our daily lives to protect assets of value
to us, from car rentals, health, our homes, and many more.
Policies are defined in confgtx.yaml file as follows:
Policies:
Readers:
Type: Signature
Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')"
Writers:
Type: Signature
Rule: "OR('Org1MSP.admin', 'Org1MSP.client')"
Admins:
Type: Signature
Rule: "OR('Org1MSP.admin')"
Organization , channel , orderer and application component has their own policies.
Foe more explination : https://hyperledger-fabric.readthedocs.io/en/master/policies/policies.html
you can also check out first-network from fabric samples where they have used policies in configtx.yaml file so you can understand it easily.
Attribute Based Access Control(ABAC):
ABAC is used where developer wants to implement access restriction at chaincode level. for example if some asset is only allow to those users, they have attribute agent. then you can use ABAC.
ABAC is very related with fabric-ca because attributes are defined in ca certificates. the huperledger fabric run time extract attribute from user request proposal and provide it to chaincode then chaincode validate it.
to use it you have to import CID(Client Identity) library in your chaincode file.(Note: keep in mide you to download CID lib if not found, keep vendor dir within chaincode dir)
Link to CID Docs:https://godoc.org/github.com/hyperledger/fabric/core/chaincode/lib/cid
Link to github page:https://github.com/hyperledger/fabric/blob/release-1.1/core/chaincode/lib/cid/README.md
Related
I want 4 intermediate CAs for a peer organization: ICA1, ICA2, ICA3 and ICA4 - one for every Node OU (peer, orderer, admin and client).
Let's say if I place ICA1 as the cacerts attribute in the Peer Node OU of the channel configuration, then will a peer identity under a different ICA (ICA2, ICA3 or ICA4), be able to satisfy a policy which says signature of "OrgMSP.peer"?
If yes, then how can I make sure that only the set of roles under a specific department can satisfy a policy given by OrgMSP.<role>? I do not wish to create an MSP definition for every department or team in the organization. So, is it achievable without that?
If no, then can I also specify a group of ICAs in the Node OU configuration of the channel for a particular OU so that I can leverage very complex policies like "Signature of one-of 'OrgMSP.peer'" and let's say that here, cacerts property for the peer OU will be ICA1 and ICA3. Is this achievable?
When you specify the nodeOU configuration, you may simply supply the OU name corresponding to the role (it sounds like this is what you've done), or you may specify the OU name and an issuing certificate. This could be a root CA, or an intermediate CA, but in either case, in order to satisfy that role, the certificate must have both the OU specified and be issued by the specified CA.
Note: Each role/certificate pair informs the MSP of a valid issuer for certificates satisfying a role. So, if you have CA1, CA2, ICA1, and ICA2, you may specify a given role twice, once for CA1 and once for ICA2. Then only certificates (directly) issued by either CA1 or ICA2 may satisfy the role.
If you look in the sample MSP configuration, you can see that certificate may be specified, but is omitted by default.
You can see more details about how this certificate is used in the actual proto documentation.
I have seen that default mod_policy is set to Admins policy at that level of configuration, however if I want to set it to MyPolicy (which may be any custom valid policy) then how to do that?
Can I achieve it in configtx.yaml itself?
Yes, this could be done. You can check the article which shows how to create a new custom policy and how to update the ACL from configtx.yaml only.
I could achieve this successfully by following the below steps:
Started the fabric-samples/first-network.
Perform docker exec into the cli container.
Set the environment corresponding to peer0.org1.example.com and that organization's admin user: Admin#org1.example.com. Fetch the latest application channel (here mychannel) configuration block.
Edit the decoded JSON block by changing the mod_policy value under the policies section for the Org1MSP under the Application group. Change it from Admins to Readers.
Submit the channel update transaction by encoding and signing the delta block into a protobuf envelope.
Now, our task is to verify this new mod_policy is working fine or not. For this, do the following:
Set the cli environment to peer0.org1.example.com and that organization's user: User1#org1.example.com. Fetch the latest application channel (here mychannel) configuration block.
Edit the decoded JSON block by changing the Readers policy in the Org1MSP from "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')" to "OR('Org1MSP.admin', 'Org1MSP.peer')" by keeping the JSON syntax of policies in mind.
Submit the channel update transaction. The successful update denotes that the Readers policy (the new mod_policy for that section) was satisfied as we submitted the channel update on behalf of the User1#org1.example.com (a client user). Note that while updating channel configuration at this moment, the Readers policy will be evaluated as "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')" as the update has not been processed.
Now using the same cli environment, try to fetch the latest application channel configuration block. The following error appears:
2020-04-09 22:25:48.990 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
2020-04-09 22:25:49.001 UTC [cli.common] readBlock -> INFO 002 Got status: &{FORBIDDEN}
This is because now to read the configuration block, User1#org1.example.com with client OU won't be able to satisfy the new Readers policy i.e. "OR('Org1MSP.admin', 'Org1MSP.peer')".
I'm trying to query channel info with node sdk (https://fabric-sdk-node.github.io/release-1.4/Channel.html - channel.queryInfo()).
I have two networks setup (Network setup not done by me. So, I don't know what are the differences).
In one network, I'm able to query successfully.
In the other one, I'm getting this error:
Error: access denied for [GetChainInfo][ ]: [failed
evaluating policy on signed data during check policy
[/Channel/Application/Readers]: [Failed to reach implicit threshold of
1 sub-policies, required 1 remaining]]
But, when I call with useAdmin=true, i.e., channel.queryInfo(undefined, true) it works. I'm wondering what could cause such error in one network and not in the other. Is there any params that is passed while creating the channel to allow/disallow non admins from querying?
The ACL of a channel has the default field of
#ACL policy for qscc's "GetChainInfo" function
qscc/GetChainInfo: /Channel/Application/Readers
And the Reader of each org is defined in the configtx.yaml like
Policies: &org1Policies
Readers:
Type: Signature
Rule: "OR('org1.example.com.member')"
It looks like here is where your problem might be. Make sure Readers is .member not .admin of the OrgMSP.
If I have 1 organization orgA, and under this organization I have 2 user: user1 and user2, also there is 1 peer in orgA, lets call it peer0.
Now imagine, user1's certificate is in orgA's msp/admincerts forlder, that makes user1 admin for orgA. On the other hand lets say user2's certificate is in peer0's msp/admincerts folder, that makes user2 admin for peer0.
My question is what is the difference in privileges between user1 and user2, I mean what user1 can do and what user2 can't do and vice versa?
Also I am using fabic ca and node sdk to interact with network. In my example when I enroll fabric ca's bootstraped user (admin/adminpw) from nod sdk, and then make create channel request, it worked, but then when I make join channel request it failed (because this user don't have privileges). When I tried to understand why this happened, I discover that if I make join request from user that's certificate is not in peer's msp/admincerts folder, that kind of user don't have permission to make peer to join channel. So only way is I have to copy enrolled admin's certificate into peer0's msp/admincerts folder, then I think it will work, but is it an only way to make it work, or is there any other way to avoid copy/paste and to it from sdk, or create new configuration update transaction?
Also I can't understand what makes this user capable of creating channel? what permissions does bootsraped user from fabric ca has?
This is a very late reply but hope someone may find this helpful. The user roles and the permissions aren't directly linked, this is done through the policies set in the configtx.yaml.
Policies are defined for each Org and Orderer, marking each of the member and admin to a certain set of policy subgroup like Readers or Writers or Admins.These are the grassroot level policies used to construct ImplicitMeta policies like for chiancode query and write.
For example, an org defines policy like
# Policies defines the set of policies at this level of the config tree
# For organization policies, their canonical path is usually
# /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
Policies: &org1Policies
Readers:
Type: Signature
Rule: "OR('org1.example.com.member')"
# If your MSP is configured with the new NodeOUs, you might
# want to use a more specific rule like the following:
# Rule: "OR('org1MSP.admin', 'org1MSP.peer')"
Writers:
Type: Signature
Rule: "OR('org1.example.com.member')"
# If your MSP is configured with the new NodeOUs, you might
# want to use a more specific rule like the following:
# Rule: "OR('org1MSP.admin', 'org1MSP.client'')"
Admins:
Type: Signature
Rule: "OR('org1.example.com.admin')
The Policies for the consortium is defined like:
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
This references the org and orderer policies defined earlier.
Now in the system chaincode can have policies like:
Application: &ApplicationDefaults
ACLs: &ACLsDefault
#This section provides defaults for policies for various resources
#in the system.
#---Query System Chaincode (qscc) function to policy mapping for access control---#
#ACL policy for qscc's "GetChainInfo" function
qscc/GetChainInfo: /Channel/Application/Readers
#ACL policy for qscc's "GetBlockByNumber" function
qscc/GetBlockByNumber: /Channel/Application/Readers
Here the policies referenced point to consortium policies.
Please read docs for more detailed guidance on this.
I was trying to understand ACL in Hyperledger Fabric v1.3. I read configtx.yaml and I saw the channel section described below:
Channel: &ChannelDefaults
# Policies defines the set of policies at this level of the config tree
# For Channel policies, their canonical path is
# /Channel/<PolicyName>
Policies:
# Who may invoke the 'Deliver' API
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
# Who may invoke the 'Broadcast' API
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
# By default, who may modify elements at this config level
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
As per documentation it is mentioned for Readers # Who may invoke the 'Deliver' API and for Writers # Who may invoke the 'Broadcast' API. I am not able to understand what Deliver API and what Broadcast API do.
Please let me know if anyone know.
Ordering service nodes implement two APIs:
Broadcast - the API for submitting transactions to the orderer
Deliver - the API for receiving blocks from the orderer
Typically clients use the broadcast API and peer nodes use the deliver API.
Separating the policies allows you to permit certain clients / apps to only submit transactions but not be able to actually receive blocks and vice versa - peers would be able to consume blocks but not be able to submit transactions to the orderer.