Condividi tramite

Protezione dei servizi

La sicurezza di un servizio Windows Communication Foundation (WCF) è costituita da due requisiti principali: sicurezza del trasferimento e autorizzazione. Un terzo requisito, il controllo degli eventi di sicurezza, è descritto in Controllo. In breve, la sicurezza del trasferimento include l'autenticazione (verifica dell'identità del servizio e del client), la riservatezza (crittografia dei messaggi) e l'integrità (firma digitale per rilevare la manomissione). L'autorizzazione è il controllo dell'accesso alle risorse, ad esempio consentendo solo agli utenti con privilegi di leggere un file. Usando le funzionalità di WCF, i due requisiti principali sono facilmente implementati.

Ad eccezione della BasicHttpBinding classe (o dell'elemento basicHttpBinding< nella configurazione), la> sicurezza del trasferimento è abilitata per impostazione predefinita per tutte le associazioni predefinite. Gli argomenti di questa sezione illustrano due scenari di base: implementazione della sicurezza e dell'autorizzazione del trasferimento in un servizio Intranet ospitato in Internet Information Services (IIS) e implementazione della sicurezza e dell'autorizzazione di trasferimento in un servizio ospitato in IIS.

Nozioni di base sulla sicurezza

La sicurezza si basa sulle credenziali. Una credenziale dimostra che un'entità è chi dichiara di essere. Un'entità può essere una persona, un processo software, una società o qualsiasi elemento che possa essere autorizzato. Ad esempio, un client di un servizio effettua un'attestazione di identità e la credenziale dimostra che l'attestazione è in qualche modo. In uno scenario tipico si verifica uno scambio di credenziali. Prima di tutto, un servizio effettua un'attestazione della propria identità e lo dimostra al client con credenziali. Viceversa, il client effettua un'attestazione di identità e presenta una credenziale al servizio. Se entrambe le parti considerano attendibili le credenziali dell'altro, è possibile stabilire un contesto sicuro in cui tutti i messaggi vengono scambiati in riservatezza e tutti i messaggi vengono firmati per proteggere l'integrità. Dopo che il servizio stabilisce l'identità del client, può associare le attestazioni nella credenziale a un ruolo o a un'appartenenza a un gruppo. In entrambi i casi, usando il ruolo o il gruppo a cui appartiene il client, il servizio autorizza il client a eseguire un set limitato di operazioni in base ai privilegi del ruolo o del gruppo.

Meccanismi di sicurezza di Windows

Se il client e il computer del servizio si trovano entrambi in un dominio Windows che richiede entrambi di accedere alla rete, le credenziali vengono fornite dall'infrastruttura di Windows. In tal caso, le credenziali vengono stabilite quando un utente del computer accede alla rete. Ogni utente e ogni computer in rete devono essere convalidati come appartenenti al set attendibile di utenti e computer. In un sistema Windows, ogni utente e computer è noto anche come entità di sicurezza.

In un dominio Windows supportato da un controller Kerberos, il controller Kerberos usa uno schema basato sulla concessione di ticket a ogni entità di sicurezza. I ticket concessi dal controller sono considerati attendibili da altri utenti autorizzati al ticket nel sistema. Ogni volta che un'entità tenta di eseguire un'operazione o di accedere a una risorsa (ad esempio un file o una directory in un computer), il ticket viene esaminato per la validità e, se viene superato, all'entità viene concesso un altro ticket per l'operazione. Questo metodo di concessione dei ticket è più efficiente rispetto all'alternativa di provare a convalidare il principale per ogni operazione.

Un meccanismo meno sicuro e meno recente usato nei domini Windows è NT LAN Manager (NTLM). Nei casi in cui Kerberos non può essere usato (in genere all'esterno di un dominio Windows, ad esempio in un gruppo di lavoro), NTLM può essere usato come alternativa. NTLM è disponibile anche come opzione di sicurezza per IIS.

In un sistema Windows l'autorizzazione funziona assegnando ogni computer e utente a un set di ruoli e gruppi. Ad esempio, ogni computer Windows deve essere configurato e controllato da una persona (o da un gruppo di persone) nel ruolo dell'amministratore. Un altro ruolo è quello dell'utente, che ha un set di autorizzazioni molto più vincolato. Oltre al ruolo, gli utenti vengono assegnati ai gruppi. Un gruppo consente a più utenti di svolgere lo stesso ruolo. In pratica, pertanto, un computer Windows viene amministrato assegnando utenti ai gruppi. Ad esempio, diversi utenti possono essere assegnati al gruppo di utenti di un computer e un set di utenti molto più vincolato può essere assegnato al gruppo di amministratori. In un computer locale, un amministratore può anche creare nuovi gruppi e assegnare altri utenti (o anche altri gruppi) al gruppo.

In un computer che esegue Windows, ogni cartella in una directory può essere protetta. Ciò significa che è possibile selezionare una cartella e controllare chi può accedere ai file e se possono copiare o meno il file oppure ,nel caso con privilegi più elevati, modificare un file, eliminare un file o aggiungere file alla cartella. Questo controllo di accesso è noto come controllo di accesso e il meccanismo per esso è noto come elenco di controllo di accesso (ACL). Quando si crea l'ACL, è possibile assegnare privilegi di accesso a qualsiasi gruppo o gruppo, nonché a singoli membri di un dominio.

L'infrastruttura WCF è progettata per usare questi meccanismi di sicurezza di Windows. Pertanto, se si sta creando un servizio distribuito in una intranet e i cui client sono limitati ai membri del dominio Windows, la sicurezza viene facilmente implementata. Solo gli utenti validi possono accedere al dominio. Dopo l'accesso degli utenti, il controller Kerberos consente a ogni utente di stabilire contesti sicuri con qualsiasi altro computer o applicazione. In un computer locale è possibile creare facilmente i gruppi e, quando si proteggono cartelle specifiche, questi gruppi possono essere usati per assegnare privilegi di accesso nel computer.

Implementazione della sicurezza di Windows nei servizi Intranet

Per proteggere un'applicazione eseguita esclusivamente in un dominio Windows, è possibile usare le impostazioni di sicurezza predefinite dell'associazione WSHttpBindingNetTcpBinding o . Per impostazione predefinita, tutti gli utenti nello stesso dominio Windows possono accedere ai servizi WCF. Poiché questi utenti hanno eseguito l'accesso alla rete, sono attendibili. I messaggi tra un servizio e un client vengono crittografati per la riservatezza e firmati per l'integrità. Per altre informazioni su come creare un servizio che usa la sicurezza di Windows, vedere Procedura: Proteggere un servizio con credenziali di Windows.

Autorizzazione tramite la classe PrincipalPermissionAttribute

Se è necessario limitare l'accesso alle risorse in un computer, il modo più semplice consiste nell'usare la PrincipalPermissionAttribute classe . Questo attributo consente di limitare la chiamata delle operazioni del servizio richiedendo all'utente di trovarsi in un gruppo o un ruolo di Windows specificato o di essere un utente specifico. Per altre informazioni, vedere Procedura: Limitare l'accesso con la classe PrincipalPermissionAttribute.

Impersonificazione

L'impersonificazione è un altro meccanismo che è possibile usare per controllare l'accesso alle risorse. Per impostazione predefinita, un servizio ospitato da IIS verrà eseguito con l'identità dell'account ASPNET. L'account ASPNET può accedere solo alle risorse per le quali dispone dell'autorizzazione. Tuttavia, è possibile impostare l'ACL per una cartella per escludere l'account del servizio ASPNET, ma consentire ad altre identità di accedere alla cartella. La domanda diventa quindi come consentire a tali utenti di accedere alla cartella se l'account ASPNET non è autorizzato a farlo. La risposta consiste nell'usare l'impersonificazione, in cui il servizio è autorizzato a usare le credenziali del client per accedere a una determinata risorsa. Un altro esempio è quando si accede a un database di SQL Server a cui solo determinati utenti dispongono dell'autorizzazione. Per altre informazioni sull'uso della rappresentazione, vedere Procedura: Rappresentare un client in un servizio e Delega e rappresentazione.

Sicurezza su Internet

La sicurezza su Internet è costituita dagli stessi requisiti della sicurezza in una intranet. Un servizio deve presentare le proprie credenziali per dimostrare l'autenticità e i client devono dimostrare la propria identità al servizio. Dopo aver dimostrato l'identità di un client, il servizio può controllare la quantità di accesso del client alle risorse. Tuttavia, a causa della natura eterogenea di Internet, le credenziali presentate differiscono da quelle usate in un dominio Windows. Mentre un controller Kerberos gestisce l'autenticazione degli utenti in un dominio con ticket per le credenziali, su Internet, servizi e client si basano su uno dei diversi modi per presentare le credenziali. L'obiettivo di questo argomento, tuttavia, è presentare un approccio comune che consente di creare un servizio WCF accessibile su Internet.

Uso di IIS e ASP.NET

I requisiti di sicurezza Internet e i meccanismi per risolvere tali problemi non sono nuovi. IIS è il server Web di Microsoft per Internet e dispone di molte funzionalità di sicurezza che risondono tali problemi; Inoltre, ASP.NET include funzionalità di sicurezza che i servizi WCF possono usare. Per sfruttare queste funzionalità di sicurezza, ospitare un servizio WCF in IIS.

Utilizzo dei provider di Membership e Ruoli in ASP.NET

ASP.NET include un sistema di gestione degli utenti e un provider di ruoli. Il provider è un database di coppie nome utente/password per l'autenticazione dei chiamanti che consente anche di specificare i privilegi di accesso di ogni chiamante. Con WCF è possibile usare facilmente un'appartenenza preesistente e un provider di ruoli tramite la configurazione. Per un'applicazione di esempio che dimostri questo, vedere l'esempio Membership and Role Provider.

Credenziali usate da IIS

A differenza di un dominio Windows supportato da un controller Kerberos, Internet è un ambiente senza un singolo controller per gestire milioni di utenti che accedono in qualsiasi momento. Al contrario, le credenziali in Internet sono spesso sotto forma di certificati X.509 (noti anche come Secure Sockets Layer, o SSL). Questi certificati vengono in genere emessi da un'autorità di certificazione, che può essere una società di terze parti che garantisce l'autenticità del certificato e la persona a cui è stato emesso. Per esporre il servizio su Internet, è necessario fornire anche un certificato attendibile per autenticare il servizio.

La domanda si pone a questo punto, come si ottiene un certificato di questo tipo? Un approccio consiste nell'accedere a un'autorità di certificazione di terze parti, ad esempio Authenticode o VeriSign, quando si è pronti per distribuire il servizio e acquistare un certificato per il servizio. Tuttavia, se si è nella fase di sviluppo con WCF e non è ancora pronto per l'acquisto di un certificato, strumenti e tecniche esistono per la creazione di certificati X.509 che è possibile usare per simulare una distribuzione di produzione. Per altre informazioni, vedere Utilizzo dei certificati.

Modalità di sicurezza

La programmazione della sicurezza WCF comporta alcuni punti decisionali critici. Una delle più semplici è la scelta della modalità di sicurezza. Le due principali modalità di sicurezza sono la modalità di trasporto e la modalità messaggio.

Una terza modalità, che combina la semantica di entrambe le modalità principali, è il trasporto con la modalità credenziali del messaggio.

La modalità di sicurezza determina la modalità di protezione dei messaggi e ogni scelta presenta vantaggi e svantaggi, come illustrato di seguito. Per altre informazioni sull'impostazione della modalità di sicurezza, vedere Procedura: Impostare la modalità di sicurezza.

Modalità trasporto

Esistono diversi livelli tra la rete e l'applicazione. Uno di questi è il livello di trasporto *,* che gestisce il trasferimento dei messaggi tra endpoint. A scopo attuale, è necessario solo comprendere che WCF usa diversi protocolli di trasporto, ognuno dei quali può proteggere il trasferimento dei messaggi. Per altre informazioni sui trasporti, vedere Trasporti.

Un protocollo comunemente usato è HTTP; un altro è TCP. Ognuno di questi protocolli può proteggere il trasferimento dei messaggi tramite un meccanismo (o meccanismi) specifico per il protocollo. Ad esempio, il protocollo HTTP è protetto tramite SSL su HTTP, comunemente abbreviato come "HTTPS". Pertanto, quando si seleziona la modalità di trasporto per la sicurezza, si sceglie di usare il meccanismo come determinato dal protocollo. Ad esempio, se si seleziona la classe WSHttpBinding e si imposta la modalità di sicurezza su Trasporto, si seleziona SSL su HTTP (HTTPS) come meccanismo di sicurezza. Il vantaggio della modalità di trasporto è che è più efficiente della modalità messaggio perché la sicurezza è integrata a un livello relativamente basso. Quando si utilizza la modalità di trasporto, il meccanismo di sicurezza deve essere implementato in base alla specifica per il trasporto e pertanto i messaggi possono fluire in modo sicuro solo da punto a punto nel trasporto.

Modalità messaggio

Al contrario, la modalità messaggio garantisce la sicurezza includendo i dati di sicurezza come parte di ogni messaggio. Utilizzando intestazioni di sicurezza XML e SOAP, le credenziali e altri dati necessari per garantire l'integrità e la riservatezza del messaggio sono incluse in ogni messaggio. Ogni messaggio include dati di sicurezza, quindi comporta un pedaggio sulle prestazioni perché ogni messaggio deve essere elaborato singolarmente. In modalità trasporto, una volta protetto il livello di trasporto, tutti i messaggi vengono trasmessi liberamente. Tuttavia, la sicurezza dei messaggi ha un vantaggio rispetto alla sicurezza del trasporto: è più flessibile. Ciò significa che i requisiti di sicurezza non sono determinati dal trasporto. È possibile usare qualsiasi tipo di credenziale client per proteggere il messaggio. In modalità trasporto, il protocollo di trasporto determina il tipo di credenziale client che è possibile usare.

Trasporto con credenziali del messaggio

La terza modalità combina il meglio sia del trasporto che della sicurezza dei messaggi. In questa modalità, la sicurezza del trasporto viene usata per garantire in modo efficiente la riservatezza e l'integrità di ogni messaggio. Allo stesso tempo, ogni messaggio include i dati delle credenziali, che consente l'autenticazione del messaggio. Con l'autenticazione, è anche possibile implementare l'autorizzazione. Autenticando un mittente, l'accesso alle risorse può essere concesso (o negato) in base all'identità del mittente.

Specificare il tipo di credenziale del client e il valore della credenziale

Dopo aver selezionato una modalità di sicurezza, è anche possibile specificare un tipo di credenziale client. Il tipo di credenziale client specifica il tipo che un client deve usare per autenticarsi nel server.

Non tutti gli scenari richiedono tuttavia un tipo di credenziale client. Usando SSL su HTTP (HTTPS), un servizio esegue l'autenticazione al client. Come parte di questa autenticazione, il certificato del servizio viene inviato al client in un processo denominato negoziazione. Il trasporto protetto da SSL garantisce che tutti i messaggi siano riservati.

Se si sta creando un servizio che richiede l'autenticazione del client, la scelta di un tipo di credenziale client dipende dal trasporto e dalla modalità selezionata. Ad esempio, l'uso del trasporto HTTP e la scelta della modalità di trasporto offrono diverse opzioni, ad esempio Basic, Digest e altri. Per altre informazioni su questi tipi di credenziali, vedere Informazioni sull'autenticazione HTTP.

Se si sta creando un servizio in un dominio Windows che sarà disponibile solo per altri utenti della rete, il più semplice da usare è il tipo di credenziale client Windows. Tuttavia, potrebbe anche essere necessario fornire un servizio con un certificato. Questo è illustrato in Procedura: Specificare i valori delle credenziali client.

Valori delle credenziali

Un valore delle credenziali è la credenziale effettiva usata dal servizio. Dopo aver specificato un tipo di credenziale, potrebbe anche essere necessario configurare il servizio con le credenziali effettive. Se hai selezionato Windows (e il servizio verrà eseguito in un dominio Windows), non specifichi un valore effettivo per le credenziali.

Identità

In WCF il termine identity ha significati diversi per il server e il client. In breve, quando si esegue un servizio, un'identità viene assegnata al contesto di sicurezza dopo l'autenticazione. Per visualizzare l'identità effettiva, controllare WindowsIdentity e PrimaryIdentity le proprietà della classe ServiceSecurityContext. Per altre informazioni, vedere Procedura: Esaminare il contesto di sicurezza.

Al contrario, nel client viene usata l'identità per convalidare il servizio. In fase di progettazione, uno sviluppatore client può impostare l'elemento <Identity> su un valore ottenuto dal servizio. In fase di esecuzione, il client controlla il valore dell'elemento rispetto all'identità effettiva del servizio. Se il controllo non riesce, il client termina la comunicazione. Il valore può essere un nome dell'entità utente (UPN) se il servizio viene eseguito con l'identità di un determinato utente o un nome dell'entità servizio (SPN) se il servizio viene eseguito con un account del computer. Per altre informazioni, vedere Identità del servizio e autenticazione. Le credenziali possono anche essere un certificato o un campo trovato in un certificato che identifica il certificato.

Livelli di protezione

La ProtectionLevel proprietà si verifica in diverse classi di attributi , ad esempio ServiceContractAttribute e le OperationContractAttribute classi . Il livello di protezione è un valore che specifica se i messaggi (o parti di messaggio) che supportano un servizio sono firmati, firmati e crittografati o inviati senza firme o crittografia. Per altre informazioni sulla proprietà, vedere Informazioni sul livello di protezione e per esempi di programmazione, vedere Procedura: Impostare la proprietà ProtectionLevel. Per altre informazioni sulla progettazione di un contratto di servizio con ProtectionLevel nel contesto, vedere Progettazione di contratti di servizio.

Vedere anche

  • Last updated on