Hyperledger Fabric Membership Service Providers (MSP)——成员服务

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（例如msp一、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实现中身份验证的有效性的更多信息能够参考Hyperledger Fabric MSP Identity Validity Rules——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），它包含六个子文件夹和一个文件：

1. 一个admincerts文件夹，其中包含每一个对应于管理员证书的PEM文件
2. 一个cacerts文件夹，其中包含了每一个对应于根CA证书的PEM文件
3. 一个intermediatecerts文件夹（可选），其中包含对应每一个中间CA的证书的PEM文件
4. 一个config.yaml文件（可选），其中配置了全部的OUs（组织单元）信息，OUs也就是yaml文件中定义的OrganizationalUnitIdentifier（组织单元ID）数组的集合，即OrganizationalUnitIdentifiers。其中须要考虑到如何证明成员们属于组织成员，证书受权配置了的证书的相对路径（例如,/cacerts/cacert.pem），而且在X.509证书的OU（ Organizational Units/组织单元）字段中将出现OrganizationalUnitIdentifier表明的实际的字符串（例如“COP”）。
5. 一个crls文件夹（可选），其中包含了被考虑的CRLs
6. 一个keystore文件夹，其中包含了一个带有节点签名密钥的PEM文件；官方强调当前的RSA密钥不受支持
7. 一个signcerts文件夹，其中包含了一个带有节点的X.509证书的PEM文件
8. 一个tlscacerts文件夹（可选），其中包含了对应于每一个TLS根CA证书的PEM文件
9. 一个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的身份验证。

1. 从新配置MSP，考虑到的中间CA证书再也不包括在可信的中间CA证书列表中。对于本地配置的MSP意味着该CA证书将从intermediatecerts文件夹中删除。
2. 从新配置MSP，以包含由信任根产生的CRL，该CRL会对所提到的中间CA证书执行废弃。

在当前的MSP实现中，官方只支持方法(1)，由于它更简单，不须要将再也不考虑的中间CA列入黑名单。

6)CAs 与 TLS CAs

须要在不一样的文件夹中声明MSP标识的根CAs和MSP TLS证书的根CAs（以及相对中间的CAs）。这是为了不不一样级别的证书之间的混淆。在MSP标识和TLS证书中重用相同的CAs是不被禁止的，可是最佳实践建议在生产中避免这种状况。