Hyperledger MSP服务化
成员服务提供者（MSP，Member service provider）是一个提供抽象化成员操作框架的组件。MSP将颁发与校验证书，以及用户认证背后的所有密码学机制与协议都抽象了出来。一个MSP可以自己定义身份，以及身份的管理（身份验证）与认证（生成与验证签名）规则。一个Hyperledger Fabric 区块链网络可以被一个或者多个MSP管理，这提供了模块化的成员操作，以及兼容不同成员标准与架构互操作性。
MSP配置
要想初始化一个MSP实例，每一个peer节点和orderer节点都需要在本地指定其配置，并在channel上启用peer节点、orderer节点及client的身份的验证与各自的签名验证。注意channel上的全体成员均参与此过程。
每个MSP都需要一个特定的名字（例如msp1、org2、org3.divA）
在MSP默认情况下，身份验证和签名需要指定一组参数，这些参数推到自RFC5280
一个自签名的证书列表（满足X.509标准）以构成信任源
一个用于表示该MSP验证过的中间CA的X.509的证书列表，用于证书的校验。这些证书应该被信任源的一个证书所认证；中间的CA则是可选参数
一个具有可验证路径的X.509证书列表（该路径通往信任源的一个证书），以表示该MSP的管理员。这些证书的所有者对MSP配置的更改要求都是经过授权的（例如根CA，中间CA）
一个证书吊销列表（CRLs）的清单，清单的每一项对应于一个已登记的（中间的或根）MSP证书颁发机构（CA）
一个自签名的证书列表（满足X.509标准）以构成TLS信任源，服务于TLS证书
一个表示该provider关注的中间TLS CA的X.509证书列表。这些证书应该被TLS信任源的一个证书所认证；中间的CA则是可选参数
对于MSP实例，有效的身份应该符合以下条件：
符合 X.509 证书标准，且具有一条可验证的路径（该路径通往信任源的一个证书）
没有保存在任何CRL中（证书吊销列表）
它们列出了一个或多个MSP配置的组织单元（列出的位置是它们X.509证书结构的OU区内）。
另外，MSP身份永远不会过期，他们只能通过添加到合适的CRL上来被撤销，此外，现阶段不支持吊销TLS证书。
如何生成MSP证书及其签名密钥
要想生成X.509证书以满足MSP配置，应用程序可以使用Openssl。我们必须强调：在Hyperledger Fabric中，不支持包括RSA密钥在内的证书。或者直接使用Fabric提供的cryptogen工具来生成证书。Hyperledger Fabric CA也可用于生成配置MSP所需的密钥及证书。
peer&orderer侧 MSP 的设置
要想（为peer节点或orderer节点）建立本地MSP，管理员应创建一个文件夹（如$MY_PATH/mspconfig）并在其下包含6个子文件夹与一个文件：
必须包含的文件夹：
admincerts下的 PEM文件对应管理员证书cacerts对应于一个根CA的证书文件夹
keystore包含一个PEM文件及节点的签名密钥；我们必须强调：现阶段还不支持RSA密钥文件夹
signcerts包含一个PEM文件及节点的X.509证书（可选）文件夹
intermediatecerts包含如下PEM文件：每个PEM文件对应于一个中间CA的证书（可选）文件
config.yaml包含相关OU的信息；后者作为<Certificate,OrganizationalUnitIdentifier>（一个被称为OrganizationalUnitIdentifiers的yaml数组的项）的一部分被定义；其中Certificate表示通往（根或中间）CA的证书的相对路径，这些CA用于为组织成员发证（如./cacerts/cacert.pem）；OrganizationalUnitIdentifier表示预期会出现在X.509证书中的实际字符串（如“COP”）（可选）文件夹
tlsintermediatecerts包含如下PEM文件：每个PEM文件对应于一个中间TLS CA的证书（可选）文件夹
tlscacerts包含如下PEM文件：每个PEM文件对应于一个根TLS根CA的证书（可选）文件夹
crls包含相关CRL
对peer节点而言配置文件是core.yaml文件，对orderer节点而言则是orderer.yaml文件 我们需要指定到mspconfig文件夹的路径，以及节点的MSP的MSP标识符。到mspconfig文件夹的路径预期是一个对FABRIC_CFG_PATH的相对路径，且会作为参数mspConfigPath和LocalMSPDir的值分别提供给peer节点和orderer节点。节点的MSP的MSP标识符则会作为参数localMspId和LocalMSPID的值分别提供给peer节点和orderer节点。运行环境可以通过为peer使用CORE前缀（例如CORE_PEER_LOCALMSPID）及为orderer使用ORDERER前缀（例如 ORDERER_GENERAL_LOCALMSPID）对以上变量进行覆写。注意：对于orderer的设置，我们需要生成并为orderer提供系统channel的创世区块。MSP配置对该区块的需求详见后面的章节。
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拥有，且不会识别相同组织内标识在其他MSP的节点。这就是说，peer节点可以与相同子分支下的一系列其他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，但是最佳做法建议在生产环境中避免这种情况。
最好的实践
- 为组织和MSP建立映射
MSP Identity Validity Rules
如MSP描述中所述，MSP可以配置有一组根证书颁发机构（rCA）和可选的一组中间证书颁发机构（iCA）。 MSP的iCA证书必须由MSP的其中一个rCA或iCA签署。 MSP的配置可能包含证书撤销列表或CRL。如果在CRL中列出了任何MSP的根证书颁发机构，则MSP的配置中不得包含任何也包含在CRL中的iCA，否则MSP设置将失败。 每个rCA是认证树的根。也就是说，每个rCA可以是一个或多个iCA的证书的签名者，这些iCA将是其他iCA或用户证书的签名者。这里有一些例子：
rCA1 rCA2 rCA3
/ \ | |
iCA1 iCA2 iCA3 id
/ \ | |
iCA11 iCA12 id id
|
id
对于上图来讲，MPS接收的X.509证书，只有被 iCA11, iCA12, iCA2, iCA3 an rCA3 签名的，才会被认为是有效的，被其他中间CA机构签名的证书，都会被认为无效。
请注意，如果在MSP配置中指定了一个或多个组织单位，则证书的有效性也会受到同样的影响。回想一下，组织单位在MSP配置中被指定为一对两个值，分别表示证明组织单位的证书颁发机构（parent-cert，ou-string）和实际组织单位标识符。如果证书C由在MSP配置中已经为其指定了组织单位的iCA或rCA签名，则在其他要求中，如果其包括作为其OU字段的一部分的字符串，则C被认为是有效的。
