共用方式為

驗證服務網狀架構 REST 要求

  • 發行項

Service Fabric 叢集可以使用 X.509 憑證、Kerberos 或 X.509 憑證和 Kerberos 的組合來保護。 本文章說明：

  • 如何編輯叢集資訊清單，以讓 HttpGatewayEndpoints (REST 端點) 遵循特定的安全性解決方案。

  • 如何修改 REST 呼叫以使用每個解決方案 (X.509、Kerberos 或 X.509 和 Kerberos)。

Http 閘道與 X.509 安全性

在 Azure 和內部部署上，Service Fabric 的 REST 端點支援下列專案的 X.509 憑證：

  1. 用戶端的驗證和授權：Service Fabric 可以設定為根據憑證授與使用者存取權、系統管理員存取權或沒有 REST 用戶端的存取權。

  2. Service Fabric 節點的驗證：REST 用戶端可以驗證它們是否與其中一個正確的 Service Fabric 節點通訊。

  3. 訊息加密 (REST 要求和回應)。

注意

具有使用者存取權的用戶端只有讀取要求的權限 (例如，https://localhost:19007/Nodes?api-version=6.0)。 具有系統管理員存取權的用戶端擁有讀取要求和寫入要求的權限 (寫入要求範例，https://localhost:19007/Nodes/<NodeName>/$/Deactivate?api-version=6.0)。

叢集資訊清單變更

本節假設您已將叢集資訊清單設為使用 X.509 憑證。 若要深入瞭解，請參閱 使用 X.509 憑證保護叢集。

若要設定叢集以支援用戶端的驗證和授權， (User 和 管理員) 和 authentication of Service Fabric 節點，必須在叢集資訊清單中設定下列參數：

  • 每個節點類型的伺服器和用戶端憑證的指紋

    • <ClientCertificate X509FindValue="…" />

    • <ServerCertificate X509FindValue="…" />

  • 安全性區段

    • <參數名稱 ="ClientRoleEnabled"Value ="true"/>

    • <參數名稱 ="ServerAuthCredentialType"Value ="x509"/>

    • ClientAuthAllowedCommonNames 參數

    • AdminAllowedCommonNames 參數

    • ServerAuthAllowedCommonNames 參數

若要在叢集資訊清單上啟用 HttpGateway，該資訊清單已經受到 X.509 (保護，即叢集和用戶端/伺服器安全性已啟用) ，只需要這些變更：

  • 將所有 HttpGatewayEndpoint 項目的通訊協定設為 "https"。 例如， < HttpGatewayEndpoint Port=「19017」 Protocol=「HTTPs」/>

  • 啟用 HttpGateway 區段中的 HttpGateway。 例如， < 參數名稱=「IsEnabled」 Value=「true」/>

如何使用 REST API 與 X.509

針對受 X.509 保護的 HTTPS 要求，請建立相關的用戶端憑證 (ClientAuthAllowedCommonNames 或 AdminAllowedCommonNames 中指定的一般名稱) 和伺服器憑證指紋。

針對受 X.509 保護的 HTTP 端點，REST API 不會變更。 REST 呼叫的 URL、HTTP 標頭、要求和回應主體將會保持不變。

Http 閘道和 Kerberos (或 NTLM) 安全性

內部部署 Service Fabric 叢集可以使用 Kerberos 和 NTLM 來驗證和授權使用者和系統管理員用戶端，以及驗證 (Service Fabric 節點) 的伺服器。 不過，Kerberos 或 NTLM 都無法用來加密訊息。

注意

建議使用 HTTPS，並確保使用 Kerberos 時，叢集資訊清單會包含伺服器憑證。

強烈建議使用 Kerberos 安全性的客戶也使用 HTTPS。 這表示叢集必須有 X.509 伺服器憑證。 如此一來，伺服器憑證將用來加密通訊。

對用戶端而言，使用 Kerberos 驗證而不是 X.509 憑證的主要優點是 Kerberos 會簡化用戶端憑證管理。

Service Fabric 可讓用戶端透過 NTLM 而非 Kerberos 進行驗證。 Microsoft 不建議使用 NTLM。 如需詳細資訊，請參閱 實作者的安全性考慮。

盡可能使用 Kerberos，而不是 NTLM。

叢集資訊清單變更

本節假設您已將叢集資訊清單設為使用 Kerberos 驗證進行用戶端驗證，並使用 X.509 憑證進行伺服器驗證和加密。 若要深入瞭解，請參閱使用 Windows 安全性 保護叢集。

如何搭配使用 REST API 和 Kerberos

使用 REST API 與 Kerberos 啟用的叢集通訊時，不會變更 REST API。 REST 呼叫的 URL、HTTP 標頭、要求和回應主體將會保持不變。

不過，您必須遵循標準 Kerberos 與 NTLM HTTP 驗證程序。

請注意：

  • 大部分的 HTTP 用戶端會自動遵循此程序。

  • 如果已知伺服器受到 Kerberos/NTLM 保護，則可以從下列程式中的步驟 3 開始。 這會移除一個網路躍點。

REST 與 Kerberos 驗證程序

以下是使用 REST 的 Kerberos 驗證程式的範例序列。

  1. 呼叫 REST API 而不含任何其他 HTTP 標頭：

    GET http://localhost:19007/Nodes?api-version=6.0 HTTP/1.1  
User-Agent: Fiddler  
Host: localhost:19007

  2. Kerberos 可讓叢集以「401 未經授權」回覆，並將 www-驗證標頭設為 "Negotiate"：

    HTTP/1.1 401 Unauthorized  
Server: Microsoft-HTTPAPI/2.0  
WWW-Authenticate: Negotiate  
Date: Thu, 09 Jan 2014 08:20:55 GMT  
Content-Length: 0

  3. 用戶端現在必須利用服務的 SPN 連絡其 AD (同盟或相互)，以取得權杖。

    服務的 SPN 是所連絡 Service Fabric 節點的 HTTP\FQDN。

  4. AD 所傳回的權杖應該用於授權標頭中，格式為「交 < 涉權杖 > 」

    GET http://localhost:19007/Nodes?api-version=6.0 HTTP/1.1  
User-Agent: Fiddler  
Host: localhost:19007  
Authorization: Negotiate YH8GBisG<…>CSqGSIb3EgECAgYKKwYBBAGCNwICHqI/BD1OVE<…>RNT05E

  5. 伺服器將會驗證權杖，而且如果用戶端已獲授權完成作業，就會開始執行要求。

    HTTP/1.1 200 OK  
Content-Type: application/json; charset=utf-8  
Server: Microsoft-HTTPAPI/2.0  
Date: Thu, 09 Jan 2014 08:38:43 GMT  
Content-Length: 1457  

[{"Name":"Node4","IpAddressOrFQDN":"localhost","Type":"NodeType04","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":false,"UpgradeDomain":"MYUD1","FaultDomain":"fd:\/RACK2","Id":{"Id":"b5bd41bc26a079f4df3791b2b5d42e5"}},{"Name":"Node1","IpAddressOrFQDN":"localhost","Type":"NodeType01","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":true,"UpgradeDomain":"MYUD1","FaultDomain":"fd:\/RACK1","Id":{"Id":"10152272d1e44a94356a41d96dc9b466"}},{"Name":"Node2","IpAddressOrFQDN":"localhost","Type":"NodeType02","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":true,"UpgradeDomain":"MYUD2","FaultDomain":"fd:\/RACK2","Id":{"Id":"15091e9851978afe10f2f3ab37c1d2f0"}},{"Name":"Node5","IpAddressOrFQDN":"localhost","Type":"NodeType05","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":false,"UpgradeDomain":"MYUD2","FaultDomain":"fd:\/RACK1","Id":{"Id":"6e48b9c722325a66f805e2890bb7dd30"}},{"Name":"Node3","IpAddressOrFQDN":"localhost","Type":"NodeType03","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":true,"UpgradeDomain":"MYUD3","FaultDomain":"fd:\/RACK1","Id":{"Id":"880f1f5072c2c4805e9cb15ec710d083"}}]