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.
Related
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 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
When I try to create a channel using Hyperledger Fabric, the request fails and returns the following error:
Client logs:
Error: got unexpected status: BAD_REQUEST -- error validating channel creation transaction for new
channel 'testchannel', could not succesfully apply update to template configuration: error
authorizing update: error validating DeltaSet: policy for [Group] /Channel/Application not
satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy
requires 1 of the 'Admins' sub-policies to be satisfied
This error occurs when there is a problem with the identity (consisting of MSP ID, certificate, and keys) that submitted the request. If you use the default Fabric configuration policies, channels need to be created by organization administrators. The error is produced by your identity not being able to satisfy default policy on the /Channel/Application/Admins path.
There are several reasons why the policy would reject your identity, including the use of invalid or expired certificates. You can learn more about why the request failed by looking at your orderer logs. The Ordering Service is the node that enforces the policies that create or update channels.
When you examine your orderer logs, look for an error that is similar to what was returned to your client. You may find an error from a certificate check immediately preceding the policy error (Principal deserialization failure). This implies that the channel creation was rejected because the MSP ID was not recognized as valid.
Ordering Service logs:
2019-08-06 15:31:43.589 UTC [cauthdsl] deduplicate -> ERRO 021 Principal deserialization failure
(MSP SampleOrg is unknown) for identity 0
2019-08-06 15:31:43.589 UTC [orderer.common.broadcast] ProcessMessage -> WARN 022 [channel:
testchannel] Rejecting broadcast of config message from 172.27.0.7:34750 because of error: error
validating channel creation transaction for new channel 'testchannel', could not succesfully apply
update to template configuration: error authorizing update: error validating DeltaSet: policy for
[Group] /Channel/Application not satisfied: implicit policy evaluation failed - 0 sub-policies
were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied
The error before the policy warning, ERRO 021 Principal deserialization failure (MSP SampleOrg is unknown) for identity 0, indicates that the MSP ID that was passed as a parameter with the request was not recognized by the ordering service. This could be a result of passing the wrong MSP ID to the command. This error may also indicate that your organization has not joined the consortium hosted by the ordering service system channel. If you are updating an application channel, this error could occur if your organization is not yet a member of the channel you are trying to update.
If the MSP ID of the identity is valid, you may encounter the following certificate validation error:
Ordering Service logs:
2019-08-06 15:34:45.730 UTC [cauthdsl] deduplicate -> ERRO 02d Principal deserialization failure
(the supplied identity is not valid: x509: certificate signed by unknown authority) for identity 0
2019-08-06 15:34:45.730 UTC [orderer.common.broadcast] ProcessMessage -> WARN 02e [channel:
testchannel] Rejecting broadcast of config message from 172.27.0.7:36214 because of error: error
validating channel creation transaction for new channel 'testchannel', could not succesfully apply
update to template configuration: error authorizing update: error validating DeltaSet: policy for
[Group] /Channel/Application not satisfied: implicit policy evaluation failed - 0 sub-policies
were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied
In this case, the ordering service recognized your MSP ID, but could not validate that your certificate was issued by one of your organization's certificate authorities. If you are managing multiple organizations, this error could be the result of you using a mismatched MSP ID and certificate to submit the request. This error could also occur if your admin certificates have expired. If this is a test network that has been launched recently, you may be issuing the request from an identity that was created by a certificate authority on an older incarnation of your network.
It will be more common that your certificate has passed the validation check, but could not fulfill the channel creation policy. If that is the case, the error in your orderer logs would look like the following:
Ordering Service logs:
2019-08-06 15:36:52.307 UTC [orderer.common.broadcast] ProcessMessage -> WARN 032 [channel:
testchannel] Rejecting broadcast of config message from 172.27.0.7:37236 because of error: error
validating channel creation transaction for new channel 'testchannel', could not succesfully apply
update to template configuration: error authorizing update: error validating DeltaSet: policy for
[Group] /Channel/Application not satisfied: implicit policy evaluation failed - 0 sub-policies
were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied
The identity that submitted the request is a valid member of your organization, and your organization is recognized to be a member of the system channel or application channel. However, the identity did not have the permission to create a channel. You may have used the wrong identity to submit the request, and used an identity that was not your organization administrator. Submit the request from your admin identity, or create a new admin, and have the channel administrator update your organization MSP.
If you encounter this error for operations other then channel creation, your certificate may not be authorized for the correct role. Check that your client certificates and peer certificates have the client and peer OU respectively.
Additional debugging techniques
If you need additional help debugging a policy or certificate related error, you can increase the logging level related to those components:
FABRIC_LOGGING_SPEC=”WARN:cauthdsl=debug:policies=debug:msp=debug
You can also manually pull your organizations root certificate from an application or system channel and use them to verify your client side certs. Use the following command to pull the latest configuration block from your channel.
peer channel fetch config ./configupdate/config_block.pb -o <orderer_endpoint> -c <my_channel> --tls --cafile <PATH_TO_ORDERER_TLS_CERT>
Then use the following command to convert the configuration block into JSON.
configtxlator proto_decode –type=common.Block --input=config_block.pb --output=config_block.json
This allows you to pull the root certificate from the block using the following command. Replace with the MSP ID of your organization.
jq -r .data.data[0].payload.data.config.channel_group.groups.Application.groups.<MSPID>\
.values.MSP.value.config.root_certs[0] config_block.json | base64 –decode > root.pem
If your MSP defines multiple root certificates or uses intermediate certificates, you will need to adjust the jq command above to properly extract them.
You can then use tools such as OpenSSL to validate your client side admin certificate against the root certificate.
openssl verify -CAFile <root.pem> <admincert.pem>
You can also use the following command to open the certificate and examine it in plaintext. This allows you to check fields such as the expiration date, the node OU, or the issuing CA.
openssl x509 -in <admincert.pem> -text
UTC [orderer.common.broadcast] ProcessMessage -> WARN 009 [channel: orgchannel] Rejecting broadcast of config message from 172.20.20.22:45668 because of error: error validating channel creation transaction for new channel 'orgchannel', could not succesfully apply update to template configuration: error authorizing update: error validating DeltaSet: policy for [Group] /Channel/Application not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied
If you are getting aforementioned error then check your configtx file and verify below mentioned attributes. Copy paste the below section and replace capabilities section.
Capabilities:
# Channel capabilities apply to both the orderers and the peers and must be
# supported by both.
# Set the value of the capability to true to require it.
Channel: &ChannelCapabilities
# V1.4.3 for Channel is a catchall flag for behavior which has been
# determined to be desired for all orderers and peers running at the v1.4.3
# level, but which would be incompatible with orderers and peers from
# prior releases.
# Prior to enabling V1.4.3 channel capabilities, ensure that all
# orderers and peers on a channel are at v1.4.3 or later.
V1_4_3: true
# V1.3 for Channel enables the new non-backwards compatible
# features and fixes of fabric v1.3
V1_3: false
# V1.1 for Channel enables the new non-backwards compatible
# features and fixes of fabric v1.1
V1_1: false
# Orderer capabilities apply only to the orderers, and may be safely
# used with prior release peers.
# Set the value of the capability to true to require it.
Orderer: &OrdererCapabilities
# V1.4.2 for Orderer is a catchall flag for behavior which has been
# determined to be desired for all orderers running at the v1.4.2
# level, but which would be incompatible with orderers from prior releases.
# Prior to enabling V1.4.2 orderer capabilities, ensure that all
# orderers on a channel are at v1.4.2 or later.
V1_4_2: true
# V1.1 for Orderer enables the new non-backwards compatible
# features and fixes of fabric v1.1
V1_1: false
# Application capabilities apply only to the peer network, and may be safely
# used with prior release orderers.
# Set the value of the capability to true to require it.
Application: &ApplicationCapabilities
# V1.4.2 for Application enables the new non-backwards compatible
# features and fixes of fabric v1.4.2.
V1_4_2: true
# V1.3 for Application enables the new non-backwards compatible
# features and fixes of fabric v1.3.
V1_3: false
# V1.2 for Application enables the new non-backwards compatible
# features and fixes of fabric v1.2 (note, this need not be set if
# later version capabilities are set)
V1_2: false
# V1.1 for Application enables the new non-backwards compatible
# features and fixes of fabric v1.1 (note, this need not be set if
# later version capabilities are set).
V1_1: false
Also check your channel name
export SYS_CHANNEL=orgchannel #should be your own system channel name
export CHANNEL_NAME=org1orgchannel #should be your own system channel name
export CHANNEL_ID=org1orgchannel #should be your own system channel name
Also remember SYS_CHANNEL value should be different from CHANNEL_NAME. CHANNEL_NAME and CHANNEL_ID should be same.
If still getting issue mail me on actachieverepeat#gmail.com.
Trying to add a new organisation from a separate host.(Modifying steps from ./eyfn.sh when necessary).
Managed to create and import network admin card using Hyperledger Composer. (https://medium.com/#mahoney_33893/hyperledger-composer-adding-another-organization-to-an-existing-running-multi-organization-fff5c8104a82).
However when pinging the network I got:
Error: Error trying to ping. Error: 2 UNKNOWN: access denied: channel [composerchannel] creator org [Org3MSP]
Upon getting the logs from peer I got
-Principal deserialization failure (MSP Org3MSP is unknown) for identity
-[channel: composerchannel] Client authorization revoked for deliver request from 10.0.1.6:48262: Failed evaluating policy on signed data during check policy on channel [composerchannel] with policy [/Channel/Application/Readers]: [Failed to reach implicit threshold of 1 sub-policies, required 1 remaining]
My problem is actually similar to that of Hyperledger-Composer: Getting "access denied" when pinging network admin card.
The solution did mention to include msp files of my new org into volumes of the orderer which I did as
docker cp msp <containername>:/etc/hyperledger/msp/peerOrganizations/org3.example.com
My first organisation was set up using the default ./startFabric.sh
Take note that im not using TLS for the time being.
The error still persist though and Im wondering why. I do however suspect that the way im giving msp to the orderer is somehow wrong. or Im putting it in a wrong file.
Maybe you will need to migrate from Composer to other framework.
Hundreds of devs are taking is using Convector. Convector is a Hyperledger Labs project that was created before Hyperledger Composer was deprecated but that looks similar to developers. It follows a model controller pattern (similar to Composer assets and transactions) however it compiles natively to Fabric code and does not create a runtime.
Please have a look into my issue .I am using hyperledger fabric 1.2 . I am exploring ACL at the time of channel creation. I just copied default Writers Policy and rename it with PankajPolicy and put into the Channel.Application in configtx.yaml see here.
Now the issue is that I just replaced peer/Propose: /Channel/Application/Writers With PankajPolicy in peer/Propose: /Channel/Application/PankajPoilicy. For complete configtx.yaml please have a look see here.
When i create genesis block with this and trying to create the channel evrything goes fine .But at the time of query am getting error
Error: error endorsing query: rpc error: code = Unknown desc = failed evaluating policy on signed data during check policy [/Channel/Application/PankajPoilicy]: [policy /Channel/Application/PankajPoilicy not found] - proposal response: <nil>
Instead if something is wrong then it should stop on write operation means at the time of peer chaincode instansiate.
Thanks in advance !!!
You created your own policy. So according to the comment on sample configtx.yaml
Policies defines the set of policies at this level of the config tree
# For Channel policies, their canonical path is
# /Channel/<PolicyName>
Your custom defined policy will be accessible on this path /Channel/<PolicyName>
Please use this peer/Propose: /Channel/PankajPoilicy
instead of this
peer/Propose: /Channel/Application/PankajPoilicy
I do not know why your write operations are working with the current configuration.