Meccanismi del controllo di accesso

  • Articolo

È possibile controllare l'accesso in diversi modi con Windows Communication Foundation (WCF). In questo argomento vengono discussi brevemente i vari meccanismi e vengono forniti suggerimenti sulle circostanze in cui utilizzarli. L'argomento consente quindi di selezionare il meccanismo corretto da utilizzare. Le tecnologie di accesso sono elencate in ordine di complessità. La tecnologia più semplice è PrincipalPermissionAttribute, la più complessa è il modello di identità.

Oltre a questi meccanismi, la rappresentazione e la delega con WCF sono illustrate in Delega e rappresentazione.

PrincipalPermissionAttribute

PrincipalPermissionAttribute viene utilizzato per limitare l'accesso a un metodo del servizio. Quando l'attributo è applicato a un metodo, può essere utilizzato per richiedere l'identità o l'appartenenza di un chiamante specifico in un gruppo di Windows o in un ruolo ASP.NET. Se il client viene autenticato utilizzando un certificato X.509, acquisisce un'identità primaria costituita dal nome del soggetto e dall'identificazione personale del certificato.

Utilizzare PrincipalPermissionAttribute per controllare l'accesso alle risorse del computer in cui il servizio è in esecuzione e se gli utenti del servizio faranno sempre parte dello stesso dominio Windows nel quale il servizio è in esecuzione. È possibile creare facilmente gruppi di Windows che presentano livelli di accesso specifici (ad esempio nessuno, sola lettura o lettura e scrittura).

Per altre informazioni sull'utilizzo dell'attributo, vedere Procedura: Limitare l'accesso tramite la classe PrincipalPermissionAttribute. Per maggiori informazioni sull'identità, vedere Identità del servizio e autenticazione.

Provider di appartenenze ASP.NET

Una funzionalità di ASP.NET è il provider di appartenenza. Anche se tecnicamente il provider di appartenenza non è un meccanismo per il controllo dell'accesso, consente di controllare l'accesso al servizio limitando il set di possibili identità che possono accedere all'endpoint del servizio. La funzionalità di appartenenza comprende un database che può essere popolato con combinazioni nome utente/password che consentono agli utenti di un sito Web di creare account nel sito. Per accedere a un servizio che utilizza il provider di appartenenza, è necessario che l'utente esegua la procedura di accesso indicando nome utente e password.

Nota

È necessario innanzitutto popolare il database con la funzionalità ASP.NET, quindi è possibile per un servizio WCF utilizzare tale database a scopo di autorizzazione.

È inoltre possibile utilizzare la funzionalità di appartenenza se si dispone già di un database di appartenenza di un sito Web ASP.NET esistente e si desidera consentire agli stessi utenti di utilizzare il servizio, autorizzandoli con lo stesso nome utente e password.

Per altre informazioni sull'uso della funzionalità di appartenenza in un servizio WCF, vedere Procedura: Usare il provider di appartenenze ASP.NET.

Provider di ruoli ASP.NET

Un'altra funzionalità di ASP.NET consiste nella possibilità di gestire l'autorizzazione mediante ruoli. Il provider di ruoli ASP.NET consente a uno sviluppatore di creare ruoli per gli utenti e di assegnare ogni utente a uno o più ruoli. Come per il provider di appartenenza, i ruoli e le assegnazioni sono archiviati in un database e possono essere popolati mediante strumenti forniti da una particolare implementazione del provider di ruoli ASP.NET. Come per la funzionalità di appartenenza, gli sviluppatori di WCF possono utilizzare le informazioni contenute nel database per autorizzare gli utenti del servizio in base ai ruoli. Essi, ad esempio, possono utilizzare il provider di ruoli in combinazione con il meccanismo di controllo dell'accesso PrincipalPermissionAttribute descritto in precedenza.

È inoltre possibile utilizzare il provider di ruoli ASP.NET se si dispone già di un database del provider di ruoli ASP.NET esistente e si desidera utilizzare lo stesso set di regole e assegnazioni utente nel servizio WCF.

Per altre informazioni sull'uso della funzionalità del provider di ruoli, vedere Procedura: Usare il provider di ruoli ASP.NET con un servizio.

Gestione autorizzazioni

Un'altra funzionalità riunisce la Gestione autorizzazioni (AzMan) e il provider di ruoli ASP.NET per l'autorizzazione dei client. Quando ASP.NET ospita un servizio Web, AzMan può essere integrato nell'applicazione per fare in modo che l'autorizzazione al servizio venga eseguita tramite AzMan. La funzionalità di Gestione ruoli di ASP.NET fornisce un'API per gestire ruoli applicazione, aggiungere e rimuovere utenti dai ruoli e controllare l'appartenenza al ruolo. Con questa API non è tuttavia possibile eseguire una query per appurare se un utente è autorizzato a eseguire una determinata attività o operazione. AzMan consente di definire operazioni singole e di riunirle in attività. Con AZMan, oltre a controlli del ruolo è inoltre possibile verificare se un utente è autorizzato a eseguire un'attività. L'assegnazione del ruolo e l'autorizzazione all'esecuzione dell'attività possono essere configurate esternamente all'applicazione o eseguite a livello di programmazione all'interno dell'applicazione. Lo snap-in MMC (Microsoft Management Console) per l'amministrazione di AzMan consente agli amministratori di modificare le attività che un ruolo può eseguire in fase di esecuzione e di gestire l'appartenenza di ogni utente ai ruoli.

È inoltre possibile utilizzare AzMan e il provider di ruoli ASP.NET se si dispone già dell'accesso a un'installazione di AzMan esistente e si desidera autorizzare gli utenti del servizio utilizzando le funzionalità della combinazione AzMan/provider di ruoli.

Per altre informazioni su AzMan e sul provider di ruoli ASP.NET, vedere Procedura: Usare Gestione autorizzazioni (AzMan) con ASP.NET 2.0. Per altre informazioni sull'uso di AzMan e del provider di ruoli per i servizi WCF, vedere Procedura: Usare il provider di ruoli di Gestione autorizzazioni ASP.NET con un servizio.

Modello di identità

Il modello di identità è un set di API che consentono di gestire attestazioni e criteri per autorizzare client. Con il modello di identità, è possibile esaminare ogni attestazione contenuta in credenziali che il chiamante ha utilizzato per autenticarsi nel servizio, confrontare le attestazioni con il set di criteri per il servizio e concedere o negare l'accesso in base al confronto.

Utilizzare il modello di identità se sono necessari un controllo preciso e la possibilità di impostare criteri specifici prima di concedere l'accesso. Quando si utilizza PrincipalPermissionAttribute, ad esempio, il criterio consiste semplicemente nel fatto che l'identità dell'utente viene autenticata e appartiene a un ruolo specifico. Con il modello di identità, al contrario, è possibile creare un criterio in base al quale l'utente deve avere più di 18 anni ed essere in possesso di patente di guida valida perché gli sia consentito visualizzare un documento.

Un esempio della possibilità di avvalersi del controllo dell'accesso basato su attestazioni del modello di identità consiste nell'utilizzo di credenziali federate nello scenario del token rilasciato. Per altre informazioni sulla federazione e sui token emessi, vedere Federazione e token emessi.

Per altre informazioni sul modello di identità, vedere Gestione di attestazioni e autorizzazioni con il modello di identità.

Vedi anche