Autorizzazione nei servizi e nelle applicazioni Web in grado di riconoscere attestazioni
Aggiornamento: 19 giugno 2015
Si applica a: Azure
Si applica a
Microsoft Azure Active Directory Access Control (anche noto come Servizio di controllo di accesso o ACS)
Windows® Identity Foundation (WIF)
ASP.NET
Windows Communication Foundation (WCF)
Riepilogo
Tramite l'autorizzazione di un'applicazione relying party vengono determinate le risorse di un'identità autenticata a cui è consentito l'accesso e le operazioni eseguibili in queste risorse. Un'autorizzazione non corretta o debole comporta la diffusione di informazioni e l'alterazione dei dati. In questo argomento vengono descritti gli approcci disponibili per implementare l'autorizzazione per le attestazioni ASP.NET applicazioni Web e i servizi tramite ACS e WIF.
Obiettivi
Elencare gli approcci di autorizzazione basati su attestazioni.
Illustrare l'impostazione generale di ciascun approccio.
Spiegare i vantaggi e gli svantaggi di ciascun approccio.
Panoramica
Fin dalla prima versione, in .NET Framework viene fornito un meccanismo flessibile per implementare l'autorizzazione. Tale meccanismo è basato su due interfacce semplici, ovvero IPrincipal e IIentity. Le implementazioni concrete di IIentity rappresentano un utente autenticato. Ad esempio, l'implementazione di WindowsIdentity rappresenta un utente autenticato da Active Directory e GenericIdentity rappresenta un utente autenticato da un'autenticazione personalizzata. Le implementazioni concrete di IPrincipal facilitano la verifica delle autorizzazioni con ruoli che dipendono dal relativo archivio. WindowsPrincipal, ad esempio, verifica l'appartenenza di WindowsIdentity ai gruppi di Active Directory. Tale verifica viene eseguita chiamando il metodo IsInRole sull'interfaccia IPrincipal. e viene definito controllo dell'accesso basato sui ruoli (RBAC). descritto nella sezione corrispondente di questo argomento. Le attestazioni possono essere utilizzate per trasferire le informazioni sui ruoli per supportare i comuni meccanismi dell'autorizzazione basata sui ruoli.
Le attestazioni possono inoltre essere usate per prendere decisioni relative alle autorizzazioni non tenendo conto semplicemente dei ruoli. Le attestazioni possono infatti essere basate praticamente su qualsiasi aspetto, ovvero età, CAP, misura di scarpe e così via. La verifica dell'accesso in base ad attestazioni arbitrarie è denominata autorizzazione basata su attestazioni o autorizzazione del controllo di accesso basato su attestazioni (CBAC), descritto nella sezione corrispondente di questo argomento.
I controlli di autorizzazione vengono eseguiti sul lato applicazione, non sul lato ACS. ACS funge da servizio token di sicurezza (STS) che rilascia i token che contengono le attestazioni all'applicazione. I token vengono arricchiti con attestazioni da provider di identità e facoltativamente da ACS stesso, usando il motore delle regole. Quando l'applicazione riceve il token con le attestazioni, può analizzarlo, estrarre le attestazioni appropriate e prendere decisioni relative alle autorizzazioni mediante il controllo di accesso basato sui ruoli o un approccio basato sulle attestazioni. WIF consente di analizzare il token e renderlo utilizzabile per tali decisioni mediante una semplice interfaccia API. Per altre informazioni su WIF, vedere WIF SDK (https://go.microsoft.com/fwlink/?LinkID=187481). Per avere un'idea del processo di autorizzazione nei servizi e nelle applicazioni in grado di riconoscere attestazioni, tenere presente il seguente diagramma. Se l'autenticazione ha esito positivo, il provider di identità genera un token (token IdP nel diagramma). Il token IdP può essere trasformato dal motore delle regole del servizio azure azure. ACS può aggiungere, rimuovere o modificare le attestazioni fornite nel token che il provider di identità genera. Infine, il token rilasciato da ACS viene inviato all'applicazione ed elaborato da WIF. La verifica dell'accesso viene eseguita in WIF mediante il controllo di accesso basato sui ruoli o il controllo di accesso basato sulle attestazioni.
.gif "ACS v2 WIF Authorization")
Controllo degli accessi in base al ruolo
Il controllo dell'accesso basato sui ruoli è un approccio di autorizzazione in cui le autorizzazioni utente vengono gestite e applicate da un'applicazione basata sui ruoli utente. Se un utente dispone di un ruolo necessario per l'esecuzione di un'azione, l'accesso viene consentito; in caso contrario, viene negato.
Metodo IPrincipal.IsInRole
Per implementare il controllo di accesso basato sui ruoli nelle applicazioni in grado di riconoscere attestazioni, usare il metodo IsInRole() dell'interfaccia IPrincipal come se si trattasse di applicazioni non in grado di riconoscere attestazioni. Per usare il metodo IsInRole() è possibile procedere in diversi modi:
Chiamare esplicitamente IPrincipal.IsInRole(“Administrator”). In questo approccio, il risultato è un valore booleano. Utilizzarlo nelle istruzioni condizionali. Può essere utilizzato in modo arbitrario in qualsiasi punto nel codice.
Usare la richiesta di sicurezza PrincipalPermission.Demand(). In questo approccio, il risultato è un'eccezione in caso di richiesta non soddisfatta. Deve rientrare nella strategia di gestione delle eccezioni. La generazione di eccezioni è infatti più dispendiosa in termini di prestazioni rispetto alla restituzione di valori booleani. Può essere utilizzata in qualsiasi punto nel codice.
Usare gli attributi dichiarativi [PrincipalPermission(SecurityAction.Demand, Role = “Administrator”)]. Questo approccio viene chiamato dichiarativo, in quanto viene utilizzato per decorare i metodi. Non può essere utilizzato in blocchi di codice nelle implementazioni del metodo. Il risultato è un'eccezione in caso di richiesta non soddisfatta. È necessario assicurarsi che rientri nella strategia di gestione delle eccezioni.
Uso dell'autorizzazione URL usando la <sezione di autorizzazione> in web.config. Questo approccio è adatto quando si gestisce l'autorizzazione a livello di URL. Si tratta del livello più grezzo tra quelli indicati in precedenza. Il vantaggio di questo approccio è che le modifiche vengono apportate nel file di configurazione, pertanto il codice non deve essere compilato per sfruttare la modifica.
Espressione dei ruoli come attestazioni
Quando il metodo IsInRole() viene chiamato, viene effettuata una verifica per determinare se l'utente corrente dispone di tale ruolo. Nelle applicazioni in grado di riconoscere attestazioni il ruolo è espresso da un tipo di attestazione del ruolo che deve essere disponibile nel token. Il tipo di attestazione del ruolo viene espresso tramite l'URI seguente:
https://schemas.microsoft.com/ws/2008/06/identity/claims/role
Vi sono diversi modi per arricchire un token con un tipo di attestazione del ruolo:
Uso del motore regole ACS: in questo caso si crea una regola usando il portale di gestione ACS o il servizio di gestione ACS per creare regole di trasformazione attestazioni che generano attestazioni di un determinato tipo di ruolo. Per altre informazioni sulle regole e la trasformazione del token, vedere Gruppi di regole e regole eprocedura: Implementare la logica di trasformazione del token tramite regole.
Trasformare le attestazioni arbitrarie in attestazioni del tipo di ruolo mediante ClaimsAuthenticationManager – ClaimsAuthenticationManager è un componente incluso in WIF Consente l'intercettazione delle richieste quando tramite esse viene avviata un'applicazione, esaminando i token e trasformandoli con l'aggiunta, la modifica o la rimozione di attestazioni. Per altre informazioni su come usare ClaimsAuthenticationManager per la trasformazione delle attestazioni, vedere Procedura: Implementare Controllo di accesso (RBAC) in un'applicazione con ASP.NET riconoscimento delle attestazioni tramite WIF e ACS
Mappare le attestazioni arbitrarie a un tipo di ruolo mediante la sezione di configurazione samlSecurityTokenRequirement – Questo è un approccio dichiarativo secondo il quale la trasformazione delle attestazioni viene eseguita usando soltanto la configurazione senza richiedere codice.
Controllo di accesso basato sulle attestazioni
Il controllo di accesso basato sulle attestazioni (CBAC) è un approccio di autorizzazione secondo il quale la decisione di concedere o negare l'accesso si basa su una logica arbitraria che usa i dati disponibili nelle attestazioni. Si tenga presente che nel caso del controllo dell'accesso basato sui ruoli, l'unica attestazione utilizzata è quella di tipo del ruolo. Per controllare se l'utente appartiene o meno a un ruolo specifico, è stata utilizzata un'attestazione di tipo del ruolo. Per illustrare il processo per prendere decisioni di autorizzazione utilizzando l'approccio basato sulle attestazioni, si tengano in considerazione i passaggi seguenti:
L'applicazione riceve una richiesta.
L'applicazione estrae le attestazioni in ingresso.
Tramite l'applicazione le attestazioni vengono passate al meccanismo della logica delle decisioni. Può essere codice in memoria o una chiamata a un servizio Web, una query relativa a un database o può richiamare un sofisticato motore regole.
Con il meccanismo delle decisioni viene calcolato il risultato in base alle attestazioni.
L'accesso viene consentito se il risultato è true e viene negato se è false. Ad esempio, la regola potrebbe essere che l'utente è di età 21 o superiore, vive a Washington State ed è stato autenticato da Windows Live ID (account Microsoft).
ACS funge da servizio di sicurezza del servizio di sicurezza che rilascia i token che contengono le attestazioni. È possibile controllare quali attestazioni vengono rilasciate, sia i tipi di attestazioni che i valori, usando il motore delle regole ACS. Per altre informazioni sul motore delle regole ACS, vedere Gruppi di regole e regole eprocedura: Implementare la logica di trasformazione token usando regole. ClaimsAuthorizationManager è un componente chiave per l'implementazione del controllo di accesso basato sulle attestazioni nelle applicazioni in grado di riconoscere attestazioni ed è incluso in WIF. Con ClaimsAuthorizationManager è possibile intercettare le richieste in ingresso e implementare qualsiasi logica di scelta per prendere decisioni di autorizzazioni basate sulle attestazioni in ingresso. Costituisce inoltre un punto di estendibilità per esternalizzare tali decisioni e separarle dal codice dell'applicazione. Questo aspetto diventa importante quando è necessario modificare la logica dell'autorizzazione. In tal caso, l'utilizzo di ClaimsAuthorizationManager non influirà sull'integrità dell'applicazione, quindi riducendo la probabilità di un errore di applicazione come risultato della modifica. Per altre informazioni su come usare ClaimsAuthorizationManager per implementare il controllo di accesso basato sulle attestazioni, vedere Procedura: Implementare l'autorizzazione delle attestazioni in un'applicazione con riconoscimento delle attestazioni ASP.NET tramite WIF e ACS.