Condividi tramite

Autenticazione delle richieste REST dell'infrastruttura di servizi

  • Articolo

Un cluster di Service Fabric può essere protetto usando certificati X.509, Kerberos o una combinazione di certificati X.509 e Kerberos. L'articolo illustra:

  • Come modificare il manifesto del cluster in modo che HttpGatewayEndpoints (endpoint REST) rispetti la soluzione di sicurezza specifica.

  • Come modificare le chiamate REST in modo che funzionino con ogni soluzione (X.509, Kerberos o X.509 con Kerberos).

Gateway HTTP con sicurezza X.509

In Azure e in locale, gli endpoint REST del supporto di Service Fabric usano certificati X.509 per:

  1. Autenticazione e autorizzazione dei client: Service Fabric può essere configurato per concedere l'accesso utente, l'accesso amministratore o nessun accesso a un client REST, a seconda dei certificati.

  2. Autenticazione dei nodi di Service Fabric: i client REST possono verificare che comunichino con uno dei nodi di Service Fabric corretti.

  3. Crittografia dei messaggi (richieste e risposte REST).

Nota

I client con accesso utente dispongono solo dell'autorizzazione per le richieste di lettura (ad esempio https://localhost:19007/Nodes?api-version=6.0). I client con accesso amministratore dispongono dell'autorizzazione per le richieste di lettura e di scrittura (esempio di richiesta di scrittura, https://localhost:19007/Nodes/<NodeName>/$/Deactivate?api-version=6.0).

Modifiche al manifesto del cluster

Questa sezione presuppone che si disponga già di un manifesto del cluster configurato per usare certificati X.509. Per altre informazioni, vedere Proteggere un cluster con certificati X.509.

Per configurare un cluster per supportare l'autenticazione e l'autorizzazione dei client (Utente e Amministrazione) e l'autenticazione dei nodi di Service Fabric, i parametri seguenti devono essere impostati nel manifesto del cluster:

  • Identificazione dei certificati server e client per ogni tipo di nodo

    • <ClientCertificate X509FindValue="…" />

    • <ServerCertificate X509FindValue="…" />

  • Sezione relativa alla sicurezza

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

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

    • Parametro ClientAuthAllowedCommonNames

    • Parametro AdminAllowedCommonNames

    • Parametro ServerAuthAllowedCommonNames

Per abilitare HttpGateway in un manifesto del cluster, che è già protetto con X.509 (ovvero la sicurezza del cluster e del client/server è già abilitata), sono necessarie solo queste modifiche:

  • Impostare il protocollo per tutti gli elementi HttpGatewayEndpoint su "https". Ad esempio, <HttpGatewayEndpoint Port="19017" Protocol="https"/>

  • Abilitare HttpGateway nella sezione HttpGateway. Ad esempio, <Parameter Name="IsEnabled" Value="true"/>

Come usare le API REST con X.509

Per una richiesta HTTPS protetta con X.509, creare il certificato client pertinente (il cui nome comune è specificato in ClientAuthAllowedCommonNames o AdminAllowedCommonNames) e l'identificazione del certificato server.

Per un endpoint HTTP protetto con X.509, le API REST non cambiano. Gli URL, le intestazioni HTTP, le richieste e i corpi di risposta della chiamata REST saranno invariati.

Gateway HTTP con sicurezza Kerberos (o NTLM)

In locale, i cluster di Service Fabric possono usare Kerberos e NTLM per autenticare e autorizzare i client utente e amministratore, nonché l'autenticazione dei server (nodi di Service Fabric). Non è tuttavia possibile usare Kerberos o NTLM per crittografare i messaggi.

Nota

È consigliabile usare HTTPS e verificare che il manifesto del cluster includa i certificati server quando si usa Kerberos.

I clienti che usano la sicurezza Kerberos dovrebbero usare anche HTTPS. Ciò significa che il cluster deve disporre di certificati server X.509. I certificati server verranno così usati per crittografare le comunicazioni.

Il principale vantaggio dell'uso dell'autenticazione Kerberos al posto dei certificati X.509 per i client consiste nel fatto che Kerberos semplifica la gestione dei certificati client.

Service Fabric consente l'autenticazione dei client tramite NTLM anziché Kerberos. Microsoft non consiglia l'uso di NTLM. Per altre informazioni, vedere Considerazioni sulla sicurezza per gli implementatori.

Quando possibile, usare Kerberos al posto di NTLM.

Modifiche al manifesto del cluster

Questa sezione presuppone che si disponga già di un manifesto del cluster configurato per usare Kerberos per l'autenticazione client e i certificati X.509 per l'autenticazione server e la crittografia. Per altre informazioni, vedere Proteggere un cluster tramite Sicurezza di Windows.

Come usare le API REST con Kerberos

Le API REST non cambiano quando vengono usate per comunicare con un cluster abilitato per Kerberos. Gli URL, le intestazioni HTTP, le richieste e i corpi di risposta della chiamata REST saranno invariati.

È necessario tuttavia seguire il processo di autenticazione HTTP NTLM e Kerberos standard.

Tenere presente quanto segue:

  • La maggior parte dei client HTTP segue automaticamente questo processo.

  • Se il server è noto per essere protetto con Kerberos/NTLM, è possibile iniziare al passaggio 3 del processo seguente. Verrà rimosso un hop di rete.

Processo di autenticazione Kerberos con REST

Di seguito è riportata una sequenza di esempio di un processo di autenticazione Kerberos tramite REST.

  1. Chiamare un'API REST senza intestazioni HTTP aggiuntive:

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

  2. Un cluster abilitato per Kerberos risponderà con un messaggio 401 - Non autorizzato e imposterà l'intestazione www-authenticate su "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. Il client deve ora ottenere il token contattando Active Directory (con accesso federato o reciproco) con il nome SPN del servizio.

    Il nome SPN del servizio è HTTP\FQDN del nodo di Service Fabric contattato".

  4. Il token restituito da AD deve essere usato nell'intestazione dell'autorizzazione con il 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. Il server autenticherà il token e, se il client è autorizzato a completare l'operazione, verrà avviata l'esecuzione della richiesta.

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