Authentifizieren von REST-Anforderungen des Dienst-Fabrics
Ein Service Fabric-Cluster kann mithilfe von X.509-Zertifikaten, Kerberos oder einer Kombination aus X.509-Zertifikaten und Kerberos gesichert werden. Dieser Artikel beschreibt Folgendes:
Bearbeiten des Clustermanifests, damit HttpGatewayEndpoints (REST-Endpunkt) der spezifischen Sicherheitslösung entsprechen.
Ändern der REST-Aufrufe, damit sie jede Lösung (X.509, Kerberos oder X.509 mit Kerberos) unterstützen.
HTTP-Gateway mit X.509-Sicherheit
In Azure und lokal unterstützen REST-Endpunkte von Service Fabric X.509-Zertifikate für:
Authentifizierung und Autorisierung von Clients: Service Fabric kann so konfiguriert werden, dass abhängig von den Zertifikaten Benutzerzugriff, Administratorzugriff oder kein Zugriff auf einen REST-Client erteilt wird.
Authentifizierung von Service Fabric-Knoten: REST-Clients können überprüfen, ob sie mit einem der richtigen Service Fabric-Knoten kommunizieren.
Verschlüsselung von Nachrichten (REST-Anforderungen und -Antworten).
Hinweis
Clients mit Benutzerzugriff haben nur eine Berechtigung für Leseanforderungen (z. B. https://localhost:19007/Nodes?api-version=6.0). Clients mit Administratorzugriff haben eine Berechtigung für Lese- und Schreibanforderungen (Beispiel für eine Leseanforderung https://localhost:19007/Nodes/<NodeName>/$/Deactivate?api-version=6.0).
Änderungen am Clustermanifest
In diesem Abschnitt wird davon ausgegangen, dass Sie bereits ein Clustermanifest für die Verwendung von X.509-Zertifikaten konfiguriert haben. Weitere Informationen finden Sie unter Sichern eines Clusters mithilfe von X.509-Zertifikaten.
Um einen Cluster so zu konfigurieren, dass die Authentifizierung und Autorisierung von Clients (Benutzer und Admin) sowie die Authentifizierung von Service Fabric-Knoten unterstützt wird, müssen die folgenden Parameter im Clustermanifest festgelegt werden:
Fingerabdruck des Server- und Clientzertifikats für jeden Knotentyp
<ClientCertificate X509FindValue="…" />
<ServerCertificate X509FindValue="…" />
Abschnitt "Security"
<Parameter Name="ClientRoleEnabled" Value="true" />
<Parameter Name="ServerAuthCredentialType" Value="X509" />
ClientAuthAllowedCommonNames-Parameter
AdminAllowedCommonNames-Parameter
ServerAuthAllowedCommonNames-Parameter
Um HttpGateway in einem Clustermanifest zu aktivieren, das bereits mit X.509 gesichert ist (d. h. die Cluster- und Client-/Serversicherheit sind bereits aktiviert), sind nur diese Änderungen erforderlich:
Legen Sie das Protokoll aller HttpGatewayEndpoint Elemente a "https" fest. Beispiel <: HttpGatewayEndpoint Port="19017" Protocol="https"/>
Aktivieren Sie HttpGateway im Abschnitt "HttpGateway". Beispiel: <Parametername="IsEnabled" Value="true"/>
Verwendung von REST-APIs mit X.509
Erstellen Sie für eine sichere X.509-HTTPS-Anforderung das entsprechende Clientzertifikat (dessen allgemeiner Name unter ClientAuthAllowedCommonNames oder AdminAllowedCommonNames angegeben ist) und den Fingerabdruck für das Serverzertifikat.
Bei einem sicheren X.509-HTTP-Endpunkt werden die REST-APIs nicht geändert. Die URLs, HTTP-Header, Anforderungs- und Antworttexte des REST-Aufrufs bleiben unverändert.
HTTP-Gateway mit Kerberos- (oder NTLM-)Sicherheit
Lokale Service Fabric-Cluster können Kerberos und NTLM zum Authentifizieren und Autorisieren der Benutzer- und Administratorclients sowie zur Authentifizierung von Servern (Service Fabric-Knoten) verwenden. Allerdings kann Kerberos oder NTLM nicht verwendet werden, um Nachrichten zu verschlüsseln.
Hinweis
Es wird empfohlen, HTTPS zu verwenden und sicherzustellen, dass das Clustermanifest bei Verwendung von Kerberos Serverzertifikate enthält.
Kunden, die Kerberos-Sicherheit verwenden, wird dringend empfohlen, ebenfalls HTTPS zu verwenden. Dies bedeutet, dass der Cluster über X.509-Serverzertifikate verfügen muss. Auf diese Weise werden die Serverzertifikate zum Verschlüsseln der Kommunikation verwendet.
Der Hauptvorteil bei der Verwendung der Kerberos-Authentifizierung anstelle von X.509-Zertifikaten für Clients besteht darin, dass Kerberos die Verwaltung der Clientzertifikate vereinfacht.
Service Fabric ermöglicht die Authentifizierung von Clients über NTLM anstelle von Kerberos. Microsoft rät von der Verwendung von NTLM ab. Weitere Informationen finden Sie unter Sicherheitsüberlegungen für Implementer.
Verwenden Sie wann immer möglich Kerberos anstatt NTLM.
Änderungen am Clustermanifest
In diesem Abschnitt wird davon ausgegangen, dass Sie bereits ein Clustermanifest für die Verwendung von Kerberos zur Clientauthentifizierung und X.509-Zertifikate für die Serverauthentifizierung und Verschlüsselung konfiguriert haben. Weitere Informationen finden Sie unter Schützen eines Clusters mithilfe von Windows-Sicherheit.
Verwenden der REST-APIs mit Kerberos
REST-APIs werden nicht geändert, wenn REST-APIs für die Kommunikation mit einem für Kerberos aktivierten Cluster verwendet werden. Die URLs, HTTP-Header, Anforderungs- und Antworttexte des REST-Aufrufs bleiben unverändert.
Allerdings müssen Sie das Standardverfahren für die Kerberos- und NTLM-HTTP-Authentifizierung befolgen.
Beachten Sie dabei Folgendes:
Die meisten HTTP-Clients folgen automatisch diesem Verfahren.
Wenn bekannt ist, dass der Server mit Kerberos/NTLM gesichert ist, kann mit Schritt 3 im folgenden Prozess begonnen werden. Dadurch wird ein Netzwerkhop entfernt.
Kerberos-Authentifizierungsverfahren mit REST
Im Folgenden finden Sie eine Beispielsequenz eines Kerberos-Authentifizierungsprozesses mit REST.
Rufen Sie eine REST-API ohne zusätzliche HTTP-Header auf:
GET http://localhost:19007/Nodes?api-version=6.0 HTTP/1.1 User-Agent: Fiddler Host: localhost:19007Ein für Kerberos aktivierter Cluster gibt die Antwort "401 – Nicht autorisiert" zurück und legt den www-authenticate-Header auf "Negotiate" fest:
HTTP/1.1 401 Unauthorized Server: Microsoft-HTTPAPI/2.0 WWW-Authenticate: Negotiate Date: Thu, 09 Jan 2014 08:20:55 GMT Content-Length: 0Der Client muss jetzt das Token abrufen, indem er mit dem SPN des Diensts eine Verbindung mit AD (als Verbund oder wechselseitig) herstellt.
Der SPN des Diensts ist HTTP\FQDN des Service Fabric-Knotens, mit dem eine Verbindung hergestellt wird."
Vom AD zurückgegebenes Token sollte im Autorisierungsheader im Format "Negotiate <token>" verwendet werden.
GET http://localhost:19007/Nodes?api-version=6.0 HTTP/1.1 User-Agent: Fiddler Host: localhost:19007 Authorization: Negotiate YH8GBisG<…>CSqGSIb3EgECAgYKKwYBBAGCNwICHqI/BD1OVE<…>RNT05EDer Server authentifiziert das Token, und wenn der Client autorisiert ist, den Vorgang abzuschließen, wird die Ausführung der Anforderung gestartet.
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"}}]