Autentisera Service Fabric REST-begäranden

  • Artikel

Ett Service Fabric-kluster kan skyddas med X.509-certifikat, Kerberos eller en kombination av X.509-certifikat och Kerberos. I den här artikeln beskrivs:

  • Så här redigerar du klustermanifestet så att HttpGatewayEndpoints (REST-slutpunkten) följer den specifika säkerhetslösningen.

  • Ändra REST-anropen så att de fungerar med varje lösning (X.509, Kerberos eller X.509 med Kerberos).

Http Gateway med X.509 Security

Rest-slutpunkter för Service Fabric-stöd i Azure och lokalt med X.509-certifikat för:

  1. Autentisering och auktorisering av klienter: Service Fabric kan konfigureras för att ge användare åtkomst, administratörsåtkomst eller ingen åtkomst till en REST-klient, beroende på certifikaten.

  2. Autentisering av Service Fabric-noder: REST-klienter kan kontrollera att de kommunicerar med en av rätt Service Fabric-noder.

  3. Kryptering av meddelanden (REST-begäranden och svar).

Anteckning

Klienter med användaråtkomst har bara behörighet för läsbegäranden (till exempel https://localhost:19007/Nodes?api-version=6.0). Klienter med administratörsåtkomst har behörighet för läsbegäranden och skrivbegäranden (exempel på skrivbegäran, https://localhost:19007/Nodes/<NodeName>/$/Deactivate?api-version=6.0).

Ändringar i klustermanifest

Det här avsnittet förutsätter att du redan har ett klustermanifest konfigurerat för att använda X.509-certifikat. Mer information finns i Skydda ett kluster med X.509-certifikat.

För att konfigurera ett kluster för autentisering och auktorisering av klienter (användare och Admin) och autentisering av Service Fabric-noder, måste följande parametrar anges i klustermanifestet:

  • Tumavtryck för server- och klientcertifikat för varje nodtyp

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

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

  • Avsnittet Säkerhet

    • <Parameternamn="ClientRoleEnabled" Value="true" />

    • <Parameternamn="ServerAuthCredentialType" Value="X509" />

    • Parametern ClientAuthAllowedCommonNames

    • Parametern AdminAllowedCommonNames

    • Parametern ServerAuthAllowedCommonNames

Om du vill aktivera HttpGateway på ett klustermanifest, som redan är skyddat med X.509 (dvs. kluster- och klient-/serversäkerhet redan är aktiverat), krävs endast dessa ändringar:

  • Ange Protokoll för alla HttpGatewayEndpoint-element till "https". Till exempel <HttpGatewayEndpoint Port="19017" Protocol="https"/>

  • Aktivera HttpGateway i avsnittet HttpGateway. Till exempel <Parameternamn="IsEnabled" Value="true"/>

Använda REST-API:er med X.509

För en X.509-skyddad HTTPS-begäran skapar du det relevanta klientcertifikatet (vars eget namn anges i ClientAuthAllowedCommonNames eller AdminAllowedCommonNames) och tumavtrycket för servercertifikatet.

För en X.509-skyddad HTTP-slutpunkt ändras inte REST-API:erna. URL:er, HTTP-huvuden, begärande- och svarskroppar för REST-anropet ändras inte.

Http Gateway med Kerberos-säkerhet (eller NTLM)

Lokalt kan Service Fabric-kluster använda Kerberos och NTLM för att autentisera och auktorisera användar- och administratörsklienter samt autentisera servrar (Service Fabric-noder). Kerberos eller NTLM kan dock inte användas för att kryptera meddelandena.

Anteckning

Vi rekommenderar att du använder HTTPS och ser till att klustermanifestet innehåller servercertifikat när du använder Kerberos.

Vi rekommenderar starkt att kunder som använder Kerberos-säkerhet även använder HTTPS. Det innebär att klustret måste ha X.509-servercertifikat. På så sätt används servercertifikaten för att kryptera kommunikationen.

Den främsta fördelen med att använda Kerberos-autentisering i stället för X.509-certifikat för klienter är att Kerberos förenklar hanteringen av klientcertifikat.

Med Service Fabric kan klienter autentiseras via NTLM i stället för Kerberos. Microsoft rekommenderar inte användning av NTLM. Mer information finns i Säkerhetsöverväganden för implementerare.

Använd Kerberos i stället för NTLM när det är möjligt.

Ändringar i klustermanifest

Det här avsnittet förutsätter att du redan har ett klustermanifest konfigurerat för att använda Kerberos för klientautentisering och X.509-certifikat för serverautentisering och -kryptering. Mer information finns i Skydda ett kluster med Windows-säkerhet.

Använda REST-API:er med Kerberos

REST-API:er ändras inte när du använder REST-API:er för att kommunicera med ett Kerberos-aktiverat kluster. URL:er, HTTP-huvuden, begärande- och svarskroppar för REST-anropet ändras inte.

Du måste dock följa standardprocessen för Kerberos- och NTLM HTTP-autentisering.

Tänk på följande:

  • De flesta HTTP-klienter följer automatiskt den här processen.

  • Om servern är känd för att skyddas med Kerberos/NTLM kan man börja i steg 3 i följande process. Detta tar bort ett nätverkshopp.

REST med Kerberos-autentiseringsprocess

Följande är en exempelsekvens av en Kerberos-autentiseringsprocess med hjälp av REST.

  1. Anropa ett REST-API utan ytterligare HTTP-huvuden:

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

  2. Ett Kerberos-aktiverande kluster kommer att svara med 401 Obehörig och ställa in www-authenticate-huvudet på "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. Klienten måste nu hämta token genom att kontakta dess AD (federerat eller ömsesidigt) med tjänstens SPN.

    TJÄNSTENS SPN är HTTP\FQDN för den Service Fabric-nod som kontaktas".

  4. Token som returneras av AD ska användas i auktoriseringshuvudet med formatet "Negotiate token" (Förhandla 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. Servern autentiserar token och om klienten har behörighet att slutföra åtgärden börjar den köra begäran.

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