Hyperledger Fabric译文之Membership Service Providers (MSP)
英文原址：http://hyperledger-fabric.readthedocs.io/en/latest/msp.html
Membership Service Providers (MSP)
该文档用于提供有关MSP设置和最佳做法的详细信息。
会员服务提供商（MSP）是旨在提供会员操作架构抽象的组件。
特别地，MSP抽取出发布和验证证书以及用户认证背后的所有加密机制和协议。MSP可以定义自己的身份概念，以及这些身份管理的规则（身份验证）和身份验证（签名生成和验证）。
Hyperledger Fabric区块链网络可由一个或多个MSP共同管理。这提供了会员操作的模块化，以及跨不同会员标准和架构的互操作性。
在本文档的其余部分，我们详细阐述Hyperledger Fabric支持的MSP的设置，并讨论了有关其使用的最佳实践。
MSP配置
要设置MSP的实例，需要在本地指定每个peer和orderer（启用peer和orderer签名）的配置，并在通道上启用peer，orderer，客户端身份验证和所有channel成员的各自的签名验证（认证）。
首先，对于每一个MSP需要指定一个可以在网络中引用的名称（例如msp1，org2和org3.divA）。这个名称可以在channel中引用并遵循联盟，组织或组织部门的MSP的会员规则。这也称为MSP标识符或MSP ID。对于每个MSP实例，MSP标识符必须是唯一的。例如，具有相同标识符的两个MSP实例在系统channel原始快中时被检测到时，orderer设置将失败。
在MSP的默认实现的情况下，需要指定一组参数以允许身份（证书）验证和签名验证。这些参数由RFC5280推导出来 ，包括：
- 构成信任根源的自签名（X.509）证书列表
- X.509证书列表，用于表示提供商认证用于证书验证的中间CA; 这些证书应该通过信托根源中的一个证书进行认证; 中间CA是可选参数
- 具有可验证证书路径的X.509证书列表，以正确的信任根证书之一代表该MSP的管理员; 这些证书的所有者有权要求更改此MSP配置（例如，根CA，中间CA）
- 该MSP的有效成员的组织单位列表应包括在其X.509证书中; 这是一个可选的配置参数，当例如多个组织利用相同的信任根和中间CA时使用，并为其成员保留了OU字段
- 与列出的 (中间或根) MSP 证书颁发机构中的一个完全对应的证书吊销列表（CRLs）; 这是一个可选参数
- 自签名（X.509）证书的清单，构成TLS证书的TLS信任根源
- X.509证书的列表，用于表示提供商认为的中间TLS CA; 这些证书应该通过TLS信托根源中的一个证书进行认证; 中间CA是可选参数。
MSP实例的有效身份需要满足以下条件：
- 它们是X.509证书的形式，具有可信证书路径，恰好是信任证书根目录之一
- 它们不包括在任何CRL中
- 他们在X.509证书结构领域中列出了一个或多个MSP配置的中
OU字段对应的组织单位
有关当前MSP实现中身份有效性的更多信息，请参阅读者MSP身份验证规则。
除了验证相关参数之外，为使MSP启用实例化的节点进行签名或认证，需要指定：
- 用于由节点签名的签名密钥（目前仅支持ECDSA密钥）
- 该节点的X.509证书，该MSP的验证参数下的有效身份
重要的是要注意，MSP身份永远不会过期; 它们只能通过将其添加到适当的CRL来撤销。此外，目前不支持强制撤销TLS证书。
如何生成MSP证书及其签名密钥？
要生成X.509证书以满足其MSP配置，应用程序可以使用Openssl。我们强调，在Hyperledger Fabric中，不支持包括RSA密钥在内的证书。
或者，可以使用cryptogen工具，其操作在入门中有说明 。
Hyperledger Fabric CA 也可用于生成配置MSP所需的密钥和证书。
MSP设置peer和orderer
要设置本地MSP（对于peer或orderer），管理员应创建一个包含六个子文件夹和文件的文件夹（例如$MY_PATH/mspconfig）：
- 一个文件夹
admincerts，其中包括对应于管理员证书的PEM文件 - 一个文件夹
cacerts，其中包括对应于根CA证书的PEM文件 - （可选）一个文件夹
intermediatecerts，其中包括每个对应于CA中间证书的PEM文件 - (可选) 文件
config. yaml包括被考虑的 ou 的信息;后者被定义为称为OrganizationalUnitIdentifiers的 yaml 数组的OrganizationalUnitIdentifier代表的实际字符串预计将出现在 x 509 证书 OU 字段 (如 “COP”) - （可选）一个文件夹，
crls以包括所考虑的CRL - 一个文件夹
keystore包含节点签名密钥的PEM文件; 我们强调目前不支持RSA密钥 - 一个文件夹
signcerts包含节点的X.509证书的PEM文件 - （可选）一个文件夹，
tlscacerts以包含每个对应于TLS根CA证书的PEM文件 - （可选）一个文件夹，
tlsintermediatecerts以包含每个对应于中间TLS CA证书的PEM文件
在节点的配置文件（peer对应的是core.yaml文件和orderer对应的是orderer.yaml）中，需要指定mspconfig文件夹的路径和节点MSP的MSP标识符。mspconfig文件夹的路径被预期和FABRIC_CFG_PATH相关和作为peer的mspConfigPath的参数值，以及orderer的LocalMSPDir 参数值。节点MSP的标识符用来作为peer的参数localMspId以及order的参数LocalMSPID对应的值。 这些变量可以通过环境变量进行覆盖，如通过peer的CORE前缀（例如CORE_PEER_LOCALMSPID）和订单的ORDERER前缀（例如ORDERER_GENERAL_LOCALMSPID）。请注意，对于orderer的设置，需要生成一个提供给orderer的系统channel的原始块。下一节将详细介绍该块的MSP配置需求。
“本地”MSP的重新配置只能手动进行，并且要求peer或orderer进程重新启动。在后续版本中，我们旨在提供在线/动态重新配置（如不需要停止节点，而是通过使用节点管理的系统链码来操作）。
Channel MSP设置
在系统的起源上，需要指定网络中出现的所有MSP的验证参数，并将其包含在系统channel的原始块中。回想一下，MSP验证参数由MSP标识符，信任的根证书，中间CA和管理证书以及OU规范和CRL组成。系统原始块在其设置阶段提供给orderer，并允许它们验证通道创建请求。如果系统原始块中包含两个具有相同标识符的MSP，则orderer拒绝该系统原始块，并且因此网络的启动将失败。
对于应用渠道，仅管理channel的MSP的验证组件需要驻留在channel的起源块中。我们强调应用程序的责任是在一个或多个peer加入该channel之前，确保正确的MSP配置信息被包含在channel的起源块（或最新配置块）中。
在通过configtxgen工具的帮助下引导通道时，可以通过在mspconfig文件夹中包含MSP的验证参数来配置通道MSP ，并在configtx.yaml相关部分中设置该路径。
在通道上重新配置 msp, 包括与该 msp 的 ca 相关的证书吊销列表的公告, 是通过 msp 的一个管理员证书的所有者创建一个 config_update 对象来实现的。管理员管理的客户端应用程序随后将向此 MSP 出现的通道发布此更新。
最佳实践
在本节中，我们详细介绍常见场景中MSP配置的最佳实践。
1）组织/公司和MSP之间的映射
我们建议组织和MSP之间存在一对一的映射。如果选择不同的映射类型的映射，则需要考虑以下内容：
- 一个组织采用多种MSP
这对应于一个组织的情况, 其中包括由其 MSP 代表的各种部门, 无论是出于管理独立原因, 还是出于隐私原因。在这种情况下, peer只能由单个 MSP 拥有, 并且不会识别来自其他项目的对等点作为同一组织的对等节点。这意味着,peer可以通过八卦组织范围内的数据与一组同级成员共享, 而不是由构成实际组织的全套提供者组成。 - 使用单个MSP的多个组织
这对应于由类似会员架构管理的组织联盟的情况。在这里需要知道的是，peers将组织范围的信息传播给具有同一个MSP身份的peer，而不管它们是否属于同一个实际组织。这是MSP定义的粒度或peer的配置的限制。
2）一个组织有不同的部门（称组织单位）， 它要向其授予对不同channel的访问权限。
两种处理方法：
- 定义一个MSP以适应所有组织成员的成员资格
该MSP的配置将包括根CA列表，中间CA和管理员证书; 会员身份将包括OU会员所属的组织单位。然后可以定义策略以捕获特定的成员OU，并且这些策略可以构成channel的读/写策略或chaincode的背书策略。这种方法的限制是，八卦peer将考虑具有其本地MSP下的成员资格身份的peer作为同一组织的成员，并且因此将其与组织范围的数据（例如他们的状态）进行闲话。 - 定义一个MSP来表示每个部门
- 这将涉及为每个部门指定一组根CA，中间CA和管理证书的证书，以便跨MSP不存在重叠的认证路径。这意味着，例如，使用每个细分的不同的中间CA。这里的缺点是管理多个MSP而不是一个MSP，但这避免了以前的方法中存在的问题。还可以通过利用MSP配置的OU扩展来为每个部门定义一个MSP。
3）将客户端与同一组织的peers分开。
在许多情况下， 需要将身份的 “类型” 从身份本身中检索出来（例如，可能需要认可的签名保证由peer派生，而不是仅充当 orderers 的客户端或节点）。
对这些要求的支持有限。
允许这种分离的一种方法是为每个节点类型创建一个单独的中间CA - 一个用于客户端，一个用于peer/orderer; 并配置两个不同的MSP - 一个用于客户端，一个用于peer/orderer。该组织应该访问的channel将需要包括两个MSP，而背书政策将仅利用peer的MSP。这将最终导致组织被映射到两个MSP实例，并将对peer和客户端交互的方式产生一定的后果。
八卦不会受到同样的组织的所有同行仍然属于一个MSP的严重影响。peer可以基于本地MSP的策略限制某些系统chaincode的执行。例如，如果请求由其本地MSP的管理员签名，而该管理人员只能是客户端（最终用户应该位于该请求的起点），peer将仅执行“joinChannel”请求。我们可以解决这个不一致的情况，如果我们接受只有作为peer/orderer MSP的成员的客户才是MSP的管理员。
使用这种方法考虑的另一点是，peer根据其本地MSP中的请求发起者的成员身份来授权事件注册请求。显然，由于请求的发起者是客户端，请求发起者始终注定属于与请求的peer不同的MSP，并且peer将拒绝该请求。
4）管理员和CA证书。
必须将 msp 管理证书设置为与 msp 为信任根或中间 ca 所考虑的任何证书不同。这是一种常见的 (安全) 做法, 即将成员资格组件的管理职责与颁发新证书和/或对现有认证的验证分开。
5）将中间CA列入黑名单
如前面部分所述，通过重新配置机制（手动重新配置本地MSP实例，以及适当构造用于channel的MSP实例的config_update信息）来实现MSP的重新配置。显然，有两种方法可以确保在MSP中考虑的中间CA不再被认为是MSP的身份验证：
- 将MSP重新配置为不再将该中间CA的证书包含在可信中间CA证书列表中。对于本地配置的MSP，这意味着该CA的证书将从
intermediatecerts文件夹中删除。 - 重新配置MSP来包括由信任根产生的CRL，该CRL会声明提及的中间CA的证书。
在目前的MSP实现中，我们只支持方法（1），因为它更简单，不需要将不再考虑的中间CA列入黑名单。
6）CAs和TLS CAs
MSP身份的根CA和MSP TLS证书的根CA（和相对中间CA）需要声明在不同的文件夹中。这是为了避免不同类别的证书之间的混淆。这里不禁止MSP身份和TLS证书重复使用相同的CA，但是最佳做法建议在生产环境中避免这种情况。