Membership Service Providers (MSP)
Membership service provider (MSP)是一个提供虚拟成员操作的管理框架的组件。
MSP抽取出签发和验证证书以及用户认证背后的所有加密机制和协议。 MSP可以定义自己的身份概念，以及这些身份管理的规则（身份验证）和身份验证（签名生成和验证）。
一个Hyperledger Fabric blockchain network 能够被一个或更多的MSP控制。这提供了会员操作的模块化，以及跨不同会员标准和体系结构的互操作性。
MSP Configuration
要初始化MSP的一个实例，需要在每个peer和order（在启用peer和order签名时）本地指定其配置，并在channel上启用peer，order，client身份验证和相应的
signature verification（authentication）。这个过程由channel所有成员共同参与。
首先，对于每个MSP，需要指定名称以引用网络中的MSP（例如，msp1，org2和org3.divA）。这是在channel中引用consortium，organization或organization division的MSP的成员资格的名称。 这也称为MSP标识符或MSP ID。 MSP标识符必须是每个MSP实例唯一的。 例如，两个具有相同标识符的MSP实例在系统通道发生时被检测到，则order设置将失败。
在MSP的默认实现的情况下，需要指定一组参数以允许身份（证书）验证和签名验证。 这些参数由RFC5280推导出来，其中包括：
- 自签名（X.509）证书列表，构成信任根源。
- X.509证书的列表，用于表示中间CA;这些证书应该通过信托根源中的一个证书来证明;中间CA是可选参数
- 一个具有连接到信任根节点中一个证书的根列表，来代表该MSP的管理员;这些证书的所有者有权要求更改此MSP配置（例如根CA，中间CA）。
- 本MSP有效成员的组织单位列表，应包含其X.509证书; 这是一个可选的配置参数，当例如多个组织利用相同的信任根和中间CA时使用，并为其成员保留了OU字段。
- 每个对应于所列出的（中间或根）MSP证书颁发机构之一的证书撤销列表（CRL）的列表; 这是一个可选参数。
- X.509证书的列表，用于表示提供商认为的中间TLS CA; 这些证书应该通过TLS信任根源中的一个证书进行认证; 中间CA是可选参数。
满足本MSP的有效身份，需要满足下述条件：
- 它们是X.509证书的形式，具有可靠的证书路径，恰好是信任证书根目录之一。
- 它们不包括在任何CRL中。
- 他们在X.509证书结构的OU字段中列出MSP配置的一个或多个组织单位。
MSP身份验证规则
如MSP描述中所述，MSP可以配置有一组根证书颁发机构（rCA），以及可选的一组中间证书颁发机构（iCAs）。一个MSP的iCA证书必须有一个确定的rCA或者iCA签署。MSP的配置可能包含证书吊销列表或CRL。如果任何MSP的根CA构列在CRL中，则MSP的配置不得包含任何iCA和CRL中的其他CA，否则MSP安装将失败。
每个rCA都是认证树的根。也就是说，每个rCA可以是一个或多个iCAs的证书的签名者，并且这些iCAs将是其他iCAs或用户证书的签名者。以下是几个例子：
默认MPS实例接受相应的由权限机构签署有效身份X.509证书。在上图中，只有iCA11，iCA12，iCA2，iCA3和rCA3签署的证书才被视为有效。内部节点签署的证书将被拒绝。
请注意，如果在MSP配置中指定了一个或多个organization units(OU)，则同样会影响证书的有效性。回想一下，OU在MSP配置中被指定为两个值的对（parent-cert，ou-string），分别表示认证OU的CA和实际OU身份。如果证书C由在MSP配置中指定了OU的iCA或rCA签署，则如果除其他要求之外，其中包含ou-string作为其OU字段的一部分，则C被认为是有效的
除了验证相关的参数外，为了使MSP启用实例化的节点进行签名或认证，需要指定：
- 用于由节点签名的签名密钥（目前只支持ECDSA密钥）。
- 该节点的X.509证书，是MSP验证参数下的有效身份。
值得注意的是，MSP永不过期身份，只能将它们添加到适当的crl。此外，目前不支持执行TLS证书的吊销。
How to generate MSP certificates and their signing keys?
要生成X.509证书以提供其MSP配置，应用程序可以使用Openssl。 我们强调，在Hyperledger Fabric中，不支持包括RSA密钥在内的证书。
作为替代，只能够使用crytogen工具。
Hyperledger Fabric CA也可用于生成配置MSP所需的密钥和证书。
MSP setup on the peer and orderer side
要设置本地MSP（peer或order），管理员应创建一个包含六个子文件夹
和一个文件的文件夹（例如$ MY_PATH / mspconfig）：
admincerts文件夹包括每个对应于管理员证书的PEM文件。cacerts文件夹,包括每个对应于根CA证书的PEM文件。- (optional)
intermediatecerts文件夹,包含每个对应于中间CA的证书PEM文件。 - (optional)
config.yaml文件，包含所考虑的OU的信息。
后者被定义为由其中OrganizationalUnitIdentifiers。其中Certificate表示认证机构（根或中间）的证书的相对路径，该证书颁发机构（根或中间）应用于证明此组织单位的成员例如(eg../cacerts/cacert.pem)。同时，OrganizationalUnitIdentifiers表示预期出现在X.509证书OU字段（例如“COP”）中的实际字符串。 - (optional)
crls文件夹，包含所考虑的CRL(Certificate Revocation List )。 keystore文件夹，含具有节点的签名密钥的PEM文件; 我们强调当前不支持RSA密钥。signcerts文件夹，包含节点X.509证书的PEM文件。- (optional)
tlscacerts文件夹，包含每个对应于TLS根CA证书的PEM文件。 - (optional)
tlsintermediatets文件夹,包括每个对应于中间TLS CA证书的PEM文件。
在节点的配置文件（对peer的core.yaml文件和orderer的orderer.yaml）中，需要指定mspconfig文件夹的路径和节点MSP的MSP标识符。mspconfig文件夹的路径预计与FABRIC_CFG_PATH相关，并且作为peer的参数mspConfigPath以及orderer的LocalMSPID的值。
节点MSP的标识符作为peer的参数localMspId、order的参数LocalMSPID提供。这些变量可以通过环境变量使用peer的CORE前缀（例如CORE_PEER_LOCALMSPID）和order的ORDERER前缀（例如ORDERER_GENERAL_LOCALMSPID）进行覆盖。请注意，对于order设置，需要生成并向order提供系统channel的genesis block。
“local”MSP的重新配置只能手动进行，并且要求peer或order进程重新启动。在随后的版本中，我们旨在提供在线/动态重新配置。
Channel MSP setup
在系统的起始阶段，需要指定出现在网络中的所有MSP的验证参数，并将其包含在系统channel的Genesis block中。MSP验证参数由MSP标识符，信任证书的根，中间CA和管理证书以及OU规范和CRL组成。系统genesis block在其order的阶段提供给orderers，并允许它们验证channel的创建请求。如果系统genesisblock包含具有相同标识符的两个MSP，orderers则拒绝genesis block，网络的引导将失败。
对于应用channel，仅管理channel的MSP的验证需要驻留在channel的genesis block中的组件。我们强调应用程序的责任是在指示一个或多个peer加入该channel之前确保正确的MSP配置信息被包括在信道的起源块（或最新配置块）中。我们强调应用程序的责任是在一个或多个peer加入该channel之前确保正确的MSP配置信息被包括在信道的genesis block（或最新配置块）中。
在通过configtxgen工具帮助引导channel时，可以通过将MSP的验证参数包含在mspconfig文件夹中，并在configtx.yaml的相关部分中设置该路径来配置通道MSP。
MSP的管理员证书的所有者通过创建config_update对象，来实现信道上的MSP的重新配置，包括与该MSP的CA相关联的证书吊销列表。然后由管理员管理的客户端应用程序将向本MSP的channel发布此更新。
Best Practices
organizations/corporations与MSP之间的映射
我们建议org和MSP之间存在一对一的映射。如果选择不同的映射类型的映射，则需要考虑以下内容：
一个org对应多个MSP。这对应于一个org的情况，由MSP代表的各种各样的不同的部门，无论是出于管理独立的原因，还是出于隐私的原因。 在这种情况下，peer只能由单个MSP拥有，并且不会将来自其他MSP的peer识别为同一org的peer。这暗示着，同一个MSP下的peer可以相互分享资源，而不是整个org下的peer都可以相互分享数据。
一个MSP对应多个org。这对应于由类似会员架构管理的组织联盟的情况。这种情况下，peer会将org共享消息，发送到同一个MSP范围内的peer中，不管是否实在同一个org中。
一个org有不同的division（称organizational unit），这样它需要能够连接到不同的channel中
有两种处理方式：
- 定义一个MSP容纳所有org的成员。该MSP的配置将包括根CA列表，中间CA和管理员证书；成员身份将包含成员所属的组织单位中（ou）。然后可以定义特定的策略来捕获特定的organization unit(ou),这些策略可以构成channel的读写策略或chaincode的背书策略。这种方式的限制是，Gossip peer将具有其本地MSP的成员资格身份的peer作为同一org中的成员，并与其分享organisation-scoped数据。
- 每个部门(division)定义一个MSP。这需要为每个division指定一组根CA，中间CA和管理员Certs的证书，以MSP不存在重叠的认证路径。这意味着，每个subdivision的中间CA会被占用。这里的缺点是管理多个MSP而不是一个MSP，但这避免了以前的方法中存在的问题。还可以利用MSP配置的OU扩展来为每个部门定义一个MSP。
将client同一个org中的peer区分开
在许多情况下，要求身份的“类型”可以从身份本身检索(eg.这可能需要，endorment的保证是由peer派生的，而非用户或仅作为orderer执行的节点)
下述是对这些要求的有限支持。
许这种分离的一种方法是为每个节点类型创建一个单独的中间CA - 一个用于client，一个用于对peer/order; 并配置两个不同的MSP - 一个用于client，一个用于peer/order。org要访问的channel将需要包括两个MSP，背书策略只会利用peer节点的MSP。 这将最终导致org被映射到两个MSP实例，并将对peer和client交互的方式产生一定的影响。
Gossip 八卦不会受到同样的组织的所有同行仍然属于一个MSP的严重影响。对等体可以将某些系统链码的执行限制为基于本地MSP的策略。例如，如果请求由其本地MSP的管理员签名，只能作为客户端（最终用户应该坐在该请求的起点），对等体才会执行“joinChannel”请求。如果我们接受仅作为对等/成员MSP成员的客户将成为MSP的管理员，我们可以解决这个不一致之处。
该方法要考虑的另一点是，对等体根据其本地MSP中的请求发起者的成员身份来授权事件注册请求。显然，由于请求的发起者是客户端，请求始发者始终注定属于与所请求的对等体不同的MSP，并且对等体将拒绝该请求。
管理员和CA证书
将MSP管理员证书设置为与MSP 或中间CA所考虑的任何证书不同。这是一种常见（安全）的做法，将成员组成部分的管理职责与颁发新证书和/或对现有证书的验证分开。root of trust
将中间CA列入黑名单
如前面部分所述，通过重新配置机制（本地MSP实例的手动重新配置，以及通过正确构造config_update的MSP实例的消息）来实现MSP的重新配置。显然，有两种方法来确保在MSP中考虑的中间CA不再被认为是MSP的身份验证：
将MSP重新配置为不再将该中间CA的证书包含在可信中间CA证书列表中。对于本地配置的MSP，这意味着该CA的证书将从intermediatecerts文件夹中删除。
重新配置MSP以包含由信任根产生的CRL，该CRL会谴责提及的中间CA证书。
在目前的MSP实现中，我们只支持方法（1），因为它更简单，不需要将不再考虑的中间CA列入黑名单。
CA和TLS CA
需要在不同的文件夹中声明MSP身份的根CA和MSP TLS证书的根CA（和相对中间CA）。这是为了避免不同类别的证书之间的混淆。不允许为MSP身份和TLS证书重复使用相同的CA，但最佳实践建议避免在生产中使用相同的CA。
======================================
如果有转载请注明出处！
[英文原版]
Membership Service Providers (MSP)