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（例如msp1、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），它包含六個子文件夾和一個文件：
- 一個admincerts文件夾，其中包含每個對應於管理員證書的PEM文件
- 一個cacerts文件夾，其中包含了每個對應於根CA證書的PEM文件
- 一個intermediatecerts文件夾（可選），其中包含對應每個中間CA的證書的PEM文件
- 一個config.yaml文件（可選），其中配置了所有的OUs（組織單元）信息，OUs也就是yaml文件中定義的OrganizationalUnitIdentifier（組織單元ID）數組的集合，即OrganizationalUnitIdentifiers。其中需要考慮到如何證實成員們屬於組織成員，證書授權配置了的證書的相對路徑（例如,/cacerts/cacert.pem），並且在X.509證書的OU（ Organizational Units/組織單元）字段中將出現OrganizationalUnitIdentifier代表的實際的字符串（例如“COP”）。
- 一個crls文件夾（可選），其中包含了被考慮的CRLs
- 一個keystore文件夾，其中包含了一個帶有節點簽名密鑰的PEM文件；官方強調當前的RSA密鑰不受支持
- 一個signcerts文件夾，其中包含了一個帶有節點的X.509證書的PEM文件
- 一個tlscacerts文件夾（可選），其中包含了對應於每個TLS根CA證書的PEM文件
- 一個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的身份驗證。
- 重新配置MSP，考慮到的中間CA證書不再包括在可信的中間CA證書列表中。對於本地配置的MSP意味着該CA證書將從intermediatecerts文件夾中刪除。
- 重新配置MSP，以包含由信任根產生的CRL，該CRL會對所提到的中間CA證書執行廢棄。
在當前的MSP實現中，官方只支持方法(1)，因為它更簡單，不需要將不再考慮的中間CA列入黑名單。
6)CAs 與 TLS CAs
需要在不同的文件夾中聲明MSP標識的根CAs和MSP TLS證書的根CAs（以及相對中間的CAs）。這是為了避免不同級別的證書之間的混淆。在MSP標識和TLS證書中重用相同的CAs是不被禁止的，但是最佳實踐建議在生產中避免這種情況。