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 組合而成。
參考網址
https://hyperledger-fabric.readthedocs.io/en/release-1.1/policies.html