Share via

Autenticación de las solicitudes de REST de Service Fabric

  • Artículo

Un clúster de Service Fabric se puede proteger mediante certificados X.509, Kerberos o una combinación de certificados X.509 y Kerberos. En este artículo se describe:

  • Cómo editar el manifiesto de clúster para hacer que HttpGatewayEndpoints (extremo de REST) cumpla con la solución de seguridad específica.

  • Cómo modificar las llamadas de REST para que funcionen con cada solución (X.509, Kerberos o X.509 con Kerberos).

Puerta de enlace de Http con seguridad X.509

En Azure y en el entorno local, los puntos de conexión REST de Service Fabric admiten el uso de certificados X.509 para:

  1. Autenticación y autorización de clientes: Service Fabric se puede configurar para proporcionar acceso de usuario, acceso de administrador o sin acceso a un cliente REST, en función de los certificados.

  2. Autenticación de nodos de Service Fabric: los clientes REST pueden comprobar que se comunican con uno de los nodos correctos de Service Fabric.

  3. Cifrado de mensajes (solicitudes y respuestas de REST).

Nota:

Los clientes con acceso de usuario solo tienen permiso para las solicitudes de lectura (por ejemplo, https://localhost:19007/Nodes?api-version=6.0). Los clientes con acceso de administrador tienen permiso para las solicitudes de lectura y escritura (ejemplo de solicitud de escritura, https://localhost:19007/Nodes/<NodeName>/$/Deactivate?api-version=6.0).

Cambios de manifiesto de clúster

En esta sección se supone que ya tiene un manifiesto de clúster configurado para usar los certificados X.509. Para más información, consulte Protección de un clúster mediante certificados X.509.

Para configurar un clúster para admitir la autenticación y autorización de clientes (usuario y Administración) y la autenticación de nodos de Service Fabric, se deben establecer los parámetros siguientes en el manifiesto del clúster:

  • Huella digital de los certificados de cliente y servidor para cada tipo de nodo

    • <ClientCertificate X509FindValue="…" />

    • <ServerCertificate X509FindValue="…" />

  • Sección de seguridad

    • <Nombre de parámetro="ClientRoleEnabled" Value="true" />

    • <Nombre de parámetro="ServerAuthCredentialType" Value="X509" />

    • Parámetro ClientAuthAllowedCommonNames

    • Parámetro AdminAllowedCommonNames

    • Parámetro ServerAuthAllowedCommonNames

Para habilitar HttpGateway en un manifiesto de clúster, que ya está protegido con X.509 (es decir, la seguridad de cliente o servidor ya está habilitada), solo se requieren estos cambios:

  • Establecer el protocolo de todos los elementos de HttpGatewayEndpoint en "https". Por ejemplo, <HttpGatewayEndpoint Port="19017" Protocol="https"/>

  • Habilite HttpGateway en la sección HttpGateway. Por ejemplo, <Parameter Name="IsEnabled" Value="true"/>

Uso de las API de REST con X.509

Para una solicitud HTTPS protegida con X.509, cree el certificado de cliente pertinente (cuyo nombre común se especifica en ClientAuthAllowedCommonNames o AdminAllowedCommonNames) y la huella digital de certificado de servidor.

Para un extremo HTTP protegido con X.509, las API de REST no cambian. Las direcciones URL, los encabezados HTTP, la solicitud y los cuerpos de respuesta de la llamada REST no se modificarán.

Seguridad de la puerta de enlace de Http con Kerberos (o NTLM)

En el entorno local, los clústeres de Service Fabric pueden usar Kerberos y NTLM para autenticar y autorizar a los clientes de usuario y administrador, así como autenticar servidores (nodos de Service Fabric). Sin embargo, Kerberos o NTLM no pueden utilizarse para cifrar los mensajes.

Nota:

Se recomienda usar HTTPS y asegurarse de que el manifiesto de clúster incluye los certificados de servidor cuando se utiliza Kerberos.

Recomendamos encarecidamente que los clientes que utilizan la seguridad de Kerberos utilicen también HTTPS. Esto significa que el clúster debe tener los certificados de servidor X.509. De este modo, los certificados de servidor se utilizarán para cifrar la comunicación.

La principal ventaja de utilizar la autenticación Kerberos en lugar de certificados X.509 para clientes es que Kerberos simplifica la administración de certificados de cliente.

Service Fabric permite que los clientes se autentiquen mediante NTLM en lugar de Kerberos. Microsoft no recomienda el uso de NTLM. Para obtener más información, consulte Consideraciones de seguridad para los implementadores.

Use Kerberos en lugar de NTLM siempre que sea posible.

Cambios de manifiesto de clúster

En esta sección se supone que ya tiene un manifiesto de clúster configurado para utilizar Kerberos para la autenticación de cliente y los certificados X.509 para el cifrado y autenticación de servidor. Para más información, consulte Protección de un clúster mediante Seguridad de Windows.

Uso de las API de REST con Kerberos

Las API de REST no cambian al utilizar las API de REST para comunicarse con un clúster con Kerberos habilitado. Las direcciones URL, los encabezados HTTP, la solicitud y los cuerpos de respuesta de la llamada REST no se modificarán.

Sin embargo, deberá seguir el proceso estándar de autenticación de Kerberos y HTTP de NTLM.

Observe lo siguiente:

  • la mayoría de los clientes HTTP siguen automáticamente este proceso.

  • Si se sabe que el servidor está protegido con Kerberos/NTLM, puede empezar en el paso 3 del proceso siguiente. Esto quitará un salto de red.

REST con el proceso de autenticación Kerberos

A continuación se muestra una secuencia de ejemplo de un proceso de autenticación Kerberos mediante REST.

  1. Llame a una API de REST sin los encabezados HTTP adicionales:

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

  2. Un clúster con Kerberos habilitado permite responder con 401 Unauthorized y establecer el encabezado www-authenticate en "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. El cliente ahora necesita obtener el token poniendo en contacto su AD (federado o mutuo) con el SPN del servicio.

    El SPN del servicio es HTTP\FQDN del nodo de Service Fabric al que se está contactando".

  4. El token devuelto por AD debe usarse en el encabezado de autorización con el formato "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<…>RNT05E

  5. El servidor autenticará el token y, si el cliente está autorizado para completar la operación, se iniciará la ejecución de la solicitud.

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