Membership Service Providers (MSP)
本文将介绍有关MSPs的设置和最佳实践的详细方案。
Membership Service Providers (MSP)是一个旨在提供成员操作体系结构抽象的组件。
尤其是MSP抽象出发布和验证证书的所有加密机制、协议以及用户身份验证。MSP可以自定义身份概念，以及这些身份被管理的规则（身份验证）和认证加密（签名生成和验证）。
一个Hyperledger Fabric区块链网络可以由一个或多个MSPs管理。这提供了成员操作的模块化，以及跨不同成员标准和体系结构的相互操作性。
在本文的其余部分中，将会详细介绍由Hyperledger Fabric支持的MSP实现的设置，并讨论了有关其使用的最佳实践。
MSP配置
要设置MSP的一个实例，在所有的peer和orderer（启用peer和orderer签名）的本地需指定它的配置，并在channel上启用peer、orderer和客户端的身份验证，并为通过和channel中所有成员分别签名验证（鉴定）。
首先，为了在网络中引用MSP（例如msp1、org2和org3.divA），每个MSP都需要指定一个名称。这个名称是被一个channel所使用的属于MSP的成员规则（配置）可能是一个集团、机构或是机构部门采用的名称。这也被称为MSP标识符或MSP ID。MSP标识符必须是唯一的每个MSP实例。例如，如果在系统channel检测时发现到两个MSP实例，那么orderer的设置将会失败。
在MSP的缺省实现中，需要指定一组参数来允许身份（证书）验证和签名验证。这些参数由RFC5280推导出来，包括如下：
- 一个自签署的（X.509）证书列表来构成信任的根
- 把一个表示为中间CAs的X.509证书列表作为提供者的证书验证；这些证书应当由信任的根证书中的一个证书进行认证；中间CAs是可选参数
- 一个（X.509）证书的列表和授信的根证书集的证书路径作为MPS的管理员，这些证书的所有者被授权请求对MSP配置进行更改（例如，根ca，中间CAs）
- 这个MSP的有效成员应该包含在他们的X.509证书中，这是一个可选的配置参数，例如用在多个组织使用相同的信任根和中间CAs，并为其成员预留了一个OU（ Organizational Units/组织单元）字段。.
- 证书撤销列表集（CRLs——certificate revocation lists）中的每一个列表都对应一个列出的（中间或者根）MSP证书颁发机构；这是一个可选参数
- 一个自签署的（X.509）证书列表构成了授信TLS证书的TLS根
- 提供者考虑一个表示为中间TLS CAs的X.509证书列表，这些证书应该由授信的TLS根证书中的一个证书进行认证，中间CAs是可选参数
为了满足以下条件，需要使用这个MSP实例的有效身份：
- 它们以证书的形式存在，并具有可验证的证书路径，以完全信任证书的根
- 不包括在任何证书撤销列表（CRLs——certificate revocation lists）中
- 在证书结构的OU（ Organizational Units/组织单元）字段中列出了MSP配置的一个或多个组织单元
除了验证相关的参数之外，为了使MSP能够在实例化的节点上进行签名或验证，还需要做出如下指定：
- 用于在节点上签署的签名键（目前仅支持ECDSA键）
- 节点的X.509证书，在MSP的验证参数下是一个有效的身份
重要的是要注意到MSP的身份永远不会过期;只有将它们添加到相应的证书撤销列表（CRLs——certificate revocation lists）中才能撤销它们。此外，目前还没有对强制撤销TLS证书的支持
如何生成MSP证书及其签名密钥？
为了生成用于提供其MSP配置的X.509证书，应用程序可以使用Openssl。在Hyperledger Fabric中没有包括对RSA密钥在内的证书的支持。
另一种方法是使用密码工具（cryptogen tool），在Hyperledger Fabric 1.0 从零开始（八）——Fabric多节点集群生产部署详细介绍了如何使用该工具生成证书配置文件
还可以使用Hyperledger Fabric CA来生成配置MSP所需的密钥和证书
MSP设置peer和orderer
若想要设置一个本地MSP（peer或是排序节点），管理员应该创建一个文件夹（例如$mypath/mspconfig），它包含六个子文件夹和一个文件：
- 一个admincerts文件夹，其中包含每个对应于管理员证书的PEM文件
- 一个cacerts文件夹，其中包含了每个对应于根CA证书的PEM文件
- 一个intermediatecerts文件夹（可选），其中包含对应每个中间CA的证书的PEM文件
- 一个config.yaml文件（可选），其中配置了所有的OUs（组织单元）信息，OUs也就是yaml文件中定义的OrganizationalUnitIdentifier（组织单元ID）数组的集合，即OrganizationalUnitIdentifiers。其中需要考虑到如何证实成员们属于组织成员，证书授权配置了的证书的相对路径（例如,/cacerts/cacert.pem），并且在X.509证书的OU（ Organizational Units/组织单元）字段中将出现OrganizationalUnitIdentifier代表的实际的字符串（例如“COP”）。
- 一个crls文件夹（可选），其中包含了被考虑的CRLs
- 一个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和orderer的LocalMSPID。这些变量可以通过当前环境使用CORE前缀赋给peer（例如：CORE_PEER_LOCALMSPID）以及使用ORDERER前缀赋给orderer（例如：ORDERER_GENERAL_LOCALMSPID）来重写。注意，对于orderer设置，需要生成，并向orderer提供系统channel的创世区块。
下面将详细介绍创世区块的MSP配置需求。
目前对于“local”MSP的重新配置只能手动进行，并且需要重新启动peer或orderer的进程。在随后的版本中，官方的目标是提供在线/动态重新配置（例如，不需要使用节点管理的系统链代码来停止节点）。
补充一点，当我们使用Hyperledger Fabric 1.0 从零开始（八）——Fabric多节点集群生产部署中的方案，即生成msp中述说的第二种方案生成对应证书后，在peerOrganizations\xxx.xxx.com\peers\peer0.xxx.xxx.com\msp的目录中可以发现上述所介绍的相关目录，以此可以进一步加深本步的了解。
MSP Channel设置
在系统的生成过程中，需要指定网络中出现的所有MSPs的验证参数，并包含在系统通道的创世区块中。回看一下前文中提到MSP的验证参数包括MSP标识符、信任证书的根、中间CA和管理证书，以及OU规范和CRLs。系统创世区块在设置阶段提供给orderers，并允许他们对channel创建请求进行身份验证，如果后者包含两个带有相同标识的MSPs，那么Orderers将会拒绝系统创世区块，并因此导致网络引导失败。
对于应用程序channels，只有管理channel的MSPs的验证组件需要驻留在channel的创世区块中。官方强调，应用程序的责任是确保正确的MSP配置信息包含在一个channel的创世区块（或最近的配置块）中，在一个或多个peer加入channel之前。
当使用configtxgen工具来引导创建一个channel时，可以通过在mspconfig文件夹中包含MSP的验证参数来配置channel的MSPs，并在configtx.yaml中的相关部分设置该路径。
在channel上重新配置MSP，包括与MSP的CAs相关联的证书撤销列表的声明，这是通过MSP的一个管理员证书的所有者通过创建一个config_update对象来实现的。由admin管理的客户端应用程序将向存在此MSP的channel发布更新。
最佳实践
下文将详细介绍在常见的场景中MSP配置的最佳实践。
1)组织/公司和MSPs之间的映射
官方建议组织（organization）和MSPs之间存在一对一的映射。如果选择了一种不同的映射类型，则需要考虑以下问题：
- 一个使用各种MSPs的组织。这与一个组织的情况相对应，其中包括由其MSP所代表的各种不同的部门，或者出于管理独立的原因，或者出于隐私方面的原因。在这种情况下，一个peer只能由一个MSP拥有，并且不能识别来自其他MSPs相同组织的其他成员的身份。它的含义是，peers可以通过gossip organization-scoped的数据与一组相同细分的成员共享，而不是由构成实际组织的全部提供者组成。
- 多个组织使用一个MSP。这与一个由类似的成员架构管理联盟组织的情况相对应。这里需要知道的是，peers可以将组织范围的消息广播给在相同的MSP下具有相同身份的peers，而不管它们是否属于同一个实际的组织。这是MSP定义的粒度限制，使用and/or来配置。
2)一个组织有不同的部门(比如组织下各单位)，它想要授予访问不同channel的权限
有两种方案可以实现这个目的：
- 定义一个MSP给所有组织成员提供成员身份。MSP的配置将包括一个根CAs、中间CAs和管理证书的列表，并且成员身份将包括一个成员所属的组织单位(OU)，然后可以定义策略以通知特定OU的成员，这些策略可能构成一个channel的读/写策略或chaincode的背书策略。这种方法的一个局限性是，gossip peers将默认在本地MSP下所属peers的成员身份都作为同一组织成员，并且gossip peers因此也将组织范围内的数据进行散播（例如：它们的状态）。
- 定义一个MSP来表示每个部门。这将为每个涉及的指定部门设置并提供包含根CAs、中间CAs和管理员证书等一组证书，这样就没有跨MSPs的重叠认证路径，举例来说明其含义，即每个细分部门都有一个不同的中间CA。这个方案的缺点是要管理多个MSPs，而不是一个MSPs，但是这绕过了第一个方案中出现的问题。还可以通过利用MSP配置的OU扩展来为每个部门定义一个MSP。
3)将客户端从相同组织的peers中分离
在许多情况下，身份的“类型”是可以从身份本身中获取的（例如，可能需要拥有peers的派生而不是客户端或者单独的节点orderers来保证背书）。
对这些要求的背书是有限的。
允许这种分离的一种方法是为每个节点类型创建一个单独的中间CA——一个用于客户端，另一个用于peers/orderers，并配置两个不同的MSPs——一个用于客户端，另一个用于peers/orderers。该组织在访问的channel需要同时包含两个MSPs，而背书策略只会影响peers引用的MSP。
Gossip不会受到太大的影响，因为同一组织的所有peers仍然属于一个MSP。peers可以将某些系统chaincode的执行限制在本地MSP的策略中。例如，如果请求是由作为客户端（用户应该发起该请求的最终起点）的本地MSP的管理员签署的，peers才会执行“joinChannel”请求。如果我们认可仅客户端作为peer/orderer MSP的成员，也为该MSP的管理员，那么我们可以绕过这种不一致的地方。
此方法的另一个要点是，peers在本地MSP中基于请求发起者的成员资格授权事件注册请求。显然，由于请求的发起者是一个客户端，请求发起者总是注定要属于一个不同的MSP，而不是请求的peers，而peers会拒绝这个请求。
4)管理员和CA证书
设置MSP管理证书与任意一个被视为该MSP的信任根或中间CAs证书不同是很重要的。这是一种常见的（安全）实践，可以将成员组件的管理职责与新证书的颁发和/或现有证书的验证分离开来。
5)中间CA黑名单
正如前面所提到的，MSP的重新配置是通过重新配置机制实现的（本地MSP实例的手动重新配置，以及通过正确构造一个channel的MSP实例的config_update消息）。有两种方法可以确保在MSP中考虑到的中间CA不再被认为是MSP的身份验证。
- 重新配置MSP，考虑到的中间CA证书不再包括在可信的中间CA证书列表中。对于本地配置的MSP意味着该CA证书将从intermediatecerts文件夹中删除。
- 重新配置MSP，以包含由信任根产生的CRL，该CRL会对所提到的中间CA证书执行废弃。
在当前的MSP实现中，官方只支持方法(1)，因为它更简单，不需要将不再考虑的中间CA列入黑名单。
6)CAs 与 TLS CAs
需要在不同的文件夹中声明MSP标识的根CAs和MSP TLS证书的根CAs（以及相对中间的CAs）。这是为了避免不同级别的证书之间的混淆。在MSP标识和TLS证书中重用相同的CAs是不被禁止的，但是最佳实践建议在生产中避免这种情况。