Policy 规则设计
本文主要是讲解一下在fabric中Policy的规则和写法，让大家有一个初步的认识，本文是基于fabric 1.1版本
Policy Type
Policy Type 目前包括两种：SIGNATURE 和 IMPLICIT_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 组合而成。