Protezione di WCF Data Services

In questo argomento vengono illustrate alcune considerazioni sulla sicurezza che riguardano in modo particolare lo sviluppo, la distribuzione e l'esecuzione di WCF Data Services e di applicazioni che accedono ai servizi che supportano OData (Open Data Protocol) . È consigliabile inoltre seguire le raccomandazioni relative alla creazione di applicazioni .NET Framework protette.

Quando si pianifica come proteggere un servizio OData basato su WCF Data Services , è necessario considerare l'autenticazione (il processo che consente di individuare e verificare l'identità di un'entità) e l'autorizzazione (il processo che consente di determinare se un'entità autenticata dispone dell'accesso alle risorse richieste). È necessario considerare anche se crittografare il messaggio tramite SSL.

Autenticazione di richieste del client

WCF Data Services non implementa alcun tipo di autenticazione propria, piuttosto si basa sul provisioning di autenticazione dell'host del servizio dati. Ciò vuole dire che il servizio presuppone che qualsiasi richiesta che riceve sia già stata autenticata dall'host di rete e che l'host abbia identificato correttamente il principio della richiesta tramite le interfacce fornite da WCF Data Services . Le opzioni di autenticazione e gli approcci sono illustrati in Serie di autenticazione e OData.

Opzioni di autenticazione per un servizio dati WCF

Nella tabella seguente vengono elencati alcuni dei meccanismi di autenticazione che sono disponibili per facilitare l'autenticazione delle richieste a un servizio dati WCF.

Opzioni di autenticazione	Descrizione
Autenticazione anonima	Quando l'autenticazione anonima HTTP è abilitata, qualsiasi principio è in grado di connettersi al servizio dati. Le credenziali non sono richieste per l'accesso anonimo. Utilizzare questa opzione solo quando si desidera consentire a chiunque l'accesso al servizio dati.
Autenticazione di base e digest	Le credenziali composte da un nome utente e da una password sono richieste per l'autenticazione. Supporta l'autenticazione di client non Windows. Sicurezza - Nota: Le credenziali di autenticazione di base (nome utente e password) vengono inviate in chiaro e possono essere intercettate. L'autenticazione digest invia un hash basato sulle credenziali fornite che la rende più sicura dell'autenticazione di base. Entrambe le autenticazioni sono vulnerabili agli attacchi man-in-the-middle. Quando si utilizzano questi metodi di autenticazione, è necessario considerare di crittografare le comunicazione fra il client e il servizio dati tramite Secure Sockets Layer (SSL). Microsoft Internet Information Services (IIS) fornisce un'implementazione dell'autenticazione digest e di base per le richieste HTTP in un'applicazione ASP.NET. Questa implementazione del provider di Autenticazione di Windows consente a un'applicazione client .NET Framework di fornire le credenziali nell'intestazione HTTP della richiesta al servizio dati per negoziare con facilità l'autenticazione di un utente Windows. Per ulteriori informazioni, vedere Riferimenti tecnici per l'autenticazione digest. Quando si desidera che il servizio dati utilizzi l'autenticazione di base secondo un servizio di autenticazione personalizzato e non con le credenziali di Windows, è necessario implementare un modulo HTTP ASP.NET personalizzato per l'autenticazione. Per un esempio su come utilizzare uno schema di autenticazione di base personalizzato con WCF Data Services , vedere l'argomento Autenticazione di base personalizzata in OData e le serie di autenticazione.
Autenticazione di Windows	Le credenziali basate su Windows vengono scambiate tramite NTLM o Kerberos. Questo meccanismo è più sicuro rispetto all'autenticazione di base o digest, ma richiede che il client sia un'applicazione basata su Windows. IIS fornisce anche un'implementazione dell'autenticazione di Windows per le richieste HTTP in un'applicazione ASP.NET. Per ulteriori informazioni, vedere ASP.NET Forms Authentication Overview. Per un esempio su come utilizzare l'autenticazione di Windows con WCF Data Services , vedere l'argomento Autenticazione di Windows in OData e le serie di autenticazione.
Autenticazione basata su form ASP.NET	L'autenticazione basata su form consente di autenticare gli utenti mediante un codice personalizzato e di gestire un token di autenticazione in un cookie o nell'URL di pagina. Viene eseguita l'autenticazione del nome utente e della password degli utenti utilizzando un form di accesso creato dall'utente. Le richieste non autenticate vengono reindirizzate a una pagina di accesso, dove l'utente fornisce le credenziali e invia il form. Se l'applicazione autentica la richiesta, il sistema elabora un ticket contenente una chiave per la ridefinizione dell'identità per le richieste successive. Per ulteriori informazioni, vedere Forms Authentication Provider. Sicurezza - Nota: Per impostazione predefinita, il cookie contenente il ticket dell'autenticazione basata su form non è protetto quando si utilizza l'autenticazione basata su form in un'applicazione Web ASP.NET. È opportuno richiedere SSL per proteggere il ticket di autenticazione e le credenziali di accesso iniziale. Per un esempio su come utilizzare l'autenticazione basata su form con WCF Data Services , vedere l'argomento Autenticazione basata su form in OData e le serie di autenticazione.
Autenticazione basata sulle attestazioni	Nell'autenticazione basata sulle attestazioni, il servizio dati utilizza un servizio del provider di identità di "terze parti" attendibile per autenticare l'utente. Il provider di identità autentica positivamente l'utente che sta richiedendo l'accesso alle risorse del servizio dati e rilascia un token che concede l'accesso alle risorse richieste. Questo token viene quindi presentato al servizio dati che concede l'accesso all'utente in base alla relazione di trust con il servizio di identità che ha rilasciato il token di accesso. Il provider di autenticazione basato sulle attestazioni risulta conveniente perché può essere utilizzato per autenticare vari tipi di client tra i vari domini trust. Utilizzando un provider di terze parti di questo tipo, il servizio dati può scaricare i requisiti di gestione e autenticazione degli utenti. OAuth 2.0 è un protocollo di autenticazione basato sulle attestazioni supportato dal Controllo di accesso AppFabric di Windows Azure per l'autorizzazione federata come servizio. Questo protocollo supporta i servizi basati su REST. Per un esempio su come utilizzare OAuth 2.0 con WCF Data Services , vedere l'argomento OData e OAuth in OData e le serie di autenticazione.

Autenticazione nella libreria client

Per impostazione predefinita, la libreria client WCF Data Services non fornisce le credenziali quando viene eseguita una richiesta a un servizio OData . Quando le credenziali di accesso sono richieste dal servizio dati per autenticare un utente, è possibile fornire queste credenziali in un elemento NetworkCredential a cui accede la proprietà Credentials di DataServiceContext, come nell'esempio seguente:

' Set the client authentication credentials.
context.Credentials = _
    New NetworkCredential(userName, password, domain)

// Set the client authentication credentials.
context.Credentials =
    new NetworkCredential(userName, password, domain);

Per ulteriori informazioni, vedere Procedura: specificare le credenziali del client per una richiesta del servizio dati (WCF Data Services).

Quando il servizio dati richiede credenziali di accesso che non possono essere specificate tramite un oggetto NetworkCredential, ad esempio un cookie o un token basato sulle attestazioni, è necessario impostare manualmente le intestazioni nella richiesta HTTP, generalmente le intestazioni Authorization e Cookie. Per ulteriori informazioni su questo tipo di scenario di autenticazione, vedere l'argomento OData e autenticazione: hook lato client. Per un esempio su come impostare le intestazioni HTTP in un messaggio di richiesta, vedere Procedura: impostare le intestazioni nella richiesta del client (WCF Data Services).

Rappresentazione

Generalmente il servizio dati accede alle risorse richieste, ad esempio i file sul server o un database, tramite le credenziali del processo di lavoro che ospita il servizio dati. Quando si utilizza la rappresentazione, è possibile eseguire le applicazioni ASP.NET con l'identità Windows (account utente) dell'utente che effettua la richiesta. La rappresentazione è di uso comune in applicazioni che si basano su IIS per autenticare l'utente e le credenziali di questo principio sono utilizzate per accedere alle risorse richieste. Per ulteriori informazioni, vedere ASP.NET Impersonation.

Configurazione dell'autorizzazione del servizio dati

L'autorizzazione è il conferimento dell'accesso alle risorse dell'applicazione concesso a un principio o un processo identificato in base a un'autenticazione precedentemente riuscita. Come regola generale, è opportuno concedere agli utenti del servizio dati solo i diritti sufficienti per eseguire le operazioni richieste dalle applicazioni client.

Restrizione dell'accesso alle risorse del servizio dati

Per impostazione predefinita, WCF Data Services concede l'accesso in lettura e scrittura comune alle risorse del servizio dati (set di entità e operazioni del servizio) a qualsiasi utente in grado di accedere al servizio dati. Le regole che definiscono l'accesso in lettura e scrittura possono essere specificate separatamente per ogni set di entità esposto dal servizio dati così come per qualsiasi operazione del servizio. Si consiglia di limitare l'accesso in lettura e scrittura solo alle risorse richieste dall'applicazione client. Per ulteriori informazioni, vedere Configuring the Data Service (WCF Data Services).

Intercettori basati sulla regola di implementazione

Gli intercettori consentono di intercettare le richieste delle risorse del servizio dati prima che vengano elaborate dal servizio dati. Per ulteriori informazioni, vedere Intercettori (WCF Data Services). Gli intercettori consentono di concedere l'autorizzazione in base all'utente autenticato che effettua la richiesta. Per un esempio su come limitare l'accesso alle risorse del servizio dati in base all'identità di un utente autenticato, vedere Procedura: intercettare messaggi del servizio dati (WCF Data Services).

Restrizione dell'accesso all'archivio dati persistente e alle risorse locali

È opportuno concedere agli account utilizzati per accedere all'archivio persistente solo i diritti in un database o nel file system sufficienti a supportare i requisiti del servizio dati. Quando viene utilizzata l'autenticazione anonima, questo è l'account utilizzato per eseguire l'applicazione hosting. Per ulteriori informazioni, vedere Procedura: sviluppare un servizio WCF in esecuzione in IIS. Quando viene utilizzata la rappresentazione, agli utenti autenticati deve essere concesso l'accesso alle risorse, generalmente come parte di un gruppo di Windows.

Altre considerazioni sulla sicurezza

Protezione dei dati nel payload

OData si basa sul protocollo HTTP. In un messaggio HTTP, è possibile che l'intestazione contenga credenziali dell'utente rilevanti, a seconda dell'autenticazione implementata dal servizio dati. È possibile che anche il corpo del messaggio contenga dati del cliente rilevanti che devono essere protetti. In entrambi i casi, si consiglia di utilizzare SSL per proteggere queste informazioni in rete.

Intestazioni dei messaggi e cookie ignorati

Le intestazioni delle richieste HTTP, diverse da quelle che dichiarano i tipi di contenuto e i percorsi delle risorse, vengono ignorate e non vengono mai impostate dal servizio dati.

I cookie possono essere utilizzati come parte di uno schema di autenticazione, ad esempio con Autenticazione basata su form ASP.NET. Tuttavia, qualsiasi cookie HTTP impostato su una richiesta in entrata viene ignorato da WCF Data Services . È possibile che l'host di un servizio dati elabori il cookie, ma il runtime di WCF Data Services non analizza mai né restituisce cookie. Anche la libreria client WCF Data Services non elabora i cookie inviati nella risposta.

Requisiti dell'hosting personalizzato

Per impostazione predefinita, i servizi WCF Data Services vengono creati come un'applicazione ASP.NET ospitata in IIS. In tal modo il servizio dati potrà utilizzare i comportamenti sicuri della piattaforma. È possibile definire i servizi WCF Data Services ospitati da un host personalizzato. Per ulteriori informazioni, vedere Hosting del servizio dati (WCF Data Services). I componenti e la piattaforma che ospitano un servizio dati devono assicurare i seguenti comportamenti di sicurezza per impedire attacchi sul servizio dati:

• Limitare la lunghezza dell'URI accettata in una richiesta del servizio dati per tutte le possibili operazioni.

• Limitare la dimensione dei messaggi HTTP in ingresso e in uscita.

• Limitare il numero totale di richieste in sospeso in qualsiasi momento.

• Limitare la dimensione delle intestazioni HTTP e relativi valori e fornire l'accesso WCF Data Services ai dati dell'intestazione.

• Rilevare e contrastare gli attacchi noti, ad esempio attacchi di tipo riproduzione di messaggi e SYN TCP.

Valori non ulteriormente codificati

I valori delle proprietà inviati al servizio dati non sono ulteriormente codificati dal runtime di WCF Data Services . Ad esempio, quando una proprietà di stringa di un'entità contiene contenuto HTML formattato, i tag non vengono codificati nel formato HTML dal servizio dati. Il servizio dati non codifica ulteriormente neanche i valori di proprietà nella risposta. La libreria client inoltre non esegue nessuna codifica aggiuntiva.

Considerazioni per le applicazioni client

Le seguenti considerazioni sulla sicurezza si applicano a tutte le applicazioni che utilizzano il client WCF Data Services per accedere ai servizi OData :

• La libreria client presuppone che i protocolli utilizzati per accedere al servizio dati forniscano un livello di sicurezza appropriato.

• La libreria client utilizza tutti i valori predefiniti per i timeout e le opzioni di analisi degli stack di trasporto forniti dalla piattaforma sottostante.

• La libreria client non legge le impostazioni dai file di configurazione dell'applicazione.

• La libreria client non implementa alcun meccanismo di accesso tra domini. Al contrario, utilizza i meccanismi forniti dallo stack HTTP sottostante.

• La libreria client non dispone di elementi dell'interfaccia utente e non visualizza i dati né esegue il rendering dei dati che riceve o invia.

• È opportuno che le applicazioni client convalidino sempre l'input dell'utente e i dati accettati da servizi non attendibili.

Vedere anche

Altre risorse

Definizione di WCF Data Services
Libreria client WCF Data Services