Partilhar via

Autenticar Pedidos REST do Service Fabric

  • Artigo

Um cluster do Service Fabric pode ser protegido com 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 com que os HttpGatewayEndpoints (ponto final REST) cumpram a 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 Http com Segurança X.509

No Azure e no local, os pontos finais REST do Service Fabric suportam a utilização de certificados X.509 para:

  1. Autenticação e autorização de clientes: o Service Fabric pode ser configurado para conceder acesso de utilizador, acesso de administrador ou sem acesso a um cliente REST, consoante os certificados.

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

  3. Encriptação de mensagens (pedidos REST e respostas).

Nota

Os clientes com acesso de utilizador só têm permissão para pedidos de leitura (por exemplo, https://localhost:19007/Nodes?api-version=6.0). Os clientes com acesso de administrador têm permissão para pedidos de leitura e pedidos de escrita (exemplo de pedido de escrita, https://localhost:19007/Nodes/<NodeName>/$/Deactivate?api-version=6.0).

Alterações ao Manifesto do Cluster

Esta secção pressupõe que já tem um manifesto de cluster configurado para utilizar certificados X.509. Para saber mais, leia Proteger um Cluster Com Certificados X.509.

Para configurar um cluster para suportar a autenticação e autorização de clientes (Utilizador e Administração) e autenticação de nós do Service Fabric, os seguintes parâmetros têm de ser definidos no manifesto do cluster:

  • Thumbprint de certificados de servidor e cliente para cada tipo de nó

    • <ClientCertificate X509FindValue="..." />

    • <ServerCertificate X509FindValue="..." />

  • Secção Segurança

    • <Parameter Name="ClientRoleEnabled" Value="true" />

    • <Parameter Name="ServerAuthCredentialType" Value="X509" />

    • Parâmetro ClientAuthAllowedCommonNames

    • Parâmetro AdminAllowedCommonNames

    • Parâmetro ServerAuthAllowedCommonNames

Para ativar o HttpGateway num manifesto de cluster, que já está protegido com X.509 (ou seja, a segurança do cluster e do cliente/servidor já estão ativadas), apenas estas alterações são necessárias:

  • Defina Protocolo de todos os elementos HttpGatewayEndpoint como "https". Por exemplo, <HttpGatewayEndpoint Port="19017" Protocol="https"/>

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

Como Utilizar APIs REST com X.509

Para um Pedido HTTPS protegido por X.509, crie o certificado de cliente relevante (cujo nome comum é especificado em ClientAuthAllowedCommonNames ou AdminAllowedCommonNames) e o thumbprint do certificado de servidor.

Para um ponto final HTTP protegido por X.509, as APIs REST não são alteradas. Os URLs, Cabeçalhos HTTP, Pedido e Corpos de Resposta da chamada REST não serão alterados.

Gateway http com Segurança Kerberos (ou NTLM)

No local, os clusters do Service Fabric podem utilizar o Kerberos e o NTLM para autenticar e autorizar os clientes de utilizador e administrador, bem como a autenticação de servidores (nós do Service Fabric). No entanto, o Kerberos ou o NTLM não podem ser utilizados para encriptar as mensagens.

Nota

É recomendado utilizar HTTPS e garantir que o manifesto do cluster inclui certificados de servidor ao utilizar o Kerberos.

Recomendamos vivamente que os clientes que utilizam a segurança Kerberos também utilizem HTTPS. Isto significa que o cluster precisa de ter certificados de servidor X.509. Desta forma, os certificados de servidor serão utilizados para encriptar a comunicação.

A principal vantagem de utilizar a autenticação Kerberos em vez de certificados X.509 para clientes é que o Kerberos simplifica a gestão de certificados de cliente.

O Service Fabric permite que os clientes sejam autenticados através do NTLM em vez do Kerberos. A Microsoft não recomenda a utilização do NTLM. Para obter mais informações, veja Considerações de Segurança para Implementadores.

Utilize Kerberos em vez de NTLM sempre que possível.

Alterações ao Manifesto do Cluster

Esta secção pressupõe que já tem um manifesto de cluster configurado para utilizar o Kerberos para autenticação de cliente e certificados X.509 para autenticação e encriptação de servidor. Para saber mais, leia Proteger um Cluster Com Segurança do Windows.

Como Utilizar as APIs REST com o Kerberos

As APIs REST não são alteradas ao utilizar APIs REST para comunicar com um cluster ativado por Kerberos. Os URLs, Cabeçalhos HTTP, Pedido e Corpos de Resposta da chamada REST não serão alterados.

No entanto, terá de seguir o processo padrão de Autenticação Kerberos e NTLM HTTP.

Tenha em atenção que:

  • A maioria dos clientes HTTP segue automaticamente este processo.

  • Se o servidor estiver protegido com Kerberos/NTLM, pode iniciar-se no passo 3 no processo seguinte. Esta ação irá remover um salto de rede.

REST com Processo de Autenticação Kerberos

Segue-se uma sequência de exemplo de um processo de autenticação Kerberos com REST.

  1. Chamar uma API REST sem cabeçalhos HTTP adicionais:

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

  2. Um kerberos ativa o cluster responderá com 401 Não Autorizado e definirá o cabeçalho www-authenticate como "Negociar":

    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. O cliente precisa agora de obter o Token ao contactar o respetivo AD (federado ou mútuo) com o SPN do serviço.

    O SPN do serviço é HTTP\FQDN do nó do Service Fabric que está a ser contactado".

  4. O token devolvido pelo AD deve ser utilizado 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 autenticará o token e, se o cliente estiver autorizado a concluir a operação, começará a executar o pedido.

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