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.
Related
Chain code life cycle endorsement is not working when following changes made in configtx.yaml.
LifecycleEndorsement:
Type: ImplicitMeta
Rule: "ANY Endorsement"
Endorsement:
Type: ImplicitMeta
Rule: "ANY Endorsement"
Network contains:
one ordering service cluster with five orderers running Raft
three organizations (Org1, Org2 and Org3), each of which has one peer (peer0)
one channel mychannel is created, and peers in all organizations join the channel
Package SACC into chaincode package
Install chaincode package to peers of all the three organizations
Org1 approves chaincode package, and tries to commit the chaincode. It fails and getting Endorsement policy error.
But chain code should be commited as LifecycleEndorsement has "Any Endorsement" rule.
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
I am using farbic CA server for register client,member,peer using the farbic node js.
While doing the registration process i am passing the role type which User,Memeber,Client. After that i do enrol which create the certificate, private,public key in wallet. I have setup the fabric network and peer has join the channel, even i have install and initiate the fabcar
My question is
If i register and enrol the user with role type client, i can query the fabcar chaincode, but if i register the user with role type member it's give me error.
what is difference between member vs client vs user
channel [channel-all]: creator certificate is not valid: could not validate identity's OUs: the identity must be a client, a peer, an orderer or an admin identity to be valid, not a combination of them
Configtx.yaml file i have already mention the policy type
- &Org1
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: Org1MSP
# ID to load the MSP definition as
ID: Org1MSP
MSPDir: crypto-config/peerOrganizations/org1.avantas.com/msp
# 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:
Readers:
Type: Signature
Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client', 'Org1MSP.member')"
Writers:
Type: Signature
Rule: "OR('Org1MSP.admin', 'Org1MSP.client', 'Org1MSP.member')"
Admins:
Type: Signature
Rule: "OR('Org1MSP.admin')"
# leave this flag set to true.
AnchorPeers:
# AnchorPeers defines the location of peers which can be used
# for cross org gossip communication. Note, this value is only
# encoded in the genesis block in the Application section context
- Host: peer0.org1.avantas.com
Port: 7051
#fama
use below my attributes while registring admin
"type":"user",
"affiliation":"orgName",
"attributes":[{
"name":"admin","value":"true","ecert":true
},
and make corrections below
Policies:
Readers:
Type: Signature
Rule: "OR('Org1MSP.member')"
Writers:
Type: Signature
Rule: "OR('Org1MSP.member')"
Admins:
Type: Signature
Rule: "OR('Org1MSP.admin')"
I am trying to create my own fabric network by taking reference of "basic network" and "First Network" provided in "fabric-samples"
I have came across section called "Policies" in "configtx" yaml file.
Kindly help me to understand significance of this section.
Policies are basically rules/definations that govern access control within a channel. They are of two types
Signature - You may have seen policies of this sort (using terms like AND,OR etc. and is more flexible than Implicit Meta Policies)
Implicit Meta - Less Flexible (Using terms like ANY,MAJORITY etc.)
Examples
1. Signature
Organizations:
- &Orderer
Name: Orderer
# ID to load the MSP definition as
ID: OrdererMSP
MSPDir: crypto-config/ordererOrganizations/example.com/msp
Policies:
#THIS IS WHERE YOU DEFINE THEM
# SIGNATURE POLICIES USE TERMS LIKE OR,AND,NOutOf etc.
Readers:
Type: Signature
Rule: "OR('OrdererMSP.member')"
Writers:
Type: Signature
Rule: "OR('OrdererMSP.member')"
Admins:
Type: Signature
Rule: "OR('OrdererMSP.admin')"
Implicit Meta
Application: &ApplicationDefaults
# Organizations is the list of orgs which are defined as participants on
# the application side of the network
Organizations:
# Policies defines the set of policies at this level of the config tree
# For Application policies, their canonical path is
# /Channel/Application/<PolicyName>
# ImplicitMeta Policy types use ANY,Majority etc.
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
You can read more about them here on the hyperledger fabric read the docs :- https://hyperledger-fabric.readthedocs.io/en/release-1.3/policies.html
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.