策略管理和访问控制

1. 概述
2. 策略的定义以及类型
3 交易背书策略

3.1 交易背书策略的验证

3.1.1 如何实现验证原则?
3.1.2 基于MSP角色验证：MSPPrincipal_ROLE
3.1.3 基于MSP的部门验证：MSPPrincipal_ORGANIZATION_UNIT
3.1.4 基于身份证书的验证：MSPPrincipal_IDENTITY

3.2 给链码指定背书策略
3.3 链码实例化策略
3.4 通道管理策略

参考书籍:《深度探索区块链：Hyperledger技术与应用》 @著张增骏董宁朱轩彤陈剑雄

1. 概述

策略管理，是一种权限控制，包括交易背书策略、链码实例化策略、通道管理策略等

2. 策略的定义以及类型

策略定义

type policy struct {
	Type int32 		// 策略类型
	Value []byte		// 策略内容
}

策略可以使用条件来组合
AND：eg: AND(‘Org1.Admin’,‘Org2.Member’) 要求2个MSP标志Org1，Org2 都要有一个签名
OR：eg: OR(‘Org1.Admin’,‘Org2.Member’)要求2个MSP标志Org1，Org2 任何一个有签名

NOutOf: eg: NOutOf(1,‘Org1.Admin’,‘Org2.Member’) 表示满足一个Org1的admin节点或者Org2中的一个成员节点有签名。等价于OR(‘Org1.Admin’,‘Org2.Member’)

策略类型有两种

SignaturePolicy: 签名策略，验证签名数据是否符合规则。支持的条件AND、OR、NOutOf。其中的NOutOf表示。
ImplicitMetaPolicy: 隐含元策略。在SignaturePolicy的基础上支持大多数组织管理员，这种策略只适合于通道管理

SignaturePolicy策略其实只有SignedBy和NOutOf两种。AND、OR都会转换为NOutOf

SignaturePolicy

type SignaturePolicy struct {
	// 支持类型
	// SignautrePolicy_SignedBy
	// SignautrePolicy_NOutOf_
	Type is SignautrePolicy_Type `protobuf_oneof:"Type"`
}

ImplicitMetaPolicy 是递归策略的定义方法，名称中的Implicit说明规则由子策略生成，Meta说明策略依赖其他策略的验证结果

type ImplicitMetaPolicy struct{
	SubPolicy string  						// 子策略名称
	Rule ImplicitMetaPolicy_Rule		// 策略规则
}

ImplicitMetaPolicy_Rule有三种形式

ImplicitMetaPolicy_ANY: 任意一个子策略成立就满足
ImplicitMetaPolicy_ALL：全部子策略成立才满足
ImplicitMetaPolicy_MAJORITY：大多数的子策略成立就满足
大多数的计算方式
threshold = len(subPolicys) / 2 + 1

3 交易背书策略

交易背书策略是对交易进行背书的规则，跟通道和链码相关，在链码实例化时指定。在链码调用的时候，需要从背书节点收集足够的签名背书。只有通过背书策略的交易才是有效的。

3.1 交易背书策略的验证

背书是由一组签名组成的，每个peer接收到区块时，都能根据交易的内容本地验证背书是否符合背书策略，不需要和其他节点交互。验证原则

所有的背书都有效，验证消息用又掉的证书进行正确的签名
满足背书策略的有效背书数量，转换为NOutOf格式进行比较
背书是期望的背书节点签名的，在背书策略中指定了哪些组织的哪些角色是有效的背书节点。

3.1.1 如何实现验证原则?

条件语法有AND OR 和NOutOf
其中AND 和OR 都可以转化成NOutOf
AND(A,B) 等价于 NOutOf(2,A,B)
OR(A,B)等价于NOutOf(1,A,B)
背书策略定义如下

type SignaturePolicyEnvlope struct {
	Version int32											// 背书策略版本，默认0
	Rule *SignaturePolicy								// 背书策略规则：签名策略
	Identities []common1.MSPPrincipal		// 背书策略主体：MSP主体签名
}

其中MSPPrincipal定义如下

type MSPPrincipal struct {
	PrincipalClassification MSPPrincipal_Classification  // MSP类型
 	Principal []type // 不同的MSP类型。实体包含不同的内容
}

MSP类型有三种

MSPPrincipal_ROLE: 基于MSP角色的验证方法，目前只有admin 和 member两种
MSPPrincipal_ORGANIZATION_UNIT: 基于部门的验证方法，同一个MSP中的不同部门
MSPPrincipal_IDENTITY：基于某个具体的身份证书验证。

3.1.2 基于MSP角色验证：MSPPrincipal_ROLE

两中情况，一种是admin角色一种是member角色

MSPRole_MEMBER: 验证是否为同一个MSP的有效签名
MSPRole_ADMIN: 验证签名者是否是MSP设置好的Admin成员。

3.1.3 基于MSP的部门验证：MSPPrincipal_ORGANIZATION_UNIT

验证步骤

验证是否为相同的MSP
验证是否都是有效的证书
验证组织部门信息是否匹配

3.1.4 基于身份证书的验证：MSPPrincipal_IDENTITY

只验证是否为有效证书就可以了。

3.2 给链码指定背书策略

指定背书策略可以使用-P参数。

peer chaincode install -C myc -n mycc -p github.cpm/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -c '{"Args":["int","a","100","b","200"]}' -P "AND('Org1.member','Org2.member')"

3.3 链码实例化策略

这个策略是用来判断是否有权限对链码进行实例化和升级的。是在对链码进行打包和签名的时候指定的，如果没有指定默认是只有通道管理员可以实例化。

3.4 通道管理策略

在这里插入图片描述
在使用configtxgen工具生成创世区块或者通道配置时，使用的默认策略

摘录来自: 张增骏. “深度探索区块链：Hyperledger技术与应用 (区块链技术丛书)。”

来源：CSDN

作者：LH_0811

链接：https://blog.csdn.net/qq_30110435/article/details/104399150

标签

edg战队

十四、区块链学习-Hyperledger Fabric (基于release-1.0) 策略管理和访问控制