Sdílet prostřednictvím

Ověřování požadavků SERVICE Fabric REST

  • Článek

Cluster Service Fabric je možné zabezpečit pomocí certifikátů X.509, protokolu Kerberos nebo kombinace certifikátů X.509 a protokolu Kerberos. Tento článek popisuje:

  • Postup úprav manifestu clusteru tak, aby koncové body HttpGateway (koncový bod REST) byly v souladu s konkrétním řešením zabezpečení.

  • Jak upravit volání REST tak, aby fungovala s jednotlivými řešeními (X.509, Kerberos nebo X.509 s protokolem Kerberos)

Brána HTTP se zabezpečením X.509

V Azure i v místním prostředí podporují koncové body REST Service Fabric použití certifikátů X.509 pro:

  1. Ověřování a autorizace klientů: Service Fabric je možné nakonfigurovat tak, aby v závislosti na certifikátech poskytoval přístup uživatelů, přístup správce nebo žádný přístup ke klientovi REST.

  2. Ověřování uzlů Service Fabric: Klienti REST můžou ověřit, že komunikují s jedním ze správných uzlů Service Fabric.

  3. Šifrování zpráv (požadavky REST a odpovědi)

Poznámka

Klienti s uživatelským přístupem mají oprávnění pouze pro žádosti o čtení (například https://localhost:19007/Nodes?api-version=6.0). Klienti s přístupem správce mají oprávnění k žádostem o čtení a zápisu (například https://localhost:19007/Nodes/<NodeName>/$/Deactivate?api-version=6.0).

Změny manifestu clusteru

V této části se předpokládá, že už máte manifest clusteru nakonfigurovaný tak, aby používal certifikáty X.509. Další informace najdete v tématu Zabezpečení clusteru pomocí certifikátů X.509.

Pokud chcete nakonfigurovat cluster tak, aby podporoval ověřování a autorizaci klientů (uživatel a Správa) a ověřování uzlů Service Fabric, musí být v manifestu clusteru nastavené následující parametry:

  • Kryptografický otisk serverových a klientských certifikátů pro každý typ uzlu

    • <ClientCertificate X509FindValue="..." />

    • <ServerCertificate X509FindValue="..." />

  • Část Zabezpečení

    • <Název parametru="ClientRoleEnabled" Value="true" />

    • <Název parametru="ServerAuthCredentialType" Value="X509" />

    • Parametr ClientAuthAllowedCommonNames

    • Parametr AdminAllowedCommonNames

    • Parametr ServerAuthAllowedCommonNames

Pokud chcete povolit HttpGateway v manifestu clusteru, který už je zabezpečený pomocí X.509 (to znamená, že zabezpečení clusteru a klienta/serveru je už povolené), vyžadují se jenom tyto změny:

  • Nastavte protokol všech elementů HttpGatewayEndpoint na https. Například <HttpGatewayEndpoint Port="19017" Protocol="https"/>

  • V části HttpGateway povolte HttpGateway. Příklad: Název parametru <="IsEnabled" Value="true"/>

Jak používat rozhraní REST API s X.509

V případě požadavku HTTPS zabezpečeného X.509 vytvořte příslušný klientský certifikát (jehož běžný název je zadaný v polích ClientAuthAllowedCommonNames nebo AdminAllowedCommonNames) a kryptografický otisk certifikátu serveru.

U koncového bodu HTTP zabezpečeného X.509 se rozhraní REST API nemění. Adresy URL, hlavičky HTTP, požadavky a odpovědi volání REST se nezmění.

Brána HTTP se zabezpečením protokolu Kerberos (nebo NTLM)

V místním prostředí můžou clustery Service Fabric používat protokoly Kerberos a NTLM k ověřování a autorizaci klientů uživatelů a správců a také k ověřování serverů (uzlů Service Fabric). K šifrování zpráv však nelze použít protokol Kerberos nebo NTLM.

Poznámka

Při použití protokolu Kerberos doporučujeme používat protokol HTTPS a zajistit, aby manifest clusteru zahrnoval certifikáty serveru.

Důrazně doporučujeme, aby zákazníci, kteří používají zabezpečení Kerberos, používali také PROTOKOL HTTPS. To znamená, že cluster musí mít certifikáty serveru X.509. Tímto způsobem se certifikáty serveru použijí k šifrování komunikace.

Hlavní výhodou použití ověřování protokolem Kerberos místo certifikátů X.509 pro klienty je, že protokol Kerberos zjednodušuje správu klientských certifikátů.

Service Fabric umožňuje ověřování klientů pomocí protokolu NTLM místo protokolu Kerberos. Společnost Microsoft nedoporučuje používat protokol NTLM. Další informace najdete v tématu Aspekty zabezpečení pro implementátory.

Pokud je to možné, používejte místo protokolu NTLM protokol Kerberos.

Změny manifestu clusteru

V této části se předpokládá, že již máte manifest clusteru nakonfigurovaný tak, aby používal protokol Kerberos pro ověřování klientů a certifikáty X.509 pro ověřování a šifrování serveru. Další informace najdete v tématu Zabezpečení clusteru pomocí Zabezpečení Windows.

Jak používat rozhraní REST API s protokolem Kerberos

Rozhraní REST API se při komunikaci s clusterem s podporou protokolu Kerberos pomocí rozhraní REST API nemění. Adresy URL, hlavičky HTTP, požadavky a odpovědi volání REST se nezmění.

Budete ale muset postupovat podle standardního procesu ověřování protokolem Kerberos a NTLM HTTP.

Poznámky:

  • Většina klientů HTTP tento proces automaticky provádí.

  • Pokud je známo, že server je zabezpečený protokolem Kerberos/NTLM, můžete začít krokem 3 v následujícím procesu. Tím se odebere jeden segment směrování sítě.

REST s procesem ověřování kerberos

Následuje příklad posloupnosti procesu ověřování protokolem Kerberos s využitím REST.

  1. Volání rozhraní REST API bez dalších hlaviček HTTP:

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

  2. Protokol Kerberos umožňuje clusteru odpovědět zpět s chybou 401 Neautorizováno a hlavičku www-authenticate nastaví na 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. Klient teď potřebuje získat token kontaktováním služby AD (federované nebo vzájemné) s hlavním názvem služby (SPN) služby.

    Hlavní název služby je HTTP\FQDN kontaktovaného uzlu Service Fabric.

  4. Token vrácený službou AD by se měl použít v autorizační hlavičce ve formátu Token Negotiate<>.

    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. Server token ověří, a pokud má klient oprávnění k dokončení operace, spustí požadavek.

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