Udostępnij za pośrednictwem

Uwierzytelnianie żądań REST usługi Service Fabric

  • Artykuł

Klaster usługi Service Fabric można zabezpieczyć przy użyciu certyfikatów X.509, Protokołu Kerberos lub kombinacji certyfikatów X.509 i Protokołu Kerberos. W tym artykule opisano:

  • Jak edytować manifest klastra, aby punkt końcowy HTTPGatewayEndpoints (REST) był zgodny z określonym rozwiązaniem zabezpieczeń.

  • Jak zmodyfikować wywołania REST do pracy z każdym rozwiązaniem (X.509, Kerberos lub X.509 przy użyciu protokołu Kerberos).

Brama HTTP z zabezpieczeniami X.509

Na platformie Azure i lokalnie punkty końcowe REST usługi Service Fabric obsługują certyfikaty X.509 dla:

  1. Uwierzytelnianie i autoryzacja klientów: można skonfigurować usługę Service Fabric w celu udzielenia dostępu użytkownika, dostępu administratora lub braku dostępu do klienta REST w zależności od certyfikatów.

  2. Uwierzytelnianie węzłów usługi Service Fabric: klienci REST mogą sprawdzić, czy komunikują się z jednym z odpowiednich węzłów usługi Service Fabric.

  3. Szyfrowanie komunikatów (żądania REST i odpowiedzi).

Uwaga

Klienci z dostępem użytkowników mają uprawnienia tylko do żądań odczytu (na przykład https://localhost:19007/Nodes?api-version=6.0). Klienci z dostępem administratora mają uprawnienia do żądań odczytu i żądań zapisu (przykład żądania zapisu). https://localhost:19007/Nodes/<NodeName>/$/Deactivate?api-version=6.0

Zmiany manifestu klastra

W tej sekcji założono, że masz już manifest klastra skonfigurowany do używania certyfikatów X.509. Aby dowiedzieć się więcej, zobacz Zabezpieczanie klastra przy użyciu certyfikatów X.509.

Aby skonfigurować klaster do obsługi uwierzytelniania i autoryzacji klientów (użytkownika i Administracja) oraz uwierzytelniania węzłów usługi Service Fabric, należy ustawić następujące parametry w manifeście klastra:

  • Odcisk palca certyfikatów serwera i klienta dla każdego typu węzła

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

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

  • Sekcja zabezpieczeń

    • <Nazwa parametru="ClientRoleEnabled" Value="true" />

    • <Nazwa parametru="ServerAuthCredentialType" Value="X509" />

    • Parametr ClientAuthAllowedCommonNames

    • Parametr AdminAllowedCommonNames

    • Parametr ServerAuthAllowedCommonNames

Aby włączyć funkcję HttpGateway w manifeście klastra, który jest już zabezpieczony za pomocą X.509 (czyli zabezpieczenia klastra i klienta/serwera są już włączone), wymagane są tylko następujące zmiany:

  • Ustaw wartość "https" dla wszystkich elementów httpGatewayEndpoint. Na przykład <HttpGatewayEndpoint Port="19017" Protocol="https"/>

  • Włącz funkcję HttpGateway w sekcji HttpGateway. Na przykład <nazwa parametru="IsEnabled" Value="true"/>

Jak używać interfejsów API REST z interfejsem X.509

W przypadku zabezpieczonego żądania HTTPS X.509 utwórz odpowiedni certyfikat klienta (którego nazwa pospolita jest określona w clientAuthAllowedCommonNames lub AdminAllowedCommonNames) i odcisk palca certyfikatu serwera.

W przypadku zabezpieczonego punktu końcowego HTTP X.509 interfejsy API REST nie zmieniają się. Adresy URL, nagłówki HTTP, żądania i treść odpowiedzi wywołania REST będą niezmienione.

Brama HTTP z zabezpieczeniami protokołu Kerberos (lub NTLM)

Lokalne klastry usługi Service Fabric mogą używać protokołu Kerberos i NTLM do uwierzytelniania i autoryzacji klientów użytkowników i administratorów, a także uwierzytelniania serwerów (węzły usługi Service Fabric). Nie można jednak użyć protokołu Kerberos lub NTLM do szyfrowania komunikatów.

Uwaga

Zaleca się użycie protokołu HTTPS i upewnienie się, że manifest klastra zawiera certyfikaty serwera podczas korzystania z protokołu Kerberos.

Zdecydowanie zalecamy klientom korzystającym z zabezpieczeń protokołu Kerberos, aby również używali protokołu HTTPS. Oznacza to, że klaster musi mieć certyfikaty serwera X.509. W ten sposób certyfikaty serwera będą używane do szyfrowania komunikacji.

Główną zaletą korzystania z uwierzytelniania Kerberos zamiast certyfikatów X.509 dla klientów jest to, że protokół Kerberos upraszcza zarządzanie certyfikatami klienta.

Usługa Service Fabric umożliwia uwierzytelnianie klientów za pośrednictwem protokołu NTLM zamiast protokołu Kerberos. Firma Microsoft nie zaleca używania protokołu NTLM. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące zabezpieczeń dla implementatorów.

Używaj protokołu Kerberos zamiast NTLM zawsze, gdy jest to możliwe.

Zmiany manifestu klastra

W tej sekcji założono, że masz już manifest klastra skonfigurowany do używania protokołu Kerberos do uwierzytelniania klienta i certyfikatów X.509 na potrzeby uwierzytelniania i szyfrowania serwera. Aby dowiedzieć się więcej, zobacz Zabezpieczanie klastra przy użyciu Zabezpieczenia Windows.

Jak używać interfejsów API REST przy użyciu protokołu Kerberos

Interfejsy API REST nie zmieniają się w przypadku używania interfejsów API REST do komunikowania się z klastrem z włączoną obsługą protokołu Kerberos. Adresy URL, nagłówki HTTP, żądania i treść odpowiedzi wywołania REST będą niezmienione.

Należy jednak postępować zgodnie ze standardowym procesem uwierzytelniania HTTP protokołu Kerberos i NTLM.

Należy pamiętać, że:

  • Większość klientów HTTP automatycznie postępuje zgodnie z tym procesem.

  • Jeśli serwer jest znany do zabezpieczenia za pomocą protokołu Kerberos/NTLM, można rozpocząć od kroku 3 w następującym procesie. Spowoduje to usunięcie jednego przeskoku sieciowego.

Rest z procesem uwierzytelniania Kerberos

Poniżej przedstawiono przykładową sekwencję procesu uwierzytelniania Kerberos przy użyciu interfejsu REST.

  1. Wywołaj interfejs API REST bez dodatkowych nagłówków HTTP:

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

  2. Protokół Kerberos umożliwia klastrowi odpowiedź z odpowiedzią 401 Brak autoryzacji i ustawi nagłówek www-authenticate na wartość "Negocjuj":

    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 musi teraz uzyskać token, kontaktując się z usługą AD (federacyjną lub wzajemne) z nazwą SPN usługi.

    Nazwa SPN usługi to HTTP\FQDN węzła usługi Service Fabric, z który jest kontaktowany".

  4. Token zwrócony przez usługę AD powinien być używany w nagłówku autoryzacji w formacie "Negocjuj <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. Serwer uwierzytelni token i jeśli klient ma autoryzację do ukończenia operacji, rozpocznie wykonywanie żądania.

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