Policy 规则设计

本文主要是讲解一下在fabric中Policy的规则和写法,让大家有一个初步的认识,本文是基于fabric 1.1版本


Policy Type

Policy Type 目前包括两种:SIGNATUREIMPLICIT_META

signature 类型的policy 本质上是由msp principals 构成的 ,可以按照以下的方式去组织policy:5个org中要有4个org admin进行签名。或者”由组织A去签名,或其他两个组织的admin进行签名”。

ImplicitMetaPolicy,此策略类型不如SignaturePolicy灵活,并且仅在配置上下文中有效。 它汇总了在配置层次结构中更深层次评估策略的结果,这些策略最终由SignaturePolicies定义。 它支持良好的默认规则,如“大多数组织管理员策略”。

message Policy {
enum PolicyType {
UNKNOWN = 0; // Reserved to check for proper initialization
SIGNATURE = 1;
MSP = 2;
IMPLICIT_META = 3;
}
int32 type = 1; // For outside implementors, consider the first 1000 types reserved, otherwise one of PolicyType
bytes policy = 2;
}

Configuration and Policies

一个channel中policies是呈一个层次结构的,每一个层次都有一个与之对应的value和policy,下面给出一个示例中,包含两个app组织和一个orderer组织:

Channel:
Policies:
Readers
Writers
Admins
Groups:
Orderer:
Policies:
Readers
Writers
Admins
Groups:
OrdereringOrganization1:
Policies:
Readers
Writers
Admins
Application:
Policies:
Readers
-----------> Writers
Admins
Groups:
ApplicationOrganization1:
Policies:
Readers
Writers
Admins
ApplicationOrganization2:
Policies:
Readers
Writers

箭头指定的策略可以简写为“/Channel/Application/Writers”,最后一个元素说明了Policy的类型,是指定写入策略的。不同的情况会去执行不同的policy,比如说:

  • 一个实例去向orderer投递一个Deliver请求,就需要符合“/Channel/Readers”
  • 普通客户端去执行一个 chaincode Endorsor 类型的交易就需要符合“/Channel/Application/Writers”
  • gossip 协议, 去向peer发送一个gossip某块的请求,就需要符合 “/Channel/Application/Readers”

这些策略在编写的时候都是由多个的Policy嵌套组合在一起的。

构造 Signature Policies

message SignaturePolicyEnvelope {
int32 version = 1;
SignaturePolicy policy = 2;
repeated MSPPrincipal identities = 3;
} message SignaturePolicy {
message NOutOf {
int32 N = 1;
repeated SignaturePolicy policies = 2;
}
oneof Type {
int32 signed_by = 1;
NOutOf n_out_of = 2;
}
}

先看一下policy的部分,SignaturePolicy有AND, OR, and NoutOf 三种模式。oneof 表示结构体中要在两者中填充一个; identities,指定具体实施签名的对象。下面给出两个signatrue policy的示例:

SignaturePolicyEnvelope{
version: 0,
policy: SignaturePolicy{
n_out_of: NOutOf{
N: 2,
policies: [
SignaturePolicy{ signed_by: 0 },
SignaturePolicy{ signed_by: 1 },
],
},
},
identities: [mspP1, mspP2],
}

指定两个签名身份:mspP1、mspP2,需要两个签名,则必然mspP2和mspP2必须签名,相当于AND模式。

SignaturePolicyEnvelope{
version: 0,
policy: SignaturePolicy{
n_out_of: NOutOf{
N: 2,
policies: [
SignaturePolicy{ signed_by: 0 },
SignaturePolicy{
n_out_of: NOutOf{
N: 1,
policies: [
SignaturePolicy{ signed_by: 1 },
SignaturePolicy{ signed_by: 2 },
],
},
},
],
},
},
identities: [mspP1, mspP2, mspP3],
}

翻译成文字的意思就是:三个签名对象(mspP1、mspP2、mspP3),指定要有两个以上的签名,其中mspP1(identities[0])必须签名,mspP2和mspP3中有一个要签名。

注意 : 签名身份未必指定是Admin,可能是一个Member。而且签名策略设计的时候需要注意,比如我们指定了以下策略:

	2 of [org1.Member, org1.Admin]

我们用org1.Admin和org1.User1签名[Admin, User1]后发送交易去验证,会发现仍证失败了。这时因为Admin的签名在先对应了org1.Member,User1对应了org1.Admin自然会失败,如果把两个签名的顺序颠倒就可以验证通过了。

为了避免这种缺陷,应在策略身份排序中从最大特权到最小特权指定标识,上面的策略应指定为:

    2 of [org1.Admin, org1.Member]

更为合理一些。

下面我们再看看结构中的msp principal.

MSP Principals

message MSPPrincipal {

    enum Classification {
ROLE = 0;
ORGANIZATION_UNIT = 1;
IDENTITY = 2;
} Classification principal_classification = 1; bytes principal = 2;
}

msp principal必须被指定为 ROLE或INDETITY,在1.1中尚未实现ORGEANIZATION_UNIT。

ROLE就是按照角色划分的集合:

message MSPRole {
string msp_identifier = 1; enum MSPRoleType {
MEMBER = 0; // Represents an MSP Member
ADMIN = 1; // Represents an MSP Admin
CLIENT = 2; // Represents an MSP Client
PEER = 3; // Represents an MSP Peer
} MSPRoleType role = 2;
}

MEMBER是指定范围最广的:所有由MSP CA签发的证书都可以;

ADMIN: MSP中指定的ADMIN身份

CLIENT(PEER): 由MSP CA 颁发,且organization unit标注为Client(Peer)的证书。

:如果想要指定Client和Peer,需要在cryptogen 产生证书的时候将organization unit设置为true。

IDENTITY就比较简单了,直接指明某个身份,在fabric中就是直接指定公钥证书,通常用的比较少。

这里多解释两句,msp principal是实现policy管理的基础,看起来满复杂实际上和传统的pki体系在作用上类似。本质上是指定一个identities的集合,指定一部分身份(比如说,高一一班所有男同学),在policy校验无非就是说这个身份符合principal指定的集合。详细的内容戳这个链接

构造ImplicitMeta Policies

message ImplicitMetaPolicy {
enum Rule {
ANY = 0; // Requires any of the sub-policies be satisfied, if no sub-policies exist, always returns true
ALL = 1; // Requires all of the sub-policies be satisfied
MAJORITY = 2; // Requires a strict majority (greater than half) of the sub-policies be satisfied
}
string sub_policy = 1;
Rule rule = 2;
}

如同名字所显示的”模糊匹配”规则,它不会像signature那样指定到底是哪个组织或者成员来签署。而是简单的划分为三类:

  • ANY:任何一条子规则符合
  • ALL:所有的子规则都需要符合
  • MAJORITY: 大多数子规则都要符合

    例如我们在channel/Readers下指定一个implicitMeta规则:
ImplicitMetaPolicy{
rule: ANY,
sub_policy: "foo",
}

指定在子策略组中“orderer”、“application”中一个叫做foo的策略,即/Channel/Application/foo 和/Channel/Oderer/foo,校验请求的时候只要满足其中一条即可。

再举一个示例,在/Channel/Application/Writers中指定一个Majority类型的implicit策略:

ImplicitMetaPolicy{
rule: MAJORITY,
sub_policy: "bar",
}

假定application中包含了三个组织Org1、Org2、Org3,即/Channel/Application/Org1/bar、/Channel/Application/Org2/bar、/Channel/Application/Org3/bar,要满足其中的两条。

默认policies

/Channel/Readers : ImplicitMetaPolicy for ANY of /Channel/*/Readers
/Channel/Writers : ImplicitMetaPolicy for ANY of /Channel/*/Writers
/Channel/Admins : ImplicitMetaPolicy for MAJORITY of /Channel/*/Admins /Channel/Application/Readers : ImplicitMetaPolicy for ANY of /Channel/Application/*/Readers
/Channel/Application/Writers : ImplicitMetaPolicy for ANY of /Channel/Application/*/Writers
/Channel/Application/Admins : ImplicitMetaPolicy for MAJORITY of /Channel/Application/*/Admins /Channel/Orderer/Readers : ImplicitMetaPolicy for ANY of /Channel/Orderer/*/Readers
/Channel/Orderer/Writers : ImplicitMetaPolicy for ANY of /Channel/Orderer/*/Writers
/Channel/Orderer/Admins : ImplicitMetaPolicy for MAJORITY of /Channel/Orderer/*/Admins # Here * represents either Orderer, or Application, and this is repeated for each org
/Channel/*/Org/Readers : SignaturePolicy for 1 of MSP Principal Org Member
/Channel/*/Org/Writers : SignaturePolicy for 1 of MSP Principal Org Member
/Channel/*/Org/Admins : SignaturePolicy for 1 of MSP Principal Org Admin

/Channel/Orderer/Admins的admin权限是需要多个orderer组织admin signature policies 组合而成。

参考网址

https://hyperledger-fabric.readthedocs.io/en/release-1.1/policies.html

Hyperledger Fabric 1.1 -- Policy 构成的更多相关文章

  1. Centos7 HyperLedger Fabric 1.4 生产环境部署

    Kafka生产环境部署案例采用三个排序(orderer)服务.四个kafka.三个zookeeper和四个节点(peer)组成,共准备八台服务器,每台服务器对应的服务如下所示: kafka案例网络拓扑 ...

  2. Hyperledger Fabric 架构梳理

    区块链的数据结构 State数据结构 由peer维护,key/value store Ledger  记录了所有成功和不成功的状态更新交易.Ledger被ordering service构造,是一个全 ...

  3. 第6章 Hyperledger Fabric模型

    This section outlines the key design features woven into Hyperledger Fabric that fulfill its promise ...

  4. Hyperledger Fabric链码之三

    在<Hyperledger Fabric链码之一>和<Hyperledger Fabric链码之二>中我们介绍了链码的定义,并通过dev网络测试了测试了自己编写的链码程序. 本 ...

  5. Hyperledger fabric 1.3版本的安装部署(原创多机多Orderer部署

    首先,我们在安装前,要考虑一个问题 Hyperledger Fabric,通过指定的节点进行背书授权,才能完成交易的存储 延伸开来,就是为了实现容错.高并发.易扩展,需要zookeeper来选择排序引 ...

  6. Installing Hyperledger Fabric v1.1 on Ubuntu 16.04 — Part II &  Part III

    This entire tutorial is the second part of the installation of Hyperledger Fabric v1.1. In the previ ...

  7. Hyperledger Fabric CA User’s Guide——开始(三)

    Fabric CA User’s Guide——开始 先决条件 安装Go 1.9+ 设置正确的GOPATH环境变量 安装了libtool和libtdhl-dev包 下面是在Ubuntu上安装libto ...

  8. Hyperledger Fabric 1.2 --- Chaincode Operator 解读和测试(二)

    本文接上一节是测试部分 搭建一个模拟测试环境 作者将fabric release1.2工程中的 example-e2e进行了改造来进行本次实验: (1)首先我们将examples/e2e_cli/sc ...

  9. Hyperledger Fabric 1.2 --- Chaincode Operator 解读和测试(一)

    前言 本文主要目的是用于整理Hyperledger  Fabric中关于chaincode 管理和操作的内容,作者以release-1.2为范本进行讲解. 主要参考链接: https://hyperl ...

随机推荐

  1. LCG(linear congruential generator): 一种简单的随机数生成算法

    目录 LCG算法 python 实现 LCG算法 LCG(linear congruential generator)线性同余算法,是一个古老的产生随机数的算法.由以下参数组成: 参数 m a c X ...

  2. RabbitMQ镜像队列初始化连接时的“优化”

    之前发过一篇帖子应用.Net+Consul维护RabbitMq的高可用性,然后最近老大问我当初我这么搞是抽的什么想法- -然后顺便贴了两行C#代码: var factory = new Connect ...

  3. C#实体更新指定的字段

    接口类: /// <summary> /// 更新指定字段 /// </summary> /// <param name="entity">实体 ...

  4. 编程开发之--Oracle数据库--存储过程在out参数中使用光标(3)

    在本系列学习随笔中的第2节我们留下了2个问题,我们现在讨论在out参数中使用光标. 1.要在out参数中使用光标,我们需要申明一个包的结构,包的结构分为包头和包体,包头只负责申明,包体只负责实现.包头 ...

  5. DBA手记(学习)-RAC环境下GES TX报警情况处理

    GES ... TX-... GES的全称是Global Enqueue Service,用于RAC环境的全局共享队列.从提示信息可以看出,目前的锁定是DML引发的行级锁(TX). 检查v$lock_ ...

  6. ajax与websocket的区别以及websocket常用使用方式

    笔者近期在公司的项目中渐渐的接触了一些比较高级的业务逻辑处理,其中比较有意思的地方就是前端接受后台给与的推送问题. 一般前端与后端的交互主要是使用ajax进行异步操作调用交互,比较有趣的是这种交互方式 ...

  7. HP-Socket国产优秀socket通信组件推荐

    来源:http://blog.csdn.net/clb929/article/details/51085983 * HP-Socket 官方网站:http://www.jessma.org * HP- ...

  8. react项目 使用echarts

    1.安装 npm install --save echarts-for-react //如果需要使用echarts的一些特殊方法需要安装 npm install --save echarts 2.使用 ...

  9. filter 图片滤镜的各种设置

    filter 图片滤镜 给当前元素加滤镜_改变它的明亮度 定义:filter 属性定义了元素(通常是<img>)的可视效果(例如:模糊与饱和度).作用在图片上或元素上.div{ },或 d ...

  10. 以某课网日志分析为例 进入大数据 Spark SQL 的世界

    第1章 初探大数据 本章将介绍为什么要学习大数据.如何学好大数据.如何快速转型大数据岗位.本项目实战课程的内容安排.本项目实战课程的前置内容介绍.开发环境介绍.同时为大家介绍项目中涉及的Hadoop. ...