Architettura della protezione

In questa sezione vengono descritti i vari punti di estendibilità che è possibile utilizzare per modificare o estendere la funzionalità del componente di protezione di Windows Communication Foundation (WCF). Per comprendere questi punti di estendibilità, è necessario comprendere l'architettura complessiva della protezione WCF. In questo argomento viene descritta l'architettura della protezione WCF in termini di componenti e loro relazioni. Viene inoltre illustrato come i punti di estendibilità descritti più avanti in questa sezione si inseriscono nel modello dell'architettura complessiva.

Ambito del componente di protezione WCF

La protezione WCF è estesa a più componenti dell'architettura WCF. In WCF l'obiettivo principale della protezione consiste nel fornire integrità, riservatezza, autenticazione, autorizzazione e controllo per le applicazioni compilate sul framework WCF. L'architettura WCF suddivide queste funzioni negli elementi seguenti:

• Protezione del trasferimento: responsabile di assicurare la riservatezza dei messaggi, l'integrità dei dati e l'autenticazione delle parti in comunicazione.
• Autorizzazione: responsabile di fornire un framework per prendere decisioni di autorizzazione.
• Controllo: responsabile della registrazione degli eventi correlati alla protezione nel registro di controllo.

Modalità di protezione e ambito del presente documento

La protezione del trasferimento può essere eseguita utilizzando una delle modalità di protezioneseguenti:

• Trasporto Tutte e tre le funzioni di protezione della comunicazione vengono fornite dal trasporto utilizzato per trasmettere i messaggi tra il client e il servizio.
• Messaggio La protezione del trasferimento viene fornita esclusivamente al livello dei messaggi SOAP; ciò significa che la protezione viene applicata direttamente al messaggio SOAP sul livello XML.
• Trasporto con credenziali del messaggio. La protezione del trasferimento viene eseguita sul livello di trasporto e sul livello messaggio. Il livello di trasporto fornisce riservatezza della comunicazione, integrità dei dati e autenticazione del servizio. Il messaggio fornisce l'autenticazione del client.

La restante parte di questo documento è dedicata alla modalità di protezione messaggio, sebbene alcune informazioni siano valide anche per la modalità trasporto con credenziali del messaggio. In particolare, la parte relativa all'autenticazione client è valida anche per la modalità trasporto con credenziali del messaggio, poiché tale modalità utilizza il livello del messaggio per eseguire l'autenticazione client nello stesso modo utilizzato dalla modalità messaggio.

Le discussioni sui componenti di autorizzazione e controllo sono valide per tutte le tre modalità di protezione allo stesso modo. Pertanto, tutte le informazioni riferite a tali componenti descritti nel documento sono valide per tutte le modalità di protezione supportate.

Concetti della modalità di protezione messaggio

Modello WS_Security

La modalità di protezione messaggio è basata sulla specifica WS-Security. Tale specifica definisce un framework che consente l'applicazione della protezione ai messaggi SOAP e fornisce un modello di protezione messaggio mediante token di protezione combinati con firme digitali e crittografia per proteggere e autenticare i messaggi SOAP. Per informazioni sulla specifica, vedere Web Services Security (WS-Security).

Terminologia

Un token di protezione asserisce le attestazioni e può essere utilizzato per dichiarare l'associazione tra segreti o chiavi di autenticazione e identità di protezione.

Un'attestazione è una dichiarazione eseguita da un'entità (ad esempio un nome, un'identità, un gruppo, una chiave o un privilegio). L'entità che esegue l'attestazione viene definita emittente dell'attestazione; l'entità su cui viene eseguita l'attestazione viene definita oggetto dell'attestazione.

Un emittente dell'attestazione può garantire o approvare le attestazioni in un token di protezione utilizzando la propria chiave per firmare o crittografare il token di protezione. In questo modo viene consentita l'autenticazione delle attestazioni nel token di protezione.

Le firme del messaggio vengono utilizzate per verificare l'origine e l'integrità del messaggio. Tali firme vengono utilizzate anche dai producer dei messaggi per dimostrare di conoscere la chiave, in genere di una terza parte, utilizzata per confermare le attestazioni in un token di protezione e quindi associare la relativa identità (e tutte le altre attestazioni rappresentate dal token di protezione) ai messaggi creati.

Token di protezione

WS-Security definisce vari tipi di token di protezione e fornisce un modello estensibile che consente di definire in modo indipendente tipi di token di protezione aggiuntivi. Ogni definizione di tipo di token contiene una serializzazione XML del token. Ciò consente di aggiungere direttamente la rappresentazione del token al messaggio.

Di seguito sono riportati alcuni tipi di token di protezione definiti in WS-Security:

• Token nome utente
• Token di certificato X.509
• Token Kerberos
• Token SAML

Esistono quattro modalità di utilizzo definite dei token e i token collegati a un determinato messaggio rientrano esattamente in una di queste categorie:

• SignedSupporting
• SignedEndorsing
• SignedEncrypted
• EncryptedEndorsing

In .NET Framework 3.0 un messaggio client può contenere un solo token di un determinato tipo, ma più token di tipi diversi.

In .NET Framework 3.5 i messaggi client possono contenere più token di un determinato tipo e token di tipi diversi.

Questa funzionalità consente numerosi scenari, tra cui:

• Invio di attestazioni incrementali. È possibile che tutte le operazioni in un sevizio richiedano la presenza di un insieme di attestazioni, anche se alcune operazioni potrebbero richiederne di aggiuntive. Anzichè utilizzare token rilasciati separatamente per ogni operazione, il client può ottenere un token rilasciato con il set iniziale di attestazioni e utilizzare un altro token rilasciato con il resto delle attestazioni necessarie per l'operazione chiamata.
• Autenticazione a più fattori. Quando il client deve raccogliere token rilasciati da più autorità emittenti o con set di attestazioni diversi prima di ottenere l'autorizzazione ad eseguire un'operazione, WCF considera il token rilasciato come un tipo di token, pertanto in questo scenario è necessario che nel messaggio siano presenti due token rilasciati di supporto.

Si noti che non è possibile configurare un servizio in questo modo: un servizio può contenere un solo token di supporto.

Per ulteriori informazioni, vedere Procedura: utilizzare più token di protezione dello stesso tipo.

Implementazione di WS-Security

Essendo WS-Security alla base della protezione dei messaggi, l'implementazione WCF di WS-Security è un elemento fondamentale dell'intera modalità di protezione messaggio. Per estendere la funzionalità della modalità di protezione messaggio, è necessario comprendere il funzionamento dell'implementazione di WS-Security.

L'implementazione di WS-Security in WCF gestisce gli elementi seguenti:

• Serializzazione dei token di protezione da e verso i messaggi SOAP.
• Autenticazione dei token di protezione.
• Applicazione e verifica delle firme del messaggio.
• Crittografia e decrittografia dei messaggi SOAP

I punti di estendibilità WCF consentono la personalizzazione dei primi due elementi. È possibile modificare la serializzazione dei token di protezione esistenti o il modo in cui la protezione WCF autentica tali token. È inoltre possibile introdurre tipi di token di protezione completamente nuovi nella protezione WCF, tra cui le funzionalità di serializzazione e autenticazione.

Negli argomenti seguenti di questa sezione viene illustrato come utilizzare i punti di estendibilità dell'implementazione di WS-Security per personalizzare la funzionalità dei token di protezione.

Autorizzazione

I token di protezione vengono deserializzati dal messaggio in ingresso e autenticati. Il processo di autenticazione produce un insieme di oggetti criteri di autorizzazione. Ogni oggetto rappresenta una parte di dati del token di protezione. Tali dati vengono utilizzati durante la fase di autorizzazione.

I criteri di autorizzazione creano un insieme di attestazioni rappresentato da un determinato token di protezione. Questo insieme di attestazioni viene quindi fornito per le decisioni di autorizzazione alla classe ServiceAuthorizationManager e alla logica all'interno della proprietà AuthorizationContext.

Identità

Oltre alle attestazioni, WCF crea un'implementazione dell'interfaccia IIdentity per rappresentare il chiamante dell'infrastruttura esistente (creata dal modello di protezione .NET Framework). Questa istanza di IIdentity rappresenta l'identità Windows del chiamante se viene eseguito il mapping del token di protezione a un account di Windows o un'identità primaria contenente il nome del chiamante. È possibile accedere a tali identità anche utilizzando ServiceSecurityContext. (Per ulteriori informazioni, vedere Procedura: esaminare il contesto di protezione.) È possibile personalizzare il modo in cui vengono create le identità in WCF utilizzando uno dei metodi seguenti:

• Implementazione di un'estensione personalizzata della classe SecurityTokenAuthenticator.
• Integrazione con ASP.NET estendendo la classe MembershipProvider o creando un'implementazione personalizzata di IAuthorizationPolicy e inserendola in ServiceAuthorizationManager.
• Creazione di un'interfaccia IAuthorizationPolicy personalizzata.

Il provider di appartenenze personalizzato funziona solo se per autenticare il chiamante viene utilizzata l'autenticazione nome utente/password. MembershipProvider convalida la coppia nome utente/password. Se la coppia è valida, WCF crea un'identità primaria che rappresenta il chiamante autenticato dopo la convalida di MembershipProvider.

Per facilitare l'integrazione con l'infrastruttura della protezione .NET Framework esistente, WCF imposta per impostazione predefinita la proprietà CurrentPrincipal su un'istanza dell'interfaccia IPrincipal che rappresenta il chiamante. L'istanza dell'interfaccia IPrincipal viene creata in base alle informazioni contenute nell'interfaccia IIdentity generata.

L'interfaccia IIdentity può essere ulteriormente ampliata integrando con ASP.NET RoleProvider. RoleProvider aggiunge un set di ruoli a cui appartiene il chiamante. La logica di autorizzazione utilizza queste informazioni per la decisione sull'accesso.

Per ulteriori informazioni sull'identità, vedere Identità del servizio e autenticazione.

Invio di messaggi protetti

Di seguito viene illustrato come proteggere un messaggio nel client quando si utilizza la modalità di protezione messaggio. Vengono inoltre illustrati i componenti interessati e le relazioni esistenti tra di essi:

1. Il codice dell'applicazione viene eseguito e genera un messaggio.
2. Nella fase di provisioning del token, vengono allegate le credenziali client (ad esempio i certificati X.509). In un scenario federato, viene contattato un emittente del token per fornire le credenziali.
3. Le credenziali vengono utilizzate per creare il token di protezione.
4. Nella fase di autenticazione del token, i token vengono verificati.
5. Infine, i token di protezione vengono serializzati e inviati.

Ricezione di messaggi protetti

Di seguito vengono illustrati i processi che vengono eseguiti quando un messaggio protetto viene estratto dalla rete e verificato sul lato ricevente:

1. Nella fase di autenticazione, i token di protezione vengono deserializzati ed elaborati. Se lo si desidera, a questo punto è possibile utilizzare un provider di appartenenze ASP.NET per fornire i nomi utente e le password.
2. Dopo l'autenticazione, vengono estratti i criteri di autorizzazione.
3. Nella fase di valutazione dei criteri di autorizzazione, i criteri di autorizzazione vengono valutati e le attestazioni possono essere aggiunte a un contesto di valutazione. In questa fase vengono inoltre utilizzati i criteri di autorizzazione esterni. Questo passaggio, così come il successivo, viene effettuato tramite i metodi della classe ServiceAuthorizationManager.
4. Nella fase di autorizzazione del servizio, vengono assegnate le autorizzazioni corrette sulla base delle attestazioni aggiunte dai criteri di autorizzazione. Questo passaggio viene effettuato tramite i metodi della classe ServiceAuthorizationManager.
5. Dopo l'autorizzazione, avviene la rappresentazione del chiamante se il chiamante lo consente e il metodo del servizio lo richiede, o la proprietà ImpersonateCallerForAllOperations viene impostata sul comportamento dell'autorizzazione del servizio. Per ulteriori informazioni, vedere Delega e rappresentazione con WCF.
6. A questo punto, WCF genera una classe PrincipalPermission utilizzando le credenziali. Se necessario, è possibile utilizzare un provider di ruoli ASP.NET.
7. Il codice dell'applicazione viene eseguito.

Panoramica sui punti di estendibilità della protezione

Di seguito vengono illustrati i punti di estendibilità forniti dai componenti di protezione WCF. La figura è divisa in quattro categorie diverse in base al momento in cui viene raggiunto il punto di estendibilità durante l'elaborazione del messaggio. Tali categorie eseguono il mapping alle fasi di elaborazione della protezione del messaggio come descritto nelle due sezioni precedenti. Nella figura viene inoltre illustrato come le tecnologie dell'infrastruttura esistente possono essere integrate con la protezione WCF.

Vedere anche

Riferimenti

PrincipalPermission
ServiceAuthorizationManager
ServiceSecurityContext

Concetti

Architettura di Windows Communication Foundation
Delega e rappresentazione con WCF

Altre risorse

Credenziale personalizzata e convalida della credenziale