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是不被禁止的，可是最佳實踐建議在生產中避免這種狀況。