您现在访问的是微软AZURE全睃版技术文档网站,若需覝访问由世纪互蝔违蝥的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

对服务结构 REST 请求进行身份验证

可以使用 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 客户端进行访问,具体取决于证书。

  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 参数

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

  • 将所有 HttpGatewayEndpoint 元素的 Protocol 设置为“https”。 例如,<HttpGatewayEndpoint Port="19017" Protocol="https"/>

  • 在 HttpGateway 节中启用 HttpGateway。 例如,<Parameter Name="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 返回的令牌,格式为 "Negotiate <token> "

    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"}}]