fabric2.0官方文档翻译：成员服务MSP
上篇文章Membership主要是一些解释性工作：介绍了MSP的结构以及以及MSP中每个文件的作用等，那我们就知道了本地MSP和通道MSP两个概念。
本文档则提供有关MSP的设置和一些好的使用实践的具体细节。
MSP的结构
MSP的默认实现，需要指定一组参数以允许身份（证书）验证和签名验证。这些参数包括：
- 自签名的根CA证书列表（X.509证书）
- 中间CA列表（X.509证书），中间CA是可选参数
- 此MSP的管理员列表（X.509证书）
- 组织单位列表，列表成员被认为是此MSP代表的组织的一部分（CA颁发的有效证书，但是证书中的OUs不属于这个列表的则不属于这个MSP成员？）这是一个可选的配置参数
- 证书吊销列表（CRL）的列表，这是一个可选参数
- 自签名的TLS根证书列表（X.509证书）
- TLS中间CA列表（X.509证书），TLS中间CA是可选参数
此MSP实例的有效身份必须满足以下条件：
它们采用X.509证书的形式，带有可验证的证书路径，可以精确地指向信任证书的根之一;
它们不包含在任何CRL中；
他们在其X.509证书结构的字段中列出了MSP配置的一个或多个组织单位OU。(MSP中的OUs列表是可选参数，不是可以不设置吗，不设置的时候有默认的？)
除了以上七个与验证相关的参数之外，为了使MSP能让实例化它的节点进行签名或验证，还需要指定两个参数（和前篇文章列出的包含九个文件一样。。）：
- 节点用于签名的签名密钥（当前仅支持ECDSA密钥）；
- 节点的X.509证书，即在此MSP的验证参数下的有效身份。
重要的是要注意，MSP身份永远不会过期。只能通过将它们添加到适当的CRL中来撤销它们。此外，当前不支持强制撤销TLS证书。
如何生成MSP证书及其签名密钥？
要生成X.509证书以提供其MSP配置，应用程序可以使用Openssl。我们强调在Hyperledger Fabric中不支持包括RSA密钥的证书。
或者，可以使用一种cryptogen工具，其操作在《入门指南》中进行了说明 。
此外，还可以使用Hyperledger Fabric CA 。
peer节点和order节点的MSP setup(设置)
- 要设置本地MSP，首先管理员应创建一个$MY_PATH/mspconfig文件夹，包含六个子文件夹和一个文件。六个子文件夹中是生成好的证书和密钥（不包含中间CA和中间TLSCA），一个文件是设置OUs列表的config.yaml文件。
- 在节点的配置文件（peer节点的core.yaml文件，排序节点的orderer.yaml）中，需要指定mspconfig文件夹的路径以及节点MSP的MSP标识符。mspconfig文件夹的路径建议peer节点为FABRIC_CFG_PATH/mspConfigPath以及order节点为FABRIC_CFG_PATH/LocalMSPDir 。节点MSP的标识符MSPID建议peer节点为localMspId，排序节点为LocalMSPID。可以通过环境变量覆盖这些文件中的配置，peer节点使用前缀CORE_PEER_（例如CORE_PEER_LOCALMSPID）和排序节点使用前缀ORDERER_（例如ORDERER_GENERAL_LOCALMSPID）。请注意，对于排序节点的设置，需要提供给排序节点系统通道的创世区块配置。创世区块中的MSP配置将在后面的部分说明。
重新配置 “本地” MSP只能手动进行，并且需要重新启动peer节点和order节点进程。在后续版本中，我们旨在提供在线/动态重新配置（即，无需通过使用节点管理的系统链码来停止节点）。
MSP的组织单位列表配置
为了配置此MSP的有效成员应在其X.509证书中包括的组织单位的列表，需要在MSP根文件夹中的config.yaml文件中指定MSP包含的组织单位（简称OU）标识符。您可以在下面找到一个示例：
上面的示例声明了两个组织单位标识符：Commercial和Administrators。如果MSP身份包含这些组织单位标识符中的至少一个，则该身份有效。该Certificate字段是指CA或中间CA证书路径，对于具有特定OU的对象要在该路径下验证对应的CA身份（意思是说在颁发证书时，commercial身份都是由cacert1颁发的；Administrations的身份是由cacert2颁发？那cacert1颁发的administrators身份是否有效呢？）。该路径是相对于MSP根文件夹的，不能为空。
身份分类
默认的MSP实现使组织可以根据其x509证书的OU将身份进一步分类为客户端clients，管理员admins，对等体peers和订购者orders：
如果身份在网络上进行交易，则应将其分类为客户端client。
如果身份处理诸如将peer加入通道或签署通道配置更新事务之类的管理任务，则应将其分类为管理员admin。
如果身份背书或提交交易，则该身份应归类为peer。
如果身份属于order节点，则应将其分类为order。
config.yaml文件中还包括了的NodeOU部分的配置示例：
(你可以指定每个特定的组织单位身份必须由某个CA来认证，但是通常不这样做，因为后续可能要在组织中增加新的CA或中间CA，而不用重新颁发所有证书，因此下面的示例注释掉Certificate。)
当启用身份分类时，NodeOUs.Enable设置为true。然后通过设置NodeOUs.ClientOUIdentifier（NodeOUs.AdminOUIdentifier，NodeOUs.PeerOUIdentifier， NodeOUs.OrdererOUIdentifier）键，定义客户端（管理，对等体，订货者）组织单元身份标识符。
ClientOUIdentifier的值包含两部分：OrganizationalUnitIdentifier是x509证书需要包含的OU值，才能将其视为客户端（分别为admin，peer，orderer），如果此字段为空，则不这个身份分类视为不存在。另一个部分Certificate是可选的，作用如前所述。
（key对应的是组织单元身份概念，value对应的是msp证书中的属性；通过key-value将证书中的ous属性值和代表的身份类别联系起来。）
如果NodeOUs.Enable设置为true，却没有定义任何的组织单元身份键值，则视为不启用身份分类功能。
身份可以使用组织单位分类为client，管理员admin，peer或订购者order。这四个分类是互斥的。必须先启用1.1通道功能，然后才能将身份分类为client或peer。需要启用1.4.3通道功能，以将身份分类为admin或order。
分类允许将身份分类为管理员admin（并执行管理员操作），而无需将证书存储在MSP 的admincerts文件夹中。该 admincerts文件夹可以保留为空，并且可以通过注册OU为admin的身份来创建管理员。admincerts文件夹中的证书仍将授予被授予管理员角色，前提是它们拥有client或admin OU。
（未启动OU身份分类前，一个组织中的身份分类可以分为两种：包含在admincerts文件夹中的身份是管理员ORG.admin，和包括管理员及普通成员的ORG.member）
（个人理解：config.yaml文件中的两个部分，第一个部分OrganizationalUnitIdentifiers是定义了哪些OU属于这个MSP；第二个部分NodeOUs是要不要启用NodeOUs功能对身份进行分类，并列出有哪些分类，如果不启用的话，在后面的权限配置中就不能使用根据OU细分的身份分类）
——————————————————————————————————————————未校对分割线
通道MSP设置
在系统生成时，需要指定出现在网络中的所有MSP的验证参数，并将其包括在系统通道的生成块中。回想一下，MSP验证参数由MSP标识符，信任证书的根，中间CA和admin证书以及OU规范和CRL组成。系统创世块在设置阶段提供给订购者，并允许他们对渠道创建请求进行身份验证。如果订购者包括两个具有相同标识符的MSP，订购者将拒绝该系统创始块，因此网络的自举将失败。
对于应用程序通道，仅管理该通道的MSP的验证组件需要驻留在该通道的创世块中。我们强调，应用程序有责任在指示一个或多个同等体加入该通道之前，确保正确的MSP配置信息包含在该通道的创始块（或最新配置块）中。
当使用configtxgen工具引导通道时，可以通过在mspconfig文件夹中包含MSP的验证参数，并在中的相关部分中设置该路径来配置通道MSP configtx.yaml。
通过MSP config_update管理员证书之一的所有者创建对象，可以在通道上重新配置 MSP，包括宣布与该MSP的CA相关的证书吊销列表。然后，由管理员管理的客户端应用程序将向此MSP出现的渠道宣布此更新。
最佳实践
在本节中，我们将详细介绍常见情况下MSP配置的最佳实践。
1）组织/公司与MSP之间的映射
我们建议组织与MSP之间存在一对一的映射。如果选择了其他类型的映射，则需要考虑以下几点：
一个使用各种MSP的组织。这对应于一个组织的情况，该组织出于管理独立性原因或出于隐私原因，包括多个部门，每个部门均由其MSP代表。在这种情况下，对等方只能由单个MSP拥有，而不会将具有其他MSP身份的对等方识别为同一组织的对等方。这样做的含义是，对等点可以通过八卦组织范围的数据与属于同一部门成员的一组对等点共享，而不与构成实际组织的所有提供者共享。
多个组织使用单个MSP。这对应于由类似的成员资格体系管理的组织联盟的情况。这里需要知道，对等节点会将组织范围的消息传播到在同一MSP下具有标识的对等节点，而不管它们是否属于同一实际组织。这是对MSP定义的粒度和/或对等方配置的限制。
2）一个组织具有不同的部门（例如组织单位）， 要向其授予访问不同渠道的权限。
有两种处理方法：
定义一个MSP以容纳所有组织成员的成员资格。该MSP的配置将由根CA，中间CA和管理证书的列表组成；成员身份将包括OU成员所属的组织单位（）。然后可以定义策略以捕获特定的成员OU，并且这些策略可以构成通道的读/写策略或链码的认可策略。这种方法的局限性在于，八卦对等方会将其本地MSP下具有成员身份的对等方视为同一组织的成员，因此会与他们进行组织范围的数据八卦（例如，其状态）。
定义一个MSP代表每个部门。这将涉及为每个部门指定一组用于根CA，中间CA和管理证书的证书，从而使跨MSP的证书路径不重叠。这意味着，例如，每个细分采用不同的中间CA。此处的缺点是管理多个MSP，而不是一个，但是这避免了以前方法中存在的问题。也可以通过利用MSP配置的OU扩展为每个部门定义一个MSP。
3）将客户与同一组织的对等方分开。
在许多情况下，需要从身份本身中检索身份的“类型”（例如，可能需要保证认可是由对等方派生的，而不是仅作为订购者的客户端或节点派生的）。
对此类要求的支持有限。
允许这种分离的一种方法是为每种节点类型创建一个单独的中间CA-一种用于客户端，一种用于对等体/订购者。并配置两个不同的MSP-一个用于客户端，一个用于对等/订购者。该组织应该访问的渠道将需要包括两个MSP，而认可策略将仅利用引用对等方的MSP。这最终将导致组织被映射到两个MSP实例，并且会对同级和客户端交互的方式产生一定的影响。
八卦不会受到严重影响，因为同一组织的所有同级仍将属于一个MSP。对等方可以将某些系统链码的执行限制为基于本地MSP的策略。例如，如果请求由其本地MSP的管理员（只能是客户端）（最终用户应位于该请求的源头）的管理员签名，则对等方将仅执行“ joinChannel”请求。如果我们接受成为对等/订购者MSP成员的唯一客户端将是该MSP的管理员，则可以解决这种不一致的情况。
使用此方法要考虑的另一点是，对等方根据其本地MSP中请求发起者的成员身份来授权事件注册请求。显然，由于请求的始发者是客户端，因此始终将请求始发者视为与请求的对等方不同的MSP，并且对等方会拒绝该请求。
4）管理员和CA证书。
重要的是，将MSP管理员证书设置为与MSP为或中间CA所考虑的任何证书都不相同。这是一种常见的（安全）做法，将成员资格组件的管理职责与新证书的颁发和/或现有证书的验证分开。root of trust
5）将中间CA列入黑名单。
如前几节所述，MSP的重新配置是通过重新配置机制（针对本地MSP实例的手动重新配置，以及config_update针对通道的MSP实例的正确构造的消息）实现的。显然，有两种方法可以确保不再考虑在MSP中考虑的中间CA用于该MSP的身份验证：
重新配置MSP，使其不再在受信任的中间CA证书列表中包含该中间CA的证书。对于本地配置的MSP，这意味着该CA的证书已从intermediatecerts文件夹中删除。
重新配置MSP，使其包含由信任根发出的CRL，该CRL声明上述中间CA的证书。
在当前的MSP实现中，我们仅支持方法（1），因为它更简单并且不需要将不再考虑的中间CA列入黑名单。
6）CA和TLS CA
需要在不同的文件夹中声明MSP身份的根CA和MSP TLS证书的根CA（以及相对的中间CA）。这是为了避免不同类别的证书之间的混淆。禁止将相同的CA用于MSP身份和TLS证书，但是最佳实践建议在生产中避免这种情况。