fabric中的一些概念

成员

如果你已经阅读了身份文档,那么你应该已经知道了 PKI 是如何能够通过信任链条来提供可验证身份的。现在我么来看一下如何用这些身份代表区块链网络中的受信任成员。

这就需要成员服务提供者(MSP)来发挥作用了,它能识别出哪些根 CA 和中间 CA 是受到信任来定义某个信任领域的成员的,例如,一个组织。MSP发挥作用的方式要么是将成员的身份进行列表,要么是识别出哪些CA获权为其成员颁发有效证书,要么(最常见的方式)将二者结合使用。

MSP 的能力绝非仅仅罗列谁是网络参与者或通道成员那么简单。MSP 可以识别参与者在 该MSP 代表的组织范围内可能扮演的特定角色(例如,管理员或作为子组织小组的成员),同时MSP还为网络或通道环境内访问权限的定义奠定了基础(例如,通道管理员、读取者、写入者)。

MSP 的配置会(以通道 MSP 的形式)被广播到相应组织成员所参与的全部通道中。除了通道 MSP之外,Peer 节点、排序节点以及客户端也都维护着一个本地 MSP,用来验证通道环境外的成员信息,并定义对某特定组件的权限(比如,谁能够在节点上安装链码)。

此外,MSP 还支持将已撤销的一组身份识别出来(如身份文档中所讨论的),但我们马上要讨论该过程是如何扩展到 MSP的。

稍后我们将继续讨论本地和通道 MSP。现在,让我们看看 MSP 通常做些什么。

将 MSP 映射到组织

组织是被管理的成员小组。组织可大可小,可以像一家跨国公司那么大,也可以像一个花店那么小。通常,组织由一个单个MSP来代表。注意,这与我们稍后将讨论的 X.509 证书中定义的组织概念不同。

由于组织和其MSP之间存在排他关系,因此以组织名称来命名MSP是很明智的,这是大多数策略配置中都会采用的约定。例如,组织ORG1可能想将某个MSP命名为ORG1-MSP。在有些情况中,一个组织可能需要多个成员小组,比如,需要用通道来在组织间执行完全不同的业务功能时。在这些情况中,拥有多个MSP并且相应地对这些MSP命名是很有道理的,例如,ORG2-MSP-NATIONAL 和ORG2-MSP-GOVERNMENT反映了NATIONAL销售通道上ORG2内与GOVERNMENT管理通道不同的成员信任根源。

由于组织及其 MSP 之间的排他性关系,所以最好使用组织的名称命名 MSP,您会发现在大多数策略配置中都采用了这种约定。例如,组织 ORG1 可能有一个名为 ORG1-MSP 之类的 MSP。在某些情况下,组织可能需要多个成员组,例如,通道用于在组织之间执行完全不同的业务功能。在这些情况下,有多个 MSP 并相应地命名是有意义的,例如,ORG2-MSP-NATIONAL 和 ORG2-MSP-GOVERNMENT ,这反映了 ORG2 在全国销售通道中与政府监管通道中成员的信任根是不同的。

一个组织有两种不同的 MSP 配置。第一个配置显示了 MSP 和组织之间的典型关系——单个 MSP 定义了组织的一组成员。在第二种配置中,用不同的 MSP 来表示具有国家、国际和政府关联的不同组织小组。

组织的单位以及 MSP

一个组织通常被划分为多个组织单元(OU),每个单元都有一组特定的职责。例如,ORG1 组织可能同时具有 ORG1-MANUFACTURING 和 ORG1-DISTRIBUTION OU 来反映这些独立的业务线。当 CA 发出 X.509 证书时,证书中的 OU 字段会指明身份所属的业务线。

稍后我们将看到,OU 怎样帮忙控制组织中被认为是区块链网络成员的部分。例如,只有来自 ORG1-MANUFACTURING OU 的身份才能访问通道,而来自 ORG1-DISTRIBUTION 的不能。

最后,尽管这是对 OU 的轻微误用,但有时它们可以被联盟中的不同组织用来区分彼此。在这种情况下,不同的组织使用相同的根 CA 和中间 CA 作为它们的信任链,但是分配 OU 字段来识别各组织的成员。稍后我们还将看到如何配置 MSP 来实现这一点。

本地和通道 MSP

在区块链网络中,MSP 出现在两个位置:

  • 在通道配置中(通道 MSP
  • 在参与者节点本地(本地 MSP

本地 MSP 是为客户端(用户)和节点(Peer 节点和排序节点)定义的。节点本地 MSP 为该节点定义权限(例如,节点管理员是谁)。用户的本地 MSP 允许用户端在其交易中作为通道的成员(例如在链码交易中)或作为系统中特定角色的所有者(例如在配置交易中的某组织管理员)对自己进行身份验证。

每个节点和用户都必须定义一个本地 MSP,因为它定义了谁拥有该级别的管理或参与权(节点管理员不一定是通道管理员,反之亦然)。

相反,通道 MSP 在通道级别定义管理和参与权。每个参与通道的组织都必须为其定义一个 MSP。通道上的 Peer 节点和排序节点将共享通道 MSP,因此能够正确地对通道参与者进行身份验证。这意味着,如果某个组织希望加入通道,则需要在通道配置中加入一个包含该组织成员信任链的 MSP。否则,由该组织身份发起的交易将被拒绝。

本地和通道 MSP 之间的关键区别不在于它们如何工作(它们都将身份转换为角色)而在于它们的作用域

本地和通道 MSP。每个节点的信任域(例如组织)由节点的本地 MSP(例如 ORG1 或 ORG2)定义。通过将组织的 MSP 添加到通道配置中,可以表示该组织加入了通道。例如,此图中的通道由 ORG1 和 ORG2 管理。类似的原则也适用于网络、排序节点和用户,但是为了简单起见,这里没有显示这些原则。

你可能会发现通过查看区块链管理员安装和实例化智能合约时所发生的情况,能帮助你理解如何使用本地和通道 MSP ,如上图所示。

管理员 B 使用身份连接到节点上,该身份是由RCA1颁发的,存储在本地 MSP中。当 B 试图在节点上安装智能合约时,该节点检查其本地 MSP ORG1-MSP,以验证 B 的身份确实是 ORG1 的成员。验证成功后才会允许安装。随后,B 希望在通道上实例化智能合约。因为这是一个通道操作,所以通道上的所有组织都必须同意该操作。因此,节点在成功提交此命令之前必须检查该通道的 MSP。(其他事情也必须发生,但现在先专注于上面的事情。)

本地 MSP 只被定义在它们应用到的节点或用户的文件系统上。因此,从物理和逻辑上来说,每个节点或用户只有一个本地 MSP。但是,由于通道 MSP 对通道中的所有节点都可用,因此在逻辑上他们只在通道配置中定义一次。然而,通道 MSP 也在通道中每个节点的文件系统上实例化,并通过共识来保持同步。因此,虽然每个节点的本地文件系统上都有各通道 MSP 的副本,但从逻辑上讲,通道 MSP 驻留在通道或网络上并由通道或网络进行维护。

MSP 层级

通道MSP和本地 MSP 之间的区别反映了组织管理其本地资源(如 Peer 节点或排序节点)和通道资源(如账本、智能合约和联盟)的需求,这些资源在通道或网络级别运行。将这些 MSP 看作是不同级别的是有帮助的,其中处于较高级别的 MSP 与网络管理相关,而处于较低级别的 MSP 处理私有资源管理的身份。MSP 在每个管理级别都是强制性的——必须为网络、通道、Peer 节点、排序节点和用户定义它们。

MSP 的级别。Peer 节点和排序节点的 MSP 是本地的,而通道(包括网络配置通道)的 MSP 是对该通道的所有参与者共享的。在这个图中,网络配置通道由 ORG1 管理,但是另一个应用程序通道可以由 ORG1 和 ORG2 管理。Peer 节点是 ORG2 的成员,由 ORG2 管理,而 ORG1 管理图中的排序节点。ORG1 信任来自 RCA1 的身份,而 ORG2 信任来自RCA2 的身份。注意,这些是管理员身份,反映了谁可以管理这些组件。所以当 ORG1 管理网络时,ORG2.MSP 也要在网络定义中。

  • 网络 MSP :一个网络的配置文件,通过定义参与组织的 MSP 定义了谁是这个网络中的成员,并且定义了这些成员中的哪些被授权来执行相关管理任务 (比如,创建一个通道)。
  • 通道 MSP:对于一个通道来说,保持其成员MSP的不同至关重要。通道为一群特定组织提供了一个彼此间私有的通信方式,这些组织又对这个通道进行管理。该通道 MSP 中所解释的通道策略定义了谁有能力参与该通道上的某些操作,比如,添加组织或者实例化链码。注意,管理通道的权限和管理网络配置通道(或任何其他通道)的能力之间没有必然联系。管理权仅存在于被管理的范围内(除非已在规则中明确——查看下边对于 ROLE 属性的讨论)。
  • Peer 节点 MSP:这个本地 MSP 是在每个节点的文件系统上定义的,并且每个节点都有一个单独的 MSP 实例。从概念上讲,该MSP和通道 MSP 执行着完全一样的操作,但仅适用于其被定义的节点。在节点上安装一个链码,这个就是使用节点的本地 MSP 来判定谁被授权进行某个操作的例子。
  • 排序节点 MSP: 就和Peer 节点 MSP 一样,排序节点的本地 MSP 也是在节点的文件系统上定义的,并且只会应用于这个节点。同时,排序节点也是由某个单独的组织所有,因此具有一个单独的 MSP 用于罗列它所信任的操作者或者节点。

MSP 结构

目前为止,你所看到的 MSP 最为重要的元素就是对于根或者中间 CA 的声明,这些 CA 被用来在对应的组织中建立一个参与者或者节点的成员身份。然而这里还有更多的元素同这两个元素一起来辅助成员相关的功能。

上面的图显示了本地 MSP 在本地文件系统中的储存方式。尽管通道 MSP 的物理结构不是完全按照这种方式构建的,但是这样考虑它们仍然是一种有用的方式。

正如您所看到的,MSP 有九个元素。在目录结构中考虑这些元素最简单,其中 MSP 名称就是根文件夹名称,而每个子文件夹代表 MSP 配置的不同元素。

让我们深入探讨一下这些文件夹,看看它们为什么重要。

  • 根 CA:该文件夹包含了根CA自主签名的X.509证书的列表,其中的根CA是受MSP代表的组织所信任的。在这个 MSP 文件夹中至少要有一个根 CA X.509 证书。

    这是最重要的一个文件夹,因为它指出了所有可用于证明成员属于对应组织的其他证书的来源 CA。

  • 中间 CA:该文件夹包含了受这个组织信任的中间 CA 对应的 X.509 证书列表。其中每个证书的签发方必须是MSP中的某个根CA或中间CA,若是中间CA,则该中间 CA 的证书签发 CA 信任链必须最终能够连上一个受信任的根 CA。

    中间 CA 可能代表了组织中不同的一个分支(就像 ORG1 有 ORG1-MANUFACTURING 和 ORG1-DISTRIBUTION一样), 也可能代表了这个组织自身(比如当一个商业 CA 被用来管理组织的身份时)。在后边这个情况中,中间 CA 可以被用来代表组织的分支。从这里你或许能看到更多关于 MSP 配置最佳实践的信息。注意,对于一个工作网络来说,也有可能没有任何的中间 CA,这种情况下,这个文件夹就是空的。

    就像根 CA 文件夹一样,中间CA文件夹定义了可用于证明组织成员身份的证书的签发CA。

  • 组织单元 (OU):组织单元被列在 $FABRIC_CFG_PATH/msp/config.yaml 文件中,包含了组织单元的一个列表,其中的成员被认为是由这个 MSP 所代表的组织的一部分。当你想要把一个组织的成员限定为持有一个其中包含某特定组织单元的身份(由MSP指定的某个CA签发)的成员时,它是很有用的。

    指定 OU 不是必须的。如果没有列出任何 OU,MSP中的所有身份(由根 CA 和中间 CA 文件夹指出)都会被认为是组织的成员。

  • 管理员:该文件夹包含了一个身份列表,其中的身份为该组织定义了哪些操作者担任管理员。对于标准的 MSP 类型来说,在这个列表中应该有一个或者多个 X509 证书。

    值得注意的是,仅凭借某操作者担任管理员这一点并不能说明它可以管理某些特定的资源。对于一个给定身份来说,它在管理系统方面的实际能力是由管理系统资源的相关策略决定的。比如,一个通道策略可能会指明 ORG1-MANUFACTURING 管理员有权利来向通道中添加新的组织,然而 ORG1-DISTRIBUTION 管理员却没有这个权利。

    虽然 X.509 证书具有 ROLE 属性(比如,明确规定一个操作者是一个 admin),但是该属性指的是操作者在其组织内所扮演的角色,而不是在区块链网络上。这一点与OU 属性的目的类似,若已经定义OU 属性,则其指的是操作者在组织中的位置。

    如果某个通道策略允许来自一个(或某些)组织的任何管理员执行某些通道功能的话,那么ROLE 属性就能够用来授予该通道级别上的管理权力。这样的话,一个组织层面的角色可以授予一个网络级别的角色。

  • 撤销证书:如果一个参与者的身份被撤销,那么该身份的识别信息(不是指身份本身)就会被储存在这个文件夹中。对基于 X.509 的身份来说,这些标识符就是主体密钥标识符 (Subject Key Identifier,SKI) 和权限访问标识符(Authority Access Identifier,AKI)的字符串对,并且无论何时使用 X.509 证书,都会检查这些标识符,以确保证书未被撤销。

    虽然这个列表在概念上跟 CA 的证书撤销列表 (CRL) 是一样的,但是它还和从组织中撤销成员有关。这样一来,本地或通道 MSP 的管理员通过广播被撤销证书的发行CA的最新CRL,就可以迅速将这个参与者或者节点从组织中撤销。罗列这一列表并不是必须的,只有在证书要撤销的时候才会用到。

  • 节点身份:这个文件夹包含了节点的身份,比如,与KeyStore内容结合使用的加密材料将允许节点在向同通道或同网络上其他参与者发送的信息中验证自己的身份。对基于 X.509 的身份来说, 该文件夹包含了一个 X.509 证书。Peer节点会把这一证书放置到交易提案的响应中,比如,来表明该节点已经为此交易背书,在接下来的验证阶段会根据交易的背书策略来验证这一背书。

    本地 MSP 中必须拥有”节点身份“文件夹,节点中有且仅有一个X.509 证书。而通道 MSP中不使用该文件夹 。

  • 私钥的 KeyStore:这个文件夹是为 Peer 节点或者排序节点(或者在客户端的本地 MSP 中) 的本地 MSP 定义的,其中包含了节点的签名秘钥。这个秘钥与节点身份文件夹里的节点身份能以密码方式匹配,可用来对数据进行签名,比如在背书阶段对一个交易提案的响应进行签名。

    本地 MSP 必须有这个文件夹,而且该文件夹必须包含且仅包含一个私钥。很显然,这个文件夹的访问权限必须限定在对这个节点有管理权限的用户的身份。

    因为通道 MSP 的目标只是提供身份验证功能,而不是签名的能力,所以通道 MSP 的配置中不包含这个文件夹。

  • TLS 根 CA:该文件夹包含了根CA的自主签名X.509证书的列表,其中的根CA是受该组织信任来进行TLS通信的。一个 TLS 通信的例子就是,Peer 节点为接受到更新过的账本, 需要连接到一个排序节点,这时就会发生TLS通信。

    MSP TLS 信息和网络内部的节点(Peer 节点和排序节点)有关联,换句话说,它与使用该网络的应用程序和管理员无关。

    这个文件夹中必须有至少一个 TLS 根 CA X.509 证书。

  • TLS 中间 CA:这个文件夹包含了在通信时这个 MSP 所代表的的组织所信任的中间 CA 证书列表。当商业 CA 被用于一个组织的 TLS 证书时,该文件夹特别有用。跟成员的中间 CA 类似,指定中间 TLS CA 是可选项。

    关于 TLS 的更多信息,点击这里

如果你读过这个文档以及我们关于身份的文档,你应该对身份和成员在 Hyperledger Fabric 中的作用有了很好的理解。您了解了如何使用 PKI 和 MSP 来识别在区块链网络中协作的参与者。您学习了证书、公钥、私钥和信任根的工作原理,以及 MSP 的物理和逻辑结构。

Next  Previous

发布了19 篇原创文章 · 获赞 0 · 访问量 9394

猜你喜欢

转载自blog.csdn.net/yuxinqingge/article/details/104678455
今日推荐