Compartilhar via


Autenticando solicitações REST do serviço de Malha do Serviço

Um cluster do Service Fabric pode ser protegido usando certificados X.509, Kerberos ou uma combinação de certificados X.509 e Kerberos. Este artigo descreve:

  • Como editar o manifesto do cluster para fazer o HttpGatewayEndpoints (ponto de extremidade REST) aderir à solução de segurança específica.

  • Como modificar as chamadas REST para trabalhar com cada solução (X.509, Kerberos ou X.509 com Kerberos).

Gateway de HTTP com segurança X.509

No Azure e no local, os pontos de extremidade REST do Service Fabric dão suporte ao uso de certificados X.509 para:

  1. Autenticação e autorização de clientes: o Service Fabric pode ser configurado para dar acesso ao usuário, acesso de administrador ou nenhum acesso a um cliente REST, dependendo dos certificados.

  2. Autenticação de nós do Service Fabric: os clientes REST podem verificar se estão se comunicando com um dos nós corretos do Service Fabric.

  3. Criptografia de mensagens (solicitações e respostas REST).

Observação

Os clientes com acesso de usuário só têm permissão para solicitações de leitura (por exemplo, https://localhost:19007/Nodes?api-version=6.0). Os clientes com acesso de administrador têm permissão para solicitações de leitura e gravação de solicitações (exemplo de solicitação de gravação, https://localhost:19007/Nodes/<NodeName>/$/Deactivate?api-version=6.0).

Alterações do manifesto do cluster

Esta seção pressupõe que você já tenha um manifesto do cluster configurado para usar certificados X.509. Para saber mais, leia Proteger um cluster usando certificados X.509.

Para configurar um cluster para dar suporte à autenticação e autorização de clientes (usuário e Administração) e autenticação de nós do Service Fabric, os seguintes parâmetros devem ser definidos no manifesto do cluster:

  • Impressão digital de certificados de cliente e servidor para cada tipo de nó

    • <ClientCertificate X509FindValue="…" />

    • <ServerCertificate X509FindValue="…" />

  • Seção de segurança

    • <Nome do parâmetro="ClientRoleEnabled" Value = "true" />

    • <Nome do parâmetro="ServerAuthCredentialType" Value = "X509" />

    • Parâmetro ClientAuthAllowedCommonNames

    • Parâmetro ClientAuthAllowedCommonNames

    • Parâmetro ServerAuthAllowedCommonNames

Para habilitar o HttpGateway em um manifesto de cluster, que já está protegido com X.509 (ou seja, a segurança de cluster e cliente/servidor já está habilitada), somente essas alterações são necessárias:

  • Definir o protocolo de todos os elementos HttpGatewayEndpoint para "https". Por exemplo, <HttpGatewayEndpoint Port="19017" Protocol="https"/>

  • Habilitar HttpGateway na seção HttpGateway. Por exemplo, <Parameter Name="IsEnabled" Value="true"/>

Como usar APIs REST com X.509

Para uma solicitação HTTPS protegida por X.509, crie o certificado do cliente relevante (cujo nome comum é especificado no ClientAuthAllowedCommonNames ou AdminAllowedCommonNames) e a impressão digital do certificado do servidor.

Para um ponto de extremidade HTTP protegido por X.509, as APIs REST não são alteradas. As URLs, os cabeçalhos HTTP, a solicitação e os corpos de resposta da chamada REST não serão alterados.

Segurança do gateway de HTTP com Kerberos (ou NTLM)

No local, os clusters do Service Fabric podem usar Kerberos e NTLM para autenticar e autorizar o usuário e os clientes administradores, bem como autenticar servidores (nós do Service Fabric). No entanto, o Kerberos ou NTLM não pode ser usado para criptografar as mensagens.

Observação

É recomendável usar HTTPS e garantir que o manifesto do cluster inclua certificados de servidor ao usar o Kerberos.

É altamente recomendável que os clientes que usam segurança Kerberos também usem HTTPS. Isso significa que o cluster precisa ter certificados de servidor X.509. Dessa forma, os certificados de servidor serão usados para criptografar a comunicação.

A principal vantagem de usar a autenticação Kerberos em vez de certificados X.509 para os clientes é que o Kerberos simplifica o gerenciamento de certificados do cliente.

O Service Fabric permite que os clientes sejam autenticados por meio de NTLM em vez de Kerberos. A Microsoft não recomenda o uso do NTLM. Para obter mais informações, consulte Considerações de segurança para implementadores.

Use Kerberos em vez de NTLM, sempre que possível.

Alterações do manifesto do cluster

Esta seção pressupõe que você já tenha um manifesto do cluster configurado para usar o Kerberos para autenticação do cliente e certificados X.509 para autenticação de servidor e criptografia. Para saber mais, leia Proteger um cluster usando Segurança do Windows.

Como usar as APIs REST com o Kerberos

As APIs REST não são alteradas ao usar as APIs REST para se comunicar com um cluster habilitado para o Kerberos. As URLs, os cabeçalhos HTTP, a solicitação e os corpos de resposta da chamada REST não serão alterados.

No entanto, você precisa seguir o processo de autenticação HTTP Kerberos e NTLM padrão.

Observe que:

  • A maioria dos clientes HTTP seguem automaticamente este processo.

  • Se o servidor é conhecido por ser protegido com Kerberos/NTLM, pode-se começar na etapa 3 no processo a seguir. Isso remove um salto de rede.

REST com processo de autenticação Kerberos

Veja a seguir um exemplo de sequência de um processo de autenticação Kerberos usando REST.

  1. Chame uma API REST sem nenhum cabeçalho HTTP adicional:

    GET http://localhost:19007/Nodes?api-version=6.0 HTTP/1.1  
    User-Agent: Fiddler  
    Host: localhost:19007  
    
    
  2. Um cluster habilitado pelo Kerberos responde com 401 Não Autorizado e define o cabeçalho www-authenticate como "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. Agora, o cliente precisa obter o Token entrando em contato com o AD (mútuo ou federado) com o SPN do serviço.

    O SPN do serviço é HTTP\FQDN do nó do Service Fabric que está sendo contatado".

  4. O token retornado pelo AD deve ser usado no Cabeçalho de Autorização com o formato "Negociar <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. O servidor autentica o token e se o cliente estiver autorizado a concluir a operação, ele inicia a execução da solicitação.

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