Hyperledger Fabric 1.1 -- Policy 构成

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

posted @ 2018-09-21 14:05  王的博客  阅读(2210)  评论(0编辑  收藏  举报