Authentification de demandes REST de structure de service
Un cluster Service Fabric peut être sécurisé à l’aide de certificats X.509, Kerberos ou d’une combinaison de certificats X.509 et Kerberos. Cet article aborde les points suivants :
Comment modifier le manifeste du cluster pour rendre le point de terminaison REST HttpGatewayEndpoints pour se conformer à la solution de sécurité spécifique.
Comment modifier les appels REST pour utiliser chaque solution (X.509, Kerberos, ou X.509 avec Kerberos).
Passerelle HTTP avec sécurité X.509
Sur Azure et localement, les points de terminaison REST de Service Fabric prennent en charge l’utilisation de certificats X.509 pour :
Authentification et autorisation des clients : Service Fabric peut être configuré pour accorder à l’utilisateur un accès, un accès administrateur ou aucun accès à un client REST, en fonction des certificats.
Authentification des nœuds Service Fabric : les clients REST peuvent vérifier qu’ils communiquent avec l’un des nœuds Service Fabric appropriés.
Chiffrement de messages (demandes et réponses REST).
Notes
Les clients disposant d'un accès utilisateur sont autorisés uniquement à effectuer des demandes de lecture (par exemple, https://localhost:19007/Nodes?api-version=6.0). Les clients disposant d'un accès administrateur sont autorisés à effectuer des demandes de lecture et d'écriture (exemple de demande d'écriture, https://localhost:19007/Nodes/<NodeName>/$/Deactivate?api-version=6.0).
Modifications du manifeste du cluster
Cette section suppose que vous avez déjà un manifeste de cluster configuré pour utiliser des certificats X.509. Pour en savoir plus, consultez Sécuriser un cluster à l’aide de certificats X.509.
Pour configurer un cluster afin de prendre en charge l’authentification et l’autorisation des clients (utilisateur et Administration) et l’authentification des nœuds Service Fabric, les paramètres suivants doivent être définis dans le manifeste du cluster :
Empreinte numérique des certificats de serveur et de client pour chaque type de nœud
<ClientCertificate X509FindValue="…" />
<ServerCertificate X509FindValue="…" />
Section Security
<Parameter Name="ClientRoleEnabled" Value="true" />
<Parameter Name="ServerAuthCredentialType" Value="X509" />
ClientAuthAllowedCommonNames parameter
AdminAllowedCommonNames parameter
ServerAuthAllowedCommonNames parameter
Pour activer HttpGateway sur un manifeste de cluster, qui est déjà sécurisé avec X.509 (autrement dit, la sécurité du cluster et du client/serveur sont déjà activées), seules ces modifications sont requises :
Définissez le protocole de tous les éléments HttpGatewayEndpoint sur « https ». Par exemple, <HttpGatewayEndpoint Port="19017 » Protocol="https"/>
Activez HttpGateway dans la section HttpGateway. Par exemple, <Parameter Name="IsEnabled » Value="true"/>
Utilisation d'API REST avec X.509
Pour une requête HTTPS sécurisée X.509, créez l'empreinte numérique des certificats de client (dont le nom commun est spécifié dans ClientAuthAllowedCommonNames ou AdminAllowedCommonNames) et de serveur appropriés.
Pour un point de terminaison HTTP sécurisé X.509, l'API REST ne change pas. Les URL, les en-têtes HTTP, les corps de requête et de réponse de l’appel REST sont inchangés.
Sécurité de la passerelle HTTP avec Kerberos (ou NTLM)
Les clusters Service Fabric locaux peuvent utiliser Kerberos et NTLM pour authentifier et autoriser les clients utilisateur et administrateur, ainsi que pour authentifier les serveurs (nœuds Service Fabric). Toutefois, Kerberos ou NTLM ne permettent pas de chiffrer les messages.
Notes
Il est recommandé d'utiliser HTTPS et de veiller à ce que le manifeste du cluster inclue des certificats de serveur lors de l'utilisation de Kerberos.
Nous recommandons vivement aux clients qui utilisent la sécurité Kerberos d'utiliser également le protocole HTTPS. Cela signifie que le cluster doit disposer de certificats de serveur X.509. De cette façon, les certificats de serveur sont utilisés pour chiffrer les communications.
Le principal avantage de l'utilisation de l'authentification Kerberos au lieu de certificats X.509 pour les clients est que Kerberos simplifie la gestion des certificats de client.
Service Fabric permet aux clients d’être authentifiés via NTLM au lieu de Kerberos. Microsoft ne recommande pas l'utilisation de NTLM. Pour plus d’informations, consultez Considérations relatives à la sécurité pour les implémenteurs.
Autant que possible, utilisez Kerberos plutôt NTLM.
Modifications du manifeste du cluster
Cette section suppose que vous avez déjà un manifeste de cluster configuré pour utiliser Kerberos pour l'authentification du client et des certificats X.509 pour l'authentification et le chiffrement du serveur. Pour en savoir plus, consultez Sécuriser un cluster à l’aide de Sécurité Windows.
Utilisation d'API REST avec Kerberos
Les API REST ne changent pas en cas d'utilisation d'API REST pour communiquer avec un cluster pour lequel Kerberos est activé. Les URL, les en-têtes HTTP, les corps de requête et de réponse de l’appel REST sont inchangés.
Toutefois, vous devez suivre le processus d'authentification HTTP standard de Kerberos et de NTLM.
Notez les points suivants :
La plupart des clients HTTP suivent automatiquement ce processus.
Si le serveur est connu pour être sécurisé avec Kerberos/NTLM, vous pouvez commencer à l’étape 3 du processus suivant. Cela supprimera un tronçon réseau.
REST avec le processus d'authentification Kerberos
Voici un exemple de séquence d’un processus d’authentification Kerberos à l’aide de REST.
Appelez une API REST sans en-tête HTTP supplémentaire :
GET http://localhost:19007/Nodes?api-version=6.0 HTTP/1.1 User-Agent: Fiddler Host: localhost:19007Un cluster pour lequel Kerberos est activé répond avec l'erreur 401 Non autorisé, et définit l'en-tête www-authentifier sur « 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: 0Le client doit obtenir le jeton en contactant son AD (fédéré ou mutuel) avec le nom principal du service (SPN).
Le SPN du service est HTTP\FQDN du nœud Service Fabric contacté. »
Le jeton retourné par AD doit être utilisé dans l’en-tête d’autorisation au format « 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<…>RNT05ELe serveur authentifie le jeton et, si le client est autorisé à effectuer l'opération, il démarre l'exécution de la demande.
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"}}]