Esporta (0) Stampa
Espandi tutto

Autorizzazione nei servizi e nelle applicazioni Web in grado di riconoscere attestazioni

Pubblicato: aprile 2011

Aggiornamento: marzo 2015

Si applica a: Azure

  • Microsoft Azure Active Directory Access Control (anche noto come Servizio Access Controll o ACS)

  • Windows® Identity Foundation (WIF)

  • ASP.NET

  • Windows Communication Foundation (WCF)

In un'applicazione relying party il processo di autorizzazione determina le risorse a cui un'identità autenticata può accedere e le operazioni che l'identità può eseguire su tali risorse. Un'autorizzazione non appropriata o vulnerabile può portare alla diffusione delle informazioni e alla manomissione dei dati. Questo argomento descrive gli approcci disponibili per implementare l'autorizzazione per servizi e applicazioni Web ASP.NET in grado di riconoscere attestazioni mediante ACS e WIF.

  • Elencare gli approcci di autorizzazione basati su attestazioni.

  • Illustrare l'impostazione generale di ciascun approccio.

  • Spiegare i vantaggi e gli svantaggi di ciascun approccio.

Fin dalla prima versione .NET Framework offre un meccanismo flessibile per l'implementazione dell'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 WindowsIdentity rappresenta un utente autenticato da Active Directory, mentre 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. Ad esempio, WindowsPrincipal verifica l'appartenenza di WindowsIdentity ai gruppi Active Directory. Tale verifica viene eseguita chiamando il metodo IsInRole sull'interfaccia IPrincipal. La verifica dell'accesso in base ai ruoli è conosciuta come controllo di accesso basato sui ruoli (RBAC), descritto nella sezione corrispondente di questo argomento. È possibile usare le attestazioni per trasportare informazioni sui ruoli per supportare meccanismi di autorizzazione noti basati 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.

Le verifiche di autorizzazione vengono eseguite sul lato dell'applicazione, non sul lato di ACS. Quest'ultimo ha la funzione di servizio token di sicurezza (STS) che rilascia i token che trasportano le attestazioni all'applicazione. Le attestazioni vengono aggiunte ai token dai provider di identità e facoltativamente da ACS mediante il relativo motore 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 (http://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 regole ACS. Quest'ultimo può aggiungere, rimuovere o modificare le attestazioni incluse nel token rilasciato dal provider di identità. Il token rilasciato da ACS viene infine 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.

Autorizzazione WIF di ACS v2

Il controllo di accesso basato sui ruoli (RBAC) è un approccio di autorizzazione secondo il quale le autorizzazioni utente vengono gestite e applicate da un'applicazione in base ai ruoli utente. Se pertanto un utente dispone di un ruolo richiesto per eseguire un'azione, l'accesso viene consentito, altrimenti viene negato.

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”). Con questo approccio, il risultato è un valore booleano. Usarlo nelle istruzioni condizionali, inserendolo in qualsiasi punto del codice.

  • Usare la richiesta di sicurezza PrincipalPermission.Demand(). Con questo approccio, il risultato è un'eccezione se la richiesta non viene soddisfatta. È pertanto opportuno valutare la scelta di tale approccio nell'ambito della propria strategia di gestione delle eccezioni. La generazione di eccezioni è infatti più dispendiosa in termini di prestazioni rispetto alla restituzione di valori booleani. La richiesta può essere inserita in qualsiasi punto del codice.

  • Usare gli attributi dichiarativi [PrincipalPermission(SecurityAction.Demand, Role = “Administrator”)]. Questo approccio è detto dichiarativo perché viene usato per decorare i metodi. Non può essere usato nei blocchi di codice all'interno delle implementazioni del metodo. Il risultato è un'eccezione se la richiesta non viene soddisfatta. Valutare l'opportunità di usarlo nell'ambito della propria strategia di gestione delle eccezioni.

  • Usare l'autorizzazione URL intervenendo sulla sezione <authorization> del file web.config. Questo approccio è adatto per gestire l'autorizzazione a livello di URL, che è il livello meno sofisticato fra tutti quelli citati in precedenza. Il vantaggio è di poter apportare le modifiche nel file di configurazione senza dover compilare il codice per renderle effettive.

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 viene espresso da un apposito tipo di attestazione che dovrebbe essere disponibile nel token. Il tipo di attestazione ruolo viene espresso mediante il seguente URI:

http://schemas.microsoft.com/ws/2008/06/identity/claims/role

È possibile aggiungere un tipo di attestazione ruolo a un token in diversi modi:

  • Usare il motore regole ACS – In questo caso viene creata una regola usando il portale di gestione ACS o il servizio di gestione ACS per creare regole di trasformazione delle attestazioni che generino attestazioni di un determinato tipo di ruolo. Per altre informazioni sulle regole e sulla trasformazione dei token, vedere Gruppi di regole e regole e Procedura: Implementare la logica di trasformazione dei token mediante regole.

  • Trasformare le attestazioni arbitrarie in attestazioni del tipo di ruolo mediante ClaimsAuthenticationManager – ClaimsAuthenticationManager è un componente incluso in WIF che consente l'intercettazione delle richieste quando avviano un'applicazione, esaminando i token e trasformandoli mediante l'aggiunta, la modifica o la rimozione di attestazioni. Per altre informazioni su come usare ClaimsAuthenticationManager per trasformare le attestazioni, vedere Procedura: Implementare mediante WIF e ACS il controllo di accesso basato sui ruoli (RBAC) in un'applicazione ASP.NET in grado di riconoscere attestazioni

  • 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.

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. Ricordare che, nel caso del controllo di accesso basato sui ruoli, l'unica attestazione usata è l'attestazione del tipo di ruolo allo scopo di verificare se l'utente appartenga o meno a quel ruolo specifico. Il processo decisionale secondo l'approccio di autorizzazione basato sulle attestazioni prevede i seguenti passaggi:

  1. L'applicazione riceve una richiesta.

  2. L'applicazione estrae le attestazioni in ingresso.

  3. L'applicazione passa le attestazioni al meccanismo di logica decisionale. 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.

  4. Il meccanismo decisionale calcola il risultato in base alle attestazioni.

  5. L'accesso viene consentito se il risultato è vero e negato se il risultato è falso. Ad esempio, la regola può richiedere che l'utente abbia almeno 21 anni, abiti in Lombardia e venga autenticato tramite Windows Live ID (account Microsoft).

ACS ha la funzione di servizio token di sicurezza che rilascia i token che trasportano le attestazioni. È possibile controllare quali attestazioni vengono rilasciate (tipi e valori) usando il motore regole ACS. Per altre informazioni sul motore regole ACS, vedere Gruppi di regole e regole e Procedura: Implementare la logica di trasformazione dei token mediante 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. ClaimsAuthorizationManager consente di intercettare le richieste in ingresso e di implementare qualunque logica si desideri per prendere decisioni relative alle autorizzazioni in base alle attestazioni in ingresso. Costituisce inoltre un punto di estendibilità per esternalizzare tali decisioni e separarle dal codice dell'applicazione. Questo aspetto è molto importante se è necessario modificare la logica di autorizzazione. In tal caso, l'uso di ClaimsAuthorizationManager infatti non inciderà sull'integrità dell'applicazione, pertanto si ridurrà la probabilità di errori dell'applicazione a seguito della modifica. Per altre informazioni su come usare ClaimsAuthorizationManager per implementare il controllo di accesso basato sulle attestazioni, vedere Procedura: Implementare mediante WIF e ACS l'autorizzazione delle attestazioni in un'applicazione ASP.NET in grado di riconoscere attestazioni.

Vedere anche

Aggiunte alla community

AGGIUNGI
Microsoft sta conducendo un sondaggio in linea per comprendere l'opinione degli utenti in merito al sito Web di MSDN. Se si sceglie di partecipare, quando si lascia il sito Web di MSDN verrà visualizzato il sondaggio in linea.

Si desidera partecipare?
Mostra:
© 2015 Microsoft