你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

对 Service Fabric REST 请求 v8.2 进行身份验证

  • 项目

可以使用 X.509 证书、Kerberos 或 X.509 证书和 Kerberos 的组合来保护 Service Fabric 群集。 本文介绍：

  • 如何编辑群集清单，使 HttpGatewayEndpoints（REST 终结点）遵循特定的安全解决方案。

  • 如何修改 REST 调用以处理每个解决方案（X.509、Kerberos，或者 X.509 与 Kerberos 的组合）。

具有 X.509 安全性的 HTTP 网关

在 Azure 和本地，Service Fabric 的 REST 终结点支持将 X.509 证书用于：

  1. 客户端的身份验证和授权：可以将 Service Fabric 配置为授予用户访问 REST 客户端的访问权限、管理员访问权限或不授予对 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 证书保护群集。

若要将群集配置为支持客户端 (用户身份验证和授权，以及 Service Fabric 节点的管理员) 和身份验证，必须在群集清单中设置以下参数：

  • 每个节点类型的服务器和客户端证书的指纹

    • <ClientCertificate X509FindValue="…" />

    • <ServerCertificate X509FindValue="…" />

  • Security 节

    • <Parameter Name="ClientRoleEnabled" Value="true" />

    • <Parameter Name="ServerAuthCredentialType" Value="X509" />

    • ClientAuthAllowedCommonNames 参数

    • AdminAllowedCommonNames 参数

    • ServerAuthAllowedCommonNames 参数

若要在群集清单上启用 HttpGateway，该清单已使用 X.509 (即群集和客户端/服务器安全性) 启用，只需进行以下更改：

  • 将所有 HttpGatewayEndpoint 元素的 Protocol 设置为“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 标头、请求和响应正文将保持不变。

具有 Kerberos（或 NTLM）安全性的 HTTP 网关

在本地，Service Fabric 群集可以使用 Kerberos 和 NTLM 对用户和管理员客户端进行身份验证和授权，以及对服务器 (Service Fabric 节点) 进行身份验证。 但是，无法使用 Kerberos 或 NTLM 来加密消息。

备注

建议在使用 Kerberos 时使用 HTTPS 并确保群集清单包含服务器证书。

我们强烈建议使用 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. 在不附加任何 HTTP 标头的情况下调用 REST API：

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

  2. Kerberos 将使群集回复“401 未授权”并将 www-authenticate 标头设置为“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. 现在，客户端需要通过将其 AD（联合或相互身份验证）与服务的 SPN 相联系来获取令牌。

    服务的 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"}}]