Service Fabric REST-aanvragen verifiëren
Een Service Fabric-cluster kan worden beveiligd met X.509-certificaten, Kerberos of een combinatie van X.509-certificaten en Kerberos. In dit artikel wordt het volgende beschreven:
Het clustermanifest bewerken om ervoor te zorgen dat het HttpGatewayEndpoints (REST-eindpunt) voldoet aan de specifieke beveiligingsoplossing.
De REST-aanroepen wijzigen om met elke oplossing te werken (X.509, Kerberos of X.509 met Kerberos).
HTTP-gateway met X.509-beveiliging
Op Azure en on-premises ondersteunen REST-eindpunten van Service Fabric X.509-certificaten voor:
Verificatie en autorisatie van clients: Service Fabric kan worden geconfigureerd om gebruikerstoegang, beheerderstoegang of geen toegang te verlenen tot een REST-client, afhankelijk van de certificaten.
Verificatie van Service Fabric-knooppunten: REST-clients kunnen controleren of ze communiceren met een van de juiste Service Fabric-knooppunten.
Versleuteling van berichten (REST-aanvragen en -antwoorden).
Notitie
Clients met gebruikerstoegang hebben alleen machtigingen voor leesaanvragen (bijvoorbeeld https://localhost:19007/Nodes?api-version=6.0). Clients met beheerderstoegang hebben machtigingen voor lees- en schrijfaanvragen (voorbeeld van schrijfaanvraag, https://localhost:19007/Nodes/<NodeName>/$/Deactivate?api-version=6.0).
Wijzigingen in clustermanifest
In deze sectie wordt ervan uitgegaan dat u al een clustermanifest hebt geconfigureerd voor het gebruik van X.509-certificaten. Lees Een cluster beveiligen met X.509-certificaten voor meer informatie.
Als u een cluster wilt configureren ter ondersteuning van verificatie en autorisatie van clients (gebruiker en Beheer) en verificatie van Service Fabric-knooppunten, moeten de volgende parameters worden ingesteld in het clustermanifest:
Vingerafdruk van server- en clientcertificaten voor elk knooppunttype
<ClientCertificate X509FindValue="..." />
<ServerCertificate X509FindValue="..." />
Sectie Beveiliging
<Parameter name="ClientRoleEnabled" Value="true" />
<Parameter Name="ServerAuthCredentialType" Value="X509" />
Parameter ClientAuthAllowedCommonNames
Parameter AdminAllowedCommonNames
Parameter ServerAuthAllowedCommonNames
Als u HttpGateway wilt inschakelen op een clustermanifest, dat al is beveiligd met X.509 (dat wil gezegd dat cluster- en client-/serverbeveiliging al zijn ingeschakeld), zijn alleen deze wijzigingen vereist:
Stel Protocol van alle HttpGatewayEndpoint-elementen in op 'https'. Bijvoorbeeld <HttpGatewayEndpoint Port="19017" Protocol="https"/>
Schakel HttpGateway in de sectie HttpGateway in. Bijvoorbeeld <: Parameter name="IsEnabled" Value="true"/>
REST API's gebruiken met X.509
Voor een met X.509 beveiligde HTTPS-aanvraag maakt u het relevante clientcertificaat (waarvan de algemene naam is opgegeven in ClientAuthAllowedCommonNames of AdminAllowedCommonNames) en de vingerafdruk van het servercertificaat.
Voor een met X.509 beveiligd HTTP-eindpunt worden de REST API's niet gewijzigd. De URL's, HTTP-headers, aanvraag en antwoordteksten van de REST-aanroep blijven ongewijzigd.
HTTP-gateway met Kerberos-beveiliging (of NTLM)-beveiliging
On-premises Service Fabric-clusters kunnen Kerberos en NTLM gebruiken om de gebruikers- en beheerclients te verifiëren en te autoriseren, en om servers (Service Fabric-knooppunten) te verifiëren. Kerberos of NTLM kan echter niet worden gebruikt om de berichten te versleutelen.
Notitie
Het wordt aanbevolen om HTTPS te gebruiken en ervoor te zorgen dat het clustermanifest servercertificaten bevat wanneer u Kerberos gebruikt.
We raden klanten die kerberos-beveiliging gebruiken ten zeerste aan om ook HTTPS te gebruiken. Dit betekent dat het cluster X.509-servercertificaten moet hebben. Op deze manier worden de servercertificaten gebruikt om de communicatie te versleutelen.
Het belangrijkste voordeel van het gebruik van Kerberos-verificatie in plaats van X.509-certificaten voor clients is dat Kerberos het beheer van clientcertificaten vereenvoudigt.
Met Service Fabric kunnen clients worden geverifieerd via NTLM in plaats van Kerberos. Microsoft raadt het gebruik van NTLM niet aan. Zie Beveiligingsoverwegingen voor implementers voor meer informatie.
Gebruik waar mogelijk Kerberos in plaats van NTLM.
Wijzigingen in clustermanifest
In deze sectie wordt ervan uitgegaan dat u al een clustermanifest hebt geconfigureerd voor het gebruik van Kerberos voor clientverificatie en X.509-certificaten voor serververificatie en versleuteling. Lees Een cluster beveiligen met behulp van Windows-beveiliging voor meer informatie.
De REST API's gebruiken met Kerberos
REST API's veranderen niet wanneer u REST API's gebruikt om te communiceren met een cluster met Kerberos. De URL's, HTTP-headers, aanvraag en antwoordteksten van de REST-aanroep blijven ongewijzigd.
U moet echter het standaard Http-verificatieproces voor Kerberos en NTLM volgen.
Opmerking:
De meeste HTTP-clients volgen dit proces automatisch.
Als bekend is dat de server is beveiligd met Kerberos/NTLM, kunt u beginnen bij stap 3 in het volgende proces. Hiermee wordt één netwerkhop verwijderd.
REST met Kerberos-verificatieproces
Hier volgt een voorbeeldreeks van een Kerberos-verificatieproces met behulp van REST.
Een REST API aanroepen zonder extra HTTP-headers:
GET http://localhost:19007/Nodes?api-version=6.0 HTTP/1.1 User-Agent: Fiddler Host: localhost:19007Een Kerberos-cluster dat is ingeschakeld, antwoordt met 401 Niet geautoriseerd en stelt de header www-authenticate in op 'Onderhandelen':
HTTP/1.1 401 Unauthorized Server: Microsoft-HTTPAPI/2.0 WWW-Authenticate: Negotiate Date: Thu, 09 Jan 2014 08:20:55 GMT Content-Length: 0De client moet nu het token ophalen door contact op te maken met de BIJBEHORENDE AD (federatief of wederzijds) met de SPN van de service.
De SPN van de service is HTTP\FQDN van het Service Fabric-knooppunt dat wordt gecontacteerd'.
Token dat door de AD wordt geretourneerd, moet worden gebruikt in de autorisatieheader met de indeling '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<…>RNT05EServer verifieert het token en als de client is gemachtigd om de bewerking te voltooien, wordt de aanvraag uitgevoerd.
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"}}]