In this tutorial, you'll learn how to configure and dynamically update the access control list (ACL) of the Hyperledger Fabric block chain.The tutorial is divided into two parts: 1. Understanding and configuring the access control list for Hyperledger Fabric 2. Dynamically updating the access control list in the channel configuration.We will introduce the default ACL content and format in fabrics to manage the configuration of channel ACLs in the role of channel administrator.

1. Basic concepts of Hyperledger Fabric access control list/ACL

There are two types of access control policies in Hyperledger Fabric:

• Signature policy: Signature Policies
• Implicit Meta Policies

The signature policy identifies a specific user by checking the signature in the request.For example:

Policies:
  MyPolicy:
    Type: Signature
    Rule: "Org1.Peer OR Org2.Peer"

Key words supported by signature policies include AND, OR, and NOutOf, which can be used to combine powerful access control rules, such as:

• The request signed by the Administrator of Agency A can be released
• Requests signed by more than half of administrators in 20 agencies can be released

Implicit meta-policy defines access control rules by aggregating descendant signature policies, which support default access rules such as "Requests signed by more than half of institutional administrators can be released".The implicit meta-policy is defined similarly but slightly differently from the signature policy in the following form:

<ALL|ANY|MAJORITY> <sub_policy>

Here is an example of an implicit meta-strategy:

Policies:
  AnotherPolicy:
    Type: ImplicitMeta
    Rule: "MAJORITY Admins"

2. Default Access Control List for Hyperledger Fabric

The default access control rules are defined in configtx.yaml for configtxgen to generate channel configurations.Officially provided configtx.yaml example Line 35 defines the signature policy, line 194 the implicit meta policy, and line 131 the access control list/ACL.

3. Customize Access Control List for Hyperledger Fabric

Let's edit the Application: ACLs section in configtx.yaml to modify the following:

peer/Propose: /Channel/Application/Writers

For:

peer/Propose: /Channel/Application/MyPolicy

MyPolicy is defined as follows:

Policies: 
    Readers:
        Type: ImplicitMeta
        Rule: "ANY Readers"
    Writers:
        Type: ImplicitMeta
        Rule: "ANY Writers"
    Admins:
        Type: ImplicitMeta
        Rule: "MAJORITY Admins"
    MyPolicy:
        Type: Signature
        Rule: "OR('Org1MSP.client')"

The MyPolicy policy states that only the Client role can perform the corresponding task.

Don't forget to generate and update CA and Administrator certificates.

Now let's try calling the chain code from the Org1Client:

Now use Org2Client to call the chain code:

It is clear that peer/propose no longer accepts calls from Client in ORG2.

4. Update the ACL configuration of the Hyperledger Fabric channel dynamically

There are two ways to update access control policies:

• Edit configtx.yaml only for subsequently established new channels
• Update ACL configurations in specific channels directly, applicable to existing channels

Below we will show how to update the access control list configuration in an existing channel.

Before you do the following, remember to start your Hyperledger Fabric network.

4.1 Access Command Line Interface

Hyperledger Fabric has an automatically created cli container that provides command line interfaces for operating nodes.Execute the following command to enter the CLI interface:

docker exec -it cli bash

Then set the environment variables the program needs to use:

export CHANNEL_NAME=mychannel
export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
export CORE_PEER_ADDRESS=peer0.org1.example.com:7051
export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
export ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

4.2 Get the current configuration of the specified Fabric channel

Execute the following command to get the current configuration of the channel and write to the file config_block.pb:

peer channel fetch config config_block.pb -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA

4.3 Convert Channel Configuration to JSON Format

config_block.pb is binary encoded block configuration data, which we will first convert to Easy to view, modify JSON format:

configtxlator proto_decode --input config_block.pb --type common.Block | jq .data.data[0].payload.data.config > config.json

4.4 Create a JSON copy of the channel configuration for modification

Subsequent modifications will be made on the copy modified_config.json:

cp config.json modified_config.json

4.5 Modify channel configuration for JSON replicas

You can use any editor you like to modify the JSON copy, such as vim:

vim modified_config.json

We changed the description of MyPolicy from Org1MSP to Org2MSP:

Remember to save the changes.

4.6 Convert a modified copy of the channel configuration JSON to binary format

configtxlator proto_encode --input modified_config.json --type common.Config --output modified_config.pb

4.7 Convert config.json to block binary format

configtxlator proto_encode --input config.json --type common.Config --output config.pb

4.8 Generate channel configuration differences before and after modification

configtxlator compute_update --channel_id $CHANNEL_NAME --original config.pb --updated modified_config.pb --output diff_config.pb

4.9 Convert the different parts of the configuration to JSON format

configtxlator proto_decode --input diff_config.pb --type common.ConfigUpdate | jq . > diff_config.json

4.10 Encapsulate Fabric Configuration Update Message

echo '{"payload":{"header":{"channel_header":{"channel_id":"mychannel", "type":2}},"data":{"config_update":'$(cat diff_config.json)'}}}' | jq . > diff_config_envelope.json

4.11 Convert configuration update messages to binary format

configtxlator proto_encode --input diff_config_envelope.json --type common.Envelope --output diff_config_envelope.pb

4.12 Signature Configuration Update Message

First, sign with the administrator of Org1 to set the environment variable:

export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
export CORE_PEER_ADDRESS=peer0.org1.example.com:7051
export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt

Then sign:

peer channel signconfigtx -f diff_config_envelope.pb

Then sign as the administrator of Org2 and set the environment variable:

export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp
export CORE_PEER_ADDRESS=peer0.org2.example.com:7051
export CORE_PEER_LOCALMSPID="Org2MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt

Signature:

peer channel signconfigtx -f diff_config_envelope.pb

4.13 Submit channel configuration updates

Submit a channel update transaction to the sorting node by executing the following command:

peer channel update -f diff_config_envelope.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls --cafile $ORDERER_CA

Now let's check the effect.First call the chain code with the Client of Org1:

It was a failure.Next, call the chain code with the Client of Org2:

As expected, it succeeded.

Original Link: Configuration and Update of the Hyperledger Fabric Access Control List - Smart Network