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. DPDK安装依赖项合集 环境合集

    前言 在dpdk编译过程中,由于一些依赖项的限制,dpdk在纯净的系统上安装需要花一些功夫.本文总结了编译dpdk所需的依赖项,并归纳了安装合集,在安装过程上可以省下大量的搜索时间. 使用系统 ubu ...

  2. OO 第五、六、七次作业总结

    第五次作业 算法与实现 这次的电梯因为要使用系统时间进行模拟,所以又是推倒了之前的重写的.最后采用三个电梯线程,一个调度线程,一个输入线程的方式. 源码分析图示 类图 方法分析 类分析 由上图看,由于 ...

  3. Uncaught SyntaxError: Unexpected token : 开发遇到的跨域问题

    先描述一下,这个问题,是如何遇到的 在ajax调用远程服务的时候,报了一个Origin xxxxxx is not allowed by Access-Control-Allow-Origin 的错误 ...

  4. Redis学习笔记(二)

    解读Retwis官网例子 Redis需要考虑需要哪些keys以及对应的value使用合适的数据类型进行存储.在retwis例子中,我们需要users,user的粉丝列表, user的关注用户列表等等. ...

  5. 学习ThinkPHP5的第一天(安装 连接数据库)

    参考文档:thinkPHP5.0完全手册  一.安装 采用的是git安装方式: 应用项目:https://github.com/top-think/think 核心框架:https://github. ...

  6. CentOS6安装各种大数据软件 第三章:Linux基础软件的安装

    相关文章链接 CentOS6安装各种大数据软件 第一章:各个软件版本介绍 CentOS6安装各种大数据软件 第二章:Linux各个软件启动命令 CentOS6安装各种大数据软件 第三章:Linux基础 ...

  7. 解决Stm32出现error: #20: identifier "GPIO_InitTypeDef" is undefined异常

    该错误是我在移植sd卡程序时出现的,错误如下: error:#20,查看错误,可以发现,这些变量都是系统定义过的,没有修改过.并且该变量也能成功跳转被找到.那么到底是什么原因呢?逛了一些帖子,尝试了好 ...

  8. 20190313-时间和日期-Time

    概述 在Python中,与时间处理相关的模块有:time.datetime以及calendar,Python中通常有这几种方式表示时间:时间戳.格式化的时间字符串.时间元组(struct_time 共 ...

  9. bat脚本,winscp,shell加mysql存储过程实现mysql单条数据迁移

    起因 公司有个任务,需要迁移mysql中的单条数据.从公司的dev环境到staging环境,dev环境的mysql安装在windows server 2012 R2下,stage是aws的服务器不能直 ...

  10. 20155210 潘滢昊 2016-2017-2 《Java程序设计》第3周学习总结

    20155210 2016-2017-2 <Java程序设计>第3周学习总结 教材学习内容总结 class xxx{ }:定义类 运用: class Clothes{ String col ...