VENDITE: 1-800-867-1389

Autenticazione e autorizzazione di Service Bus con il Servizio di controllo di accesso

Service Bus di Windows Azure supporta l'utilizzo del Access Control di Active Directory di Windows Azure (anche noto come Servizio Access Control o ACS) per l'autorizzazione delle operazioni di Service Bus.

Access Control di Active Directory di Windows Azure (anche noto come Servizio Access Control o ACS)

Il servizio ACS facilita l'autenticazione, in quanto stabilisce l'identità di un chiamante. A tale scopo, può procedere in due modi. Stabilisce l'identità in base a un elenco di identità (o account) di servizio, avente come ambito lo spazio dei nomi, secondo uno schema classico costituito da nome utente e password, oppure delega la determinazione dell'identità a un provider di identità esterno, come ad esempio Active Directory Federation Services (ADFS), Windows Live ID, Facebook, Google ID, Yahoo ID o OpenID.

Una volta stabilita l'identità, il servizio ACS ha (o riceve) diverse "attestazioni" correlate. Tali attestazioni corrispondono ad affermazioni relative all'utente o all'account non di tipo utente e sono firmate digitalmente dal provider di identità da cui sono state emesse. Per il servizio ACS questo costituisce una garanzia del fatto che le attestazioni siano corrette o almeno conformi alle regole di governance dell'autorità emittente. In altri termini, un set di attestazioni in cui si afferma che l'identità rappresentata corrisponde a "Bill Gates, Presidente di Microsoft Corporation" verrà probabilmente considerato più attendibile se emesso dal gateway ADFS di Microsoft e meno attendibile se emesso da terze parti. Le attestazioni sempre disponibili fra tutti i provider di identità e anche per le identità di servizio predefinite di ACS sono l'attestazione di provider, che identifica il provider stesso, e l'attestazione "nameidentifier", che corrisponde a un identificatore specifico e univoco del provider per l'identità in questione.

In secondo luogo, il servizio ACS facilita l'autorizzazione consentendo il mapping tra le attestazioni generate dai provider di identità e le attestazioni riconosciute da una "relying party". Service Bus è una relying party, in quanto si basa su ACS per gestire l'autenticazione e l'autorizzazione. Il mapping delle attestazioni serve a due scopi. Da un lato, normalizza le attestazioni dei linguaggi più diversi in un unico set di attestazioni riconosciuto dal servizio e, dall'altro, svolge la funzione di set di regole di autorizzazione. Se per una determinata identità non è presente alcun mapping a un set di attestazioni riconosciuto dal servizio, l'identità non può accedere al servizio.

L'autenticazione e l'autorizzazione passano sempre attraverso il client, il quale è l'unico componente che richiede la visibilità in rete diretta per tutte le parti interessate. È ad esempio possibile utilizzare un servizio ADFS non esposto all'esterno del firewall aziendale insieme al servizio ACS poiché quest'ultimo e ADFS non comunicano mai direttamente tra loro. Ogni volta che il client desidera eseguire un'operazione su una risorsa protetta, ad esempio inviare un messaggio a una coda di Service Bus, deve ottenere un riscontro del fatto di essere autorizzato a eseguirla. Tale riscontro viene fornito dal servizio ACS sotto forma di "token". Il token è semplicemente un contenitore per un set di attestazioni ed è firmato digitalmente dall'autorità emittente. Se il servizio ACS è configurato per stabilire l'identità utilizzando un provider di identità esterno, quale ADFS, sono coinvolti almeno due token. Il primo token viene fornito da un provider di identità come ADFS, che specifica come input uno fra i diversi tipi possibili di riscontro dell'identità dell'utente. Tale token viene quindi passato al servizio ACS, che lo valuta, esegue le regole ed emette il token per la relying party.

Service Bus e ACS

Service Bus e ACS hanno una relazione speciale, poiché a ogni spazio dei nomi servizio di Service Bus è associato uno spazio dei nomi servizio di ACS corrispondente, con lo stesso nome seguito dal suffisso "-sb". Questa relazione dipende dal modo in cui Service Bus e ACS gestiscono la relazione di trust reciproca e le chiavi private di crittografia associate.

Service Bus può formare una federazione con ACS V1 e con ACS V2. Tutte le istanze di spazio dei nomi servizio create prima della versione del mese di settembre 2011 di Service Bus vengono federate con ACS V1, mentre tutte le istanze di spazio dei nomi servizio create dopo l'aggiornamento del servizio vengono federate con ACS V2. In questo argomento viene trattato solo ACS V2, ossia la versione corrente del servizio ACS.

All'interno dello spazio dei nomi servizio di ACS "-sb", che può essere esplorato dal portale di Windows Azure selezionando lo spazio dei nomi servizio di Service Bus e facendo clic sull'icona di ACS sulla barra multifunzione, è possibile accedere a una definizione di relying party "ServiceBus" seguendo la struttura di spostamento relativa a "Relying Party Applications". La definizione di relying party ha un valore di "area di autenticazione" mappato alla radice dello spazio dei nomi servizio Service Bus corrispondente (con schema "http") e imposta il tipo di token su "SWT" e la scadenza dei token su 1200 secondi. Le chiavi di firma inoltre non sono gestibili o accessibili tramite il portale o l'API.

Alla definizione di relying party "ServiceBus" è associato un "gruppo di regole predefinito per Service Bus", contenente il mapping di base che consente al "proprietario" di uno spazio dei nomi servizio di agire come utente con privilegi avanzati sullo spazio dei nomi servizio. Nel gruppo di regole sono incluse, per impostazione predefinita, tre regole semplici per il mapping dell'attestazione di input "nameidentifier" per l'identità di servizio "proprietario" alle tre attestazioni di autorizzazione riconosciute da Service Bus, ovvero "Send" per tutte le operazioni di invio, "Listen" per l'apertura dei listener o la ricezione di messaggi e "Manage" per l'osservazione o la gestione dello stato del tenant di Service Bus. Quest'ultimo ignora tutte le altre attestazioni contenute nei token che gli vengono forniti. L'identità di servizio "proprietario" è una normale identità di servizio nello spazio dei nomi servizio di ACS. È possibile e consigliabile crearne altre. L'utilizzo dell'identità "proprietario", in realtà, dovrebbe essere limitato all'esecuzione di attività amministrative.

Definizioni di relying party e ambito

Quando un client richiede un token di autorizzazione per inviare un messaggio a una coda che ad esempio risiede all'indirizzo https://tenant.servicebus.windows.net/my/test, nella richiesta sarà inclusa una forma normalizzata dell'indirizzo di destinazione come area di autenticazione di destinazione prevista. In questa normalizzazione viene semplicemente utilizzato uno schema URI comune per tutti i protocolli. La richiesta di un token per l'interazione con un'entità di Service Bus che risieda all'indirizzo https://tenant.servicebus.windows.net/my/test o sb://tenant.servicebus.windows.net/my/test pertanto verrà sempre effettuata utilizzando un URI dell'area di autenticazione basato sullo schema "http" http://tenant.servicebus.windows.net/foo/bar. Anche tutte le definizioni di relying party, di conseguenza, devono utilizzare lo schema URI "http" normalizzato per l'URI dell'area di autenticazione.

Quando la richiesta arriva al servizio ACS, questo assocerà l'URI dell'area di autenticazione alle definizioni di relying party in base a una "corrispondenza del prefisso più lungo". In altri termini, viene selezionata ed eseguita la relying party il cui indirizzo "URI dell'area di autenticazione" sia il prefisso disponibile più lungo per l'indirizzo per cui viene richiesto il token, insieme alla definizione della relying party e alle definizioni di regole associate. La definizione di relying party "ServiceBus" predefinita ha come ambito l'intero spazio dei nomi servizio di Service Bus corrispondente. Questo significa che il relativo URI dell'area di autenticazione, corrispondente all'indirizzo radice dello spazio dei nomi servizio di Service Bus, è un prefisso per tutti gli indirizzi possibili in uno spazio dei nomi servizio di Service Bus. Le definizioni delle regole abilitate per tale definizione di relying party garantiscono pertanto l'accesso completo all'intero spazio dei nomi servizio di Service Bus.

La procedura per creare un set di regole di autorizzazione con un ambito per una coda che, ad esempio, risieda all'indirizzo https://tenant.servicebus.windows.net/my/test consiste nel creare una nuova definizione di relying party, specificando l'indirizzo della coda o un prefisso di tale indirizzo come URI dell'area di autenticazione della nuova definizione tramite il portale o l'API di gestione di ACS. Nel portale i passaggi sono i seguenti:

  • In Relying Party Applications fare clic su Add.

  • Immettere un nome visualizzato, ad esempio MyTest.

  • Immettere http://tenant.servicebus.windows.net/MyTest come URI dell'area di autenticazione per l'ambito.

  • Selezionare SWT come formato del token.

  • Impostare Encryption Policy su None.

  • Impostare Token lifetime su 1200 secondi.

  • Fare clic su Salva.

Il risultato è una definizione di relying party esclusiva per tale indirizzo. Poiché il relativo URI dell'area di autenticazione è un suffisso della definizione di relying party "ServiceBus" predefinita, la definizione eredita automaticamente le chiavi di firma corrette, in modo che Service Bus consideri attendibili i token generati in base alla nuova definizione. Tuttavia, dal momento che non sono presenti regole associate per la nuova definizione di relying party, nessuno sarà in grado di accedere alla coda, nemmeno il "proprietario", poiché non è prevista alcuna ereditarietà implicita automatica delle regole tra le definizioni di relying party, anche se costituiscono una gerarchia.

Dopo la creazione della nuova definizione, vi sarà un "gruppo di regole predefinito per <nomevisualizzato>" nella sezione Rule Groups del portale di ACS. Questo nuovo gruppo è vuoto per impostazione predefinita. Per consentire l'accesso alla coda, è necessario aggiungere regole al gruppo, una procedura descritta nella sezione che segue. In alternativa, è possibile abilitare per la definizione di relying party un gruppo di regole non vuoto già esistente. Ogni gruppo di regole può essere considerato come un elenco di controllo di accesso separato che può essere abilitato in qualsiasi posizione della gerarchia di relying party. Per abilitare un'ereditarietà simile a quella del file system, ad esempio per ereditare le regole predefinite della radice dello spazio dei nomi servizio di Service Bus, è sufficiente abilitare il "gruppo di regole predefinito per ServiceBus" corrispondente e qualsiasi altro gruppo di regole. A tale scopo, è necessario selezionare la casella appropriata nella sezione "Rule Groups" della definizione di relying party nel portale. Per i casi in cui è necessario applicare un set comune di regole di accesso a diverse risorse, ad esempio regole comuni per un set di risorse parallele come le code di pari livello in http://tenant.servicebus.windows.net/my/test e http://tenant.servicebus.windows.net/my/zoo, è anche possibile definire come ambito per la definizione di relying party il ramo dello spazio dei nomi servizio condiviso, ad esempio http://tenant.servicebus.windows.net/my.

In altri casi, gli scenari correnti possono richiedere una gestione del controllo di accesso diversa per i diversi aspetti della stessa entità di Service Bus, ad esempio autorizzazioni diverse per sottoscrizioni diverse di un argomento. In questi casi è possibile creare una definizione di relying party che abbia come ambito un determinato nome di sottoscrizione, ad esempio http://tenant.servicebus.windows.net/my/test/subscriptions/sub1/, e fare in modo che in tale definizione siano incluse le regole che si applicano solo alla sottoscrizione specifica.

Definizione delle regole

Le regole sono definite in gruppi e in genere comportano il mapping di un'attestazione di input a un'attestazione di output. Tutte le regole incluse in un gruppo generano un unico risultato combinato. Se pertanto vi sono tre regole corrispondenti per un determinato set di attestazioni di input che generano tre attestazioni di output distinte, nel token di autorizzazione emesso saranno contenute tutte e tre le attestazioni. Per Service Bus, le tre attestazioni di autorizzazione sono "Send" per tutte le operazioni di invio, "Listen" per l'apertura dei listener o la ricezione di messaggi e "Manage" per l'osservazione o la gestione dello stato del tenant di Service Bus. Per maggiore precisione, "Send", "Listen" e "Manage" sono i valori consentiti per il tipo di attestazione "net.windows.servicebus.action". Per creare una regola per Service Bus, è necessario mappare un'attestazione di input, ad esempio nameidentifier di un'identità di servizio, all'attestazione di autorizzazione desiderata. Per concedere all'identità di servizio "contoso" l'autorizzazione a effettuare un invio ("Send") a una coda, la definizione della regola dovrebbe quindi mappare l'attestazione nameidentifier dell'autorità emittente con valore "contoso" a un'attestazione di output personalizzata di tipo "net.windows.servicebus.action" con valore "Send". Per concedere all'identità di servizio tutte e tre le attestazioni di autorizzazione, sono necessarie tre regole distinte. L'obiettivo di disporre solo di tre attestazioni di autorizzazione è quello di rendere meno complessa la definizione delle regole.

Utilizzo dei provider di token

Un provider di token è un costrutto generico nell'API gestita .NET per Service Bus che consente di convertire una forma di credenziale in un token di autorizzazione generato dal servizio ACS, che può quindi essere passato a Service Bus per l'esecuzione dell'operazione desiderata. TokenProvider è una classe di base astratta con tre implementazioni concrete accessibili tramite metodi factory per la maggior parte degli scenari di base:

  • Chiave privata condivisa - Consente di ottenere un token basato su un'identità di servizio (e la chiave condivisa associata a tale identità) con definizione nello spazio dei nomi buddy "-sb" dello spazio dei nomi servizio di Service Bus in ACS. L'identità di servizio, di cui è stato già effettuato il provisioning e che è stata creata al momento della creazione dello spazio dei nomi servizio, viene chiamata "proprietario" e la relativa chiave privata condivisa è disponibile tramite il portale di gestione.

  • SWT (Simple Web Token) - Consente di ottenere un token basato su un token SWT acquisito precedentemente e passato al servizio ACS tramite il provider di token. Il token viene passato al servizio ACS come token binario mediante una richiesta RST/RSTR WS-Trust/WS-Federation. Per informazioni sulla configurazione dei provider WS-Federation, vedere la documentazione relativa al servizio ACS.

  • SAML - Consente di ottenere un token basato su un token SAML acquisito precedentemente e passato al servizio ACS tramite il provider di token. Il token viene passato al servizio ACS mediante una richiesta RST/RSTR WS-Trust/WS-Federation. Per informazioni sulla configurazione dei provider WS-Federation, vedere la documentazione relativa al servizio ACS.

Le API Service Bus MessagingFactory, NamespaceManager e TransportClientEndpointBehavior accettano istanze di TokenProvider. Il provider di token viene chiamato quando sono necessari token, inclusi gli scenari in cui una connessione attiva da molto tempo deve acquisire un nuovo token dopo la scadenza del token esistente (tale scadenza è pari a 1200 secondi per impostazione predefinita). Gli scenari di federazione che richiedono l'interazione dell'utente non richiedono l'implementazione di un provider di token personalizzato.

A scopo esemplificativo, un provider di token personalizzato per consentire a un utente di Facebook di inviare messaggi a una determinata coda dovrà presentare all'utente, tramite ACS, l'interfaccia utente di Facebook appropriata per stabilire l'identità di Facebook, effettuare il reindirizzamento tramite ACS, in modo che il token di Facebook venga scambiato con un token di ACS per Service Bus, e quindi estrarre il token di ACS non appena la richiesta viene reindirizzata all'applicazione locale. Nel sito Codeplex di Service Bus sarà disponibile una raccolta sempre più vasta di esempi di provider di token per la personalizzazione.

Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.

Aggiunte alla community

Mostra:
© 2014 Microsoft