Hyperledger Fabric2中文文档-Membership Service Providers（MSP）

翻译：https://hyperledger-fabric.readthedocs.io/en/latest/msp.html

本文档提供了MSP的设置和实践。MSP是一个Fabric组件，是成员操作的抽象。

特别是，MSP将颁发证书，验证证书和用户身份验证背后的所有加密机制和协议抽象出来。MSP可以定义自己的身份概念，以及管理这些身份的规则（身份验证）和身份验证（签名生成和验证）。

一个Fabric的区块链网络可以由一个或多个MSP管理。这提供了成员操作的模块化，以及不同成员标准和体系结构的互操作性。在本文档的其余部分中，我们将详细介绍由Fabric支持的MSP实现的设置，并讨论有关其使用的最佳实践。

MSP配置

要设置MSP实例，需要在每个peer和orderer方本地指定其配置（以启用peer和orderer签名），并在通道上指定其配置，一起用所有通道成员的peer，orderer，client身份验证和各自的签名验证（身份验证）。

首先，需要为每个MSP指定一个名称，以便在网络中引用该MSP（例如msp1，org2和org3.divA）。这是代表联盟，组织或组织部分的MSP的成员规则在通道中引用的名称。这也被成为MSP标示符或MSP ID。每个MSP实例都要求MSP标识符是唯一的。例如，如果在系统通道中检测到两个具有相同标示符的MSP实例，则orderer设置将失败。

在默认的MSP实现的情况下，需要指定一组参数以允许身份（证书）验证和签名验证。这些参数由RFC5280推导，包括：

• 构成信任根的自签名（X.509）CA证书列表
• 一个X.509证书的列表，用于表示此提供程序为证书验证而考虑的中间CA；这些证书应该正好由信任根中的而一个证书进行验证；中间CA是可选参数。
• 一个X.509证书的列表，该列表代表此MSP的管理员，具有可验证的证书路径，正好指向信任根的其中一个CA证书；证书的所有者有权对此MSP配置进行更改（例如，根CA，中间CA）
• 本MSP有效成员应在其X.509证书中包含的组织单位列表；这是一个可选的配置参数，当多个组织利用相同的信任根和中间CA，并为其成员保留一个OU字段时使用。
• 证书吊销列表的列表（CRL），每个列表对应于所列出的（中间或根）MSP证书颁发机构中的一个；这是一个可选参数。
• 构成TLS证书的TLS信任根的自签名（X.509）证书的列表。
• 表示此提供程序考虑的中间TLS CA的X.509证书列表；这些证书应该由TLS信任根中的一个证书进行认证；中间CA是可选参数。

此MSP实例的有效标识必须满足以下条件：

• 它们以X.509 证书的形式存在，证书路径可验证，正好指向信任证书的根之一；
• 它们不包含在任何CRL（证书吊销列表 ）中；
• 它们在X.509证书结构的OU字段中列出了MSP配置的一个或多个组织单元。

有关当前MSP实现中标识有效性的更多信息，参阅MSP Identity Validity Rules

除了与验证相关的参数外，要使MSP能够对其实例化的节点进行签名或验证，还需要指定：

• 节点用于签名的签名秘钥（当前仅支持ECDSA秘钥）
• 节点的X.509证书，即在此MSP的验证参数下的有效标识。

需要注意的是，MSP身份永远不会过期；只有将它们添加到相应的CRL中，才能撤销它们。此外，目前不支持强制吊销TLS证书。

如何生成MSP证书和其签名秘钥

Openssl可用于生成X.509证书和秘钥。注意Hyperledger Fabric不支持RSA秘钥和证书。

或者，可以按照 Getting Started 来使用cryptogen工具。

Fabric CA还可用于生成配置MSP所需的秘钥和证书。

MSP在peer和orderer上的安装

要设置本地MSP（对peer或orderer），管理员应该创建包含六个子文件夹和一个文件的文件夹（例如 $MY_PATH/mspconfig）

1.包含PEM文件的文件夹admincerts ，每个文件对应一个管理员证书。

2.一个包含PEM文件的文件夹cacert，每个文件对应与根CA的证书。

3.(可选)intermediatecerts文件夹包含每个对应与中间CA证书的PEM文件

4.（可选）文件config.yaml配置支持的组织单位和身份分类（请参阅下面的相应部分）。

5.（可选）文件夹crls包含所考虑的CRL

6.文件夹keystore 包含一个带有节点签名秘钥的PEM文件；我们强调目前不支持RSA秘钥。

7.文件夹signcerts ，包含一个PEM文件和节点的X.509证书。

8.（可选）文件夹tlscacerts ，包含对应于TLS根CA证书的PEM文件

9.（可选）文件夹tlsintermediatecerts ，包含与中间TLS CA证书相对应的PEM文件

在节点的配置文件中（peer的core.yaml和orderer的orderer.yaml），需要指定mspconfig的目录路径，以及节点MSP的标示符。mspconfig文件夹的路径应于FABRIC_CFG_PATH相对，也就是peer的mspConfigPath 参数，orderer的LocalMSPDir 参数。节点的标识参数在peer中是localMspId ，在orderer中是LocalMSPID 。这个变量可以被环境变量更改，peer是CORE_PEER_LOCALMSPID，orderer是ORDERER_GENERAL_LOCALMSPID。注意，对于orderer的设置，需要生成，且提供系统通道创始区块。需要这个区块的MSP配置会在下个部分详细介绍。

只能手动配置“local” MSP，并且需要peer和orderer进程重启。在随后的版本中，我们的目标是提供在线/动态重新配置（即不需要使用节点管理的系统链码来停止节点）。

组织单位

为了配置此MSP的有效成员应包含在其X.509证书中的组织单位列表，config.yaml文件需要指定组织单位（简称OU）标示符。示例如下：

OrganizationalUnitIdentifiers:
  - Certificate: "cacerts/cacert1.pem"
    OrganizationalUnitIdentifier: "commercial"
  - Certificate: "cacerts/cacert2.pem"
    OrganizationalUnitIdentifier: "administrators"

以上示例声明了两个组织单元标识：commercial 和administrators。如果MSP标识包含至少一个组织单位标示符，则该标识有效。证书字段指的是CA或中间CA证书路径，在该路径下标识，有特定的OU，应该被验证。路径是相对与MSP根文件的且不能为空。

身份分类

默认的MSP组件基于OU的x509证书将组织分为client，admin，peer和orderer基于OU的x509证书。

• 如果能在网上做交易，身份就是client
• 如果做一些admin的任务，如加入一个peer或者升级通道配置，一个身份应该被归为admin
• 如果为交易背书或提交交易，身份是peer
• 如果属于ordering节点，那就是orderer

为了定义给定的MSP的client，admin，peer，和orderer，config.yaml文件需要配置适当。下面示例config.yaml的NodeOU 部分:

NodeOUs:
  Enable: true
  # For each identity classification that you would like to utilize, specify
  # an OU identifier.
  # You can optionally configure that the OU identifier must be issued by a specific CA
  # or intermediate certificate from your organization. However, it is typical to NOT
  # configure a specific Certificate. By not configuring a specific Certificate, you will be
  # able to add other CA or intermediate certs later, without having to reissue all credentials.
  # For this reason, the sample below comments out the Certificate field.
  ClientOUIdentifier:
    # Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "client"
  AdminOUIdentifier:
    # Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "admin"
  PeerOUIdentifier:
    # Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "peer"
  OrdererOUIdentifier:
    # Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "orderer"

当NodeOUs.Enable为true时，身份分类启用。然后，通过client（admin，peer，orderer）组织单元标识通过属性NodeOUs.ClientOUIdentifier (NodeOUs.AdminOUIdentifier, NodeOUs.PeerOUIdentifier, NodeOUs.OrdererOUIdentifier)设置。

a.OrganizationalUnitIdentifier：x509证书需要包含的OU值，才能将其视为client（admin，peer，orderer）。如果此字段为空，则不应用分类。

b. Certificate：（可选）将其设置为CA或中间CA证书的路径，在该证书下应验证客户端（peer，admin，orderer）身份。该字段是相对于MSP根文件夹的。只有一个单独的证书可以指定。如果不设置此项，那就在组织的MSP配置中定义的任何CA下验证身份，如果将来需要添加其他CA或中间证书，这可能是理想的。

注意如果NodeOUs.ClientOUIdentifier（NodeOUs.AdminOUIdentifier, NodeOUs.PeerOUIdentifier, NodeOUs.OrdererOUIdentifier）缺失，分类就不支持。如果NodeOUs.Enable设置成true，并且没有类型key被定义，那么身份分类就被假设为禁用。

身份可以使用组织单元来分类为client，admin，peer，orderer。这四类身份是相互排斥的。1.1版本在分类为client和peer之前需要启用通道capability ，1.4.3版本在分类为admin和orderer之前，需要启用通道capability 。

分类允许将身份分类为管理员，而无需将证书存储在MSP的admincerts文件夹中。相反，admincerts 文件可以一直为空，并且可以通过向OU注册标识来创建。admincerts文件夹中的证书仍将向其持有者授予管理员角色，前提是他们拥有客户端或管理OU。

通道MSP设置

在系统产生时，需要指定网络中出现的所有msp的验证参数，并包含系统的创始区块。回想以下，MSP验证参数包括MSP标示符、信任证书的根、中间CA和管理证书，以及OU规范和CRL。系统创始区块在orderer的设置阶段提供给他们，并允许他们验证通道创建请求。如果系统genesis块包含两个具有相同标识的MSP，那么orderer将拒绝系统创始区块，因此网络的引导将失败。

对于应用程序通道，只有管理通道的msp的验证组件需要驻留在通道的创始区块中。我们强调，应用程序有责任在指示一个或多个peer加入通道之前，确保通道的创始区块（或最新的配置块）中包含正确的MSP配置信息。

在使用configtxgen工具引导通道时，可以通过在mspconfig文件夹中包含MSP的验证参数并在其中的相关部分设置该路径来配置通道MSP的configtx.yaml

重新配置通道上的MSP，包括与该MSP的ca相关联的证书吊销列表通知，是通过MSP的一个管理员证书的所有者创建config_update 对象来实现的。然后，由管理员管理的客户端应用程序将向显示此MSP的频道宣布此更新。

最佳实践

这部分，我们将详细介绍常见场景中MSP配置的最佳实践。

1）组织、公司和MSP之间的映射。

我们建议在组织和MSP之间建立一一对应的关系。如果选择不同类型的映射，则需要考虑以下几点：

• 一个组织雇佣不同的MSP。这对应于一个组织的情况，包括各种部门，每个部门由其MSP代表，或者出于管理独立性的原因，或者处于隐私的原因。在这种情况下，一个peer只能由一个MSP拥有，并且不会识别同一个组织有不同MSP的peer。这意味着peer可以通过gossip与同属于一细分的一组peer共享数据，而不是与组成实际组织的全套提供者共享数据。
• 多个组织共用一个MSP。这对应于一个由成员们管理的联盟，这里需要知道的是，peer会将组织范围内的消息传播给同一MSP下具有标识的peer，而不管它们是否属于同一个实际组织。这是对于MSP定义颗粒度和peer的配置的限制。

2）一个组织有不同的部门（或组织单元），它想授予不同的通道访问权限。

两种方式来处理这种情况：

• 定义一个MSP以容纳所有组织成员的资格。MSP的配置将包括根ca，中间ca和管理证书的列表；成员身份将包括成员所属的组织单元（OU）。然后，可以定义策略来捕获特定角色的成员（应该是：peer，admin，client，order，member之一），这些策略可以构成频道的读/写策略或链码的认可策略。在configtx.yaml 的profile部分指定OU为未配置。这种方法的一个局限性是，gossip peer会认为其笨的MSP下具有成员身份的peer视为同一组织的成员，并因此与他们沟通组织范围内的数据（例如他们的状态）
• 为每一个部门来定义MSP。这将涉及为每个部门指定根CA，中间CA和管理证书的一组证书，以便在MSP之间没有重叠的证书路径。这意味着，例如，每个细分使用不同的中间CA.这里的缺点是管理多个msp而不是一个msp，但是这回避了前面方法中存在的问题。这可以通过利用MSP配置的OU扩展为每个部门定义一个MSP.

3）将client与同一组织的peer分离。

在许多情况下，需要从身份本身检索身份的“类型”（例如，可能需要保证背书是由peer而不是仅作为orderer的client或节点派生的）。

对这种要求的支持有限。

允许这种分离的一种方法是为每种节点类型创建一个单独的中间CA——一个用于client，一个用于peer/orderer;并配置两个不同的MSP——一个用于客户端，一个用于peer/orderer。该组织应该访问的通道将需要包括两个MSP，而背书策略将只利用引用peer的MSP。这最终会导致组织被映射到两个MSP实例，并且会对peer和client交互方式产生一定的影响。

Gossip不会收到剧烈影响，因为同一组织的所有peer依然属于同一个MSP。Peer可以将某些系统链码的执行限制为基于本地MSP的策略。例如，peer可以执行joinChannel请求，如果请求是由只能是client的本地MSP管理员签名的。如果我们接受作为peer/orderer的MSP的唯一客户机是该MSP的管理员，我们就可以避免这种不一致。

使用这种方法需要考虑的另一点是，peer根据本地MSP中请求发起方的成员身份来授权事件注册请求。显然，由于请求的发起者是client，因此请求发起者总被认为属于被请求peer不同的MSP，并且peer将拒绝该请求。

4）管理员和CA证书

将MSP管理员证书设置为不同的信任根或中间ca的证书，这一点很重要。这是一种常见的（安全）做法，将管理成员组成部分的职责与颁发新证书和/或验证现有证书分开。

5）阻止中间CA

前文提到，重新配置MSP是通过重新构造结构实现的（手动重新配置本地MSP实例，并通过为通道MSP实例正确构造配置config_update ）。显然，有两种方法可以确保MSP中考虑的中间CA不再用于该MSP的身份验证：

1.重新配置MSP，使其不再将该中间CA的证书包含在受信任的中间CA证书列表中。对于本地配置的MSP，这意味着将从intermediatecerts文件夹中删除此CA的证书。

2.重新配置MSP以包含由trust根生成的CRL，该CRL将公开所述中间CA的证书。

在当前的MSP实现中，我们只支持方法（1），因为它更简单，不需要打包丢弃的中间CA。

6）CA和TLS CA

MSP标识的根CA和MSP TLS证书的根CA（以及相对中间CA）需要在不同的文件夹中声明。这是为了避免不同类别证书之间的混淆。不禁止对MSP标识和TLS证书中用相同的ca，但最佳实践建议在生产中避免这种情况。