Membership Service Providers (MSP)
Membership service provider (MSP)是一个提供虚拟成员操做的管理框架的组件。html
MSP抽取出签发和验证证书以及用户认证背后的全部加密机制和协议。 MSP能够定义本身的身份概念，以及这些身份管理的规则（身份验证）和身份验证（签名生成和验证）。web
一个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安装将失败。ide
每一个rCA都是认证树的根。也就是说，每一个rCA能够是一个或多个iCAs的证书的签名者，而且这些iCAs将是其余iCAs或用户证书的签名者。如下是几个例子：
svg
默认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的信息。
后者被定义为由其中<Certificate，OrganizationalUnitIdentifier>组成的一个yaml的数组，被称为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。
======================================
若是有转载请注明出处！