Controllo degli accessi del bus di servizio con firme di accesso condiviso
Questo articolo illustra le firme di accesso condiviso, il funzionamento e come usarle in modo indipendente dalla piattaforma con bus di servizio di Azure.
Sas protegge l'accesso alle bus di servizio in base alle regole di autorizzazione configurate in uno spazio dei nomi o in un'entità di messaggistica (coda o argomento). Una regola di autorizzazione ha un nome, è associata a diritti specifici e include una coppia di chiavi di crittografia. Usare il nome e la chiave della regola tramite l'SDK del bus di servizio o nel proprio codice per generare un token di firma di accesso condiviso. Un client può quindi passare il token al bus di servizio per dimostrare l'autorizzazione per l'operazione richiesta.
Nota
bus di servizio di Azure supporta l'autorizzazione dell'accesso a uno spazio dei nomi bus di servizio e alle relative entità usando Microsoft Entra ID. L'autorizzazione di utenti o applicazioni tramite il token OAuth 2.0 restituito da Microsoft Entra ID offre una maggiore sicurezza e facilità d'uso rispetto alle firme di accesso condiviso (SAS). Le chiavi di firma di accesso condiviso non dispongono di un controllo di accesso con granularità fine, sono difficili da gestire/ruotare e non hanno le funzionalità di controllo per associarne l'uso a un utente o a un'entità servizio specifica. Per questi motivi è consigliabile usare Microsoft Entra ID.
Microsoft consiglia di usare Microsoft Entra ID con le applicazioni bus di servizio di Azure quando possibile. Per altre informazioni, vedere gli articoli seguenti:
- Autenticare e autorizzare un'applicazione con l'ID Microsoft Entra per accedere alle bus di servizio di Azure entità.
- Autenticare un'identità gestita con l'ID Microsoft Entra per accedere alle risorse di bus di servizio di Azure
È possibile disabilitare l'autenticazione della chiave SAS o locale per uno spazio dei nomi del Bus di servizio e consentire solo l'autenticazione di Microsoft Entra. Per istruzioni dettagliate, vedere Disabilitare l'autenticazione locale.
Panoramica di SAS
Le firme di accesso condiviso (SAS) sono un meccanismo di autorizzazione basato sulle attestazioni che usa token semplici. Quando si usano le firme di accesso condiviso, le chiavi non vengono mai passate durante il transito. Le chiavi vengono usate per firmare crittograficamente informazioni che possono essere verificate in un secondo momento dal servizio. L'uso delle firme di accesso condiviso è paragonabile a quello della combinazione di nome utente e password in cui il client entra immediatamente in possesso di un nome di regola di autorizzazione e una chiave corrispondente. È paragonabile anche a un modello di sicurezza federata, in cui il client riceve un token di accesso firmato per un tempo limitato da un servizio token di sicurezza senza mai entrare in possesso della chiave di firma.
L'autenticazione sas in bus di servizio è configurata con i criteri di autorizzazione di accesso condiviso denominati con diritti di accesso associati e una coppia di chiavi crittografiche primarie e secondarie. Le chiavi sono valori a 256 bit nella rappresentazione in base 64. È possibile configurare regole a livello di spazio dei nomi, in bus di servizio code e argomenti.
Nota
Queste chiavi sono stringhe di testo normale che usano una rappresentazione di Base 64 e non devono essere decodificate prima che vengano usate.
Il token di firma di accesso condiviso contiene il nome dei criteri di autorizzazione scelti, l'URI della risorsa a cui si accede, un istante di scadenza e una firma crittografica HMAC-SHA256 calcolata su questi campi usando la chiave crittografica primaria o secondaria della regola di autorizzazione scelta.
Criteri di autorizzazione dell'accesso condiviso
Ogni spazio dei nomi bus di servizio e ogni entità bus di servizio dispone di criteri di autorizzazione di accesso condiviso costituiti da regole. I criteri a livello di spazio dei nomi si applicano a tutte le entità nello spazio dei nomi, indipendentemente dalla configurazione dei singoli criteri.
Per ogni regola del criterio di autorizzazione si stabiliscono tre informazioni: nome, ambito e diritti. Il nome è un nome univoco all'interno dell’ambito. L'ambito è abbastanza semplice: è l'URI della risorsa in questione. Per uno spazio dei nomi bus di servizio, l'ambito è lo spazio dei nomi completo, ad esempio https://<yournamespace>.servicebus.windows.net/.
I diritti assegnati dalla regola del criterio possono essere una combinazione di:
- Invia : concede il diritto di inviare messaggi all'entità
- Listen : concede il diritto di ricevere (coda, sottoscrizioni) e tutte le relative operazioni di gestione dei messaggi
- Gestisci: concede il diritto di gestire la topologia dello spazio dei nomi, inclusa la creazione e l'eliminazione di entità
Il diritto Di gestione include i diritti di invio e ascolto.
Uno spazio dei nomi o un criterio di entità può contenere fino a 12 regole di autorizzazione di accesso condiviso, fornendo spazio per tre set di regole, ognuno dei quali copre i diritti di base e la combinazione di Invio e Ascolto. Questo limite è per entità, ovvero lo spazio dei nomi e ogni entità può avere fino a 12 regole di autorizzazione di accesso condiviso. Questo limite sottolinea che l'archivio dei criteri di firma di accesso condiviso non deve essere un utente o un archivio di account del servizio. Se l'applicazione deve concedere l'accesso al bus di servizio in base alle identità utente o del servizio, deve implementare un servizio token di sicurezza che rilascia token di firma di accesso condiviso dopo un controllo di autenticazione e accesso.
A una regola di autorizzazione vengono assegnate una chiave primaria e una chiave secondaria. Si tratta di chiavi di crittografia complesse. Queste chiavi non possono essere perse perché sono sempre disponibili nel portale di Azure. È possibile utilizzare una delle chiavi generate ed è possibile rigenerarle in qualsiasi momento. Se si rigenera o si modifica una chiave nel criterio, tutti i token emessi in precedenza in base a tale chiave diventano immediatamente non validi. Le connessioni in corso create in base a tali token continuano invece a funzionare fino alla scadenza del token.
Quando si crea uno spazio dei nomi del bus di servizio, viene creato automaticamente un criterio denominato RootManageSharedAccessKey. Questo criterio dispone delle autorizzazioni Manage per l'intero spazio dei nomi. È consigliabile considerare questa regola come un account radice amministratore e non usarla nell'applicazione. È possibile creare altre regole dei criteri nella scheda Criteri di accesso condiviso per lo spazio dei nomi nel portale, tramite PowerShell o l'interfaccia della riga di comando di Azure.
È consigliabile rigenerare periodicamente le chiavi usate nell'oggetto SharedAccessAuthorizationRule . La presenza degli slot di chiave primaria e secondaria cha lo scopo di consentire di ruotare le chiavi gradualmente. Se l'applicazione usa in genere la chiave primaria, è possibile copiare la chiave primaria nello slot della chiave secondaria e solo allora rigenerare la chiave primaria. Il nuovo valore di chiave primaria può essere quindi configurato nelle applicazioni client, che possono accedere in modo continuativo usando la chiave primaria precedente nello slot secondario. Dopo che tutti i client sono stati aggiornati, è possibile rigenerare la chiave secondaria per ritirare infine la chiave primaria precedente.
Se è noto o si sospetta che una chiave è compromessa ed è necessario revocare le chiavi, è possibile rigenerare entrambi gli oggetti PrimaryKey e SecondaryKey per una regola SharedAccessAuthorizationRule, sostituendo le chiavi precedenti con quelle nuove. Se viene eseguita questa procedura, tutti i token firmati con le chiavi precedenti non sono più validi.
Procedure consigliate per l'uso della firma di accesso condiviso
Quando si utilizzano le firme di accesso condiviso nell'applicazione, è necessario essere consapevoli di due rischi potenziali:
- Se una firma di accesso condiviso viene persa, può essere usata da chiunque lo ottenga, che potrebbe compromettere le risorse bus di servizio.
- Se una firma di accesso condiviso fornita a un'applicazione client scade e l'applicazione non è in grado di recuperarne una nuova dal servizio, è possibile che le funzionalità dell'applicazione potrebbero risentirne.
Per mitigare questi rischi, è consigliabile attenersi ai consigli seguenti relativi all'utilizzo di firme di accesso condiviso:
- Chiedere ai client di rinnovare automaticamente la firma di accesso condiviso, se necessario: i client devono rinnovare la firma di accesso condiviso prima della scadenza, in modo da avere la possibilità di effettuare altri tentativi qualora il servizio che fornisce la firma di accesso condiviso non sia disponibile. Se la firma di accesso condiviso deve essere usata per alcune operazioni immediate e di breve durata che dovrebbero essere completate entro il periodo di scadenza, potrebbe non essere necessario perché la firma di accesso condiviso non dovrebbe essere rinnovata. Se tuttavia si dispone di client che effettuano normalmente richieste tramite la firma di accesso condiviso, è necessario considerare la possibilità che la firma scada. La considerazione chiave consiste nell'bilanciare la necessità che la firma di accesso condiviso sia di breve durata (come indicato in precedenza) con la necessità di garantire che il client richieda il rinnovo in anticipo (per evitare interruzioni a causa della scadenza della firma di accesso condiviso prima di un rinnovo riuscito).
- Prestare attenzione all'ora di inizio della firma di accesso condiviso: se si imposta ora l'ora di inizio della firma di accesso condiviso, a causa dell'asimmetria dell'orologio (differenze nell'ora corrente in base a computer diversi), potrebbero verificarsi errori intermittenti per i primi minuti. In generale, impostare l'ora di inizio ad almeno 15 minuti prima. In alternativa, non impostarlo affatto, che lo renderà valido immediatamente in tutti i casi. Lo stesso vale in genere anche per l'ora di scadenza. È consigliabile osservare fino a 15 minuti di sfasamento di orario in entrambe le direzioni per qualsiasi richiesta.
- Indicare una risorsa specifica a cui accedere: una procedura di sicurezza consigliata consiste nel fornire a un utente i privilegi minimi necessari. Se un utente necessita solo dell'accesso in lettura a una singola entità, concedere solo tale tipo di accesso per tale entità e non l'accesso in lettura/scrittura/eliminazione per tutte le entità. Ciò consente anche di ridurre i danni se una firma di accesso condiviso viene compromessa in quanto la firma è meno potente nelle mani di un utente malintenzionato.
- Non usare sempre la firma di accesso condiviso: a volte i rischi associati a un'operazione specifica rispetto al bus di servizio superano i vantaggi della firma di accesso condiviso. Per tali operazioni, creare un servizio di livello intermedio che scrive nel bus di servizio dopo la convalida, l'autenticazione e il controllo delle regole business.
- Usare sempre HTTPS: usare sempre HTTPS per creare o distribuire una firma di accesso condiviso. Se una firma di accesso condiviso viene passata tramite HTTP e intercettata, un utente malintenzionato che esegue un collegamento man-in-the-middle è in grado di leggere la firma di accesso condiviso e quindi usarla come l'utente previsto potrebbe avere, potenzialmente compromettendo i dati sensibili o consentendo il danneggiamento dei dati da parte dell'utente malintenzionato.
Configurazione dell'autenticazione della firma di accesso condiviso
È possibile configurare i criteri di autorizzazione di accesso condiviso in bus di servizio spazi dei nomi, code o argomenti. La configurazione in una sottoscrizione bus di servizio non è attualmente supportata, ma è possibile usare le regole configurate in uno spazio dei nomi o in un argomento per proteggere l'accesso alle sottoscrizioni.
In questa figura le regole di autorizzazione manageRuleNS, sendRuleNS e listenRuleNS si applicano sia alla coda Q1 che all'argomento T1, mentre listenRuleQ e sendRuleQ si applicano solo alla coda Q1 e sendRuleT si applica solo all'argomento T1.
Generare un token della firma di accesso condiviso
Qualsiasi client che abbia accesso al nome di una regola di autorizzazione e a una delle relative chiavi di firma può generare un token di firma di accesso condiviso. Il token viene generato creando una stringa nel formato seguente:
SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>
se: istante di scadenza del token. Valore intero che riflette i secondi trascorsi dalle00:00:00 UTCdel 1 ° gennaio 1970 (epoca UNIX) quando il token scade.skn: nome della regola di autorizzazione.sr- URI con codifica URL della risorsa a cui si accede.sig- Firma con codifica URL HMACSHA256. Il calcolo hash è simile allo pseudocode seguente e restituisce base64 di output binario non elaborato.urlencode(base64(hmacsha256(urlencode('https://<yournamespace>.servicebus.windows.net/') + "\n" + '<expiry instant>', '<signing key>')))
Importante
Per esempi di generazione di un token di firma di accesso condiviso con linguaggi di programmazione diversi, vedere Generare un token di firma di accesso condiviso.
Il token contiene i valori non hash in modo che il destinatario possa ricalcolare il codice hash con gli stessi parametri, verificando che l'autorità di certificazione sia in possesso di una chiave di firma valida.
L'URI di risorsa è l'URI completo della risorsa del bus di servizio a cui si richiede l'accesso. Ad esempio http://<namespace>.servicebus.windows.net/<entityPath> o sb://<namespace>.servicebus.windows.net/<entityPath>, ovvero http://contoso.servicebus.windows.net/contosoTopics/T1/Subscriptions/S3.
L'URI deve essere codificato in percentuale.
La regola di autorizzazione di accesso condiviso usata per la firma deve essere configurata nell'entità specificata da questo URI o in un elemento padre nella gerarchia. Ad esempio http://contoso.servicebus.windows.net/contosoTopics/T1 o http://contoso.servicebus.windows.net nell'esempio precedente.
Un token di firma di accesso condiviso è valido per tutte le risorse precedute dal prefisso <resourceURI> usato in signature-string.
Rigenerazione delle chiavi
È consigliabile rigenerare periodicamente le chiavi usate nei criteri di autorizzazione di accesso condiviso. La presenza degli slot di chiave primaria e secondaria cha lo scopo di consentire di ruotare le chiavi gradualmente. Se l'applicazione usa in genere la chiave primaria, è possibile copiare la chiave primaria nello slot della chiave secondaria e solo allora rigenerare la chiave primaria. Il nuovo valore di chiave primaria può essere quindi configurato nelle applicazioni client, che possono accedere in modo continuativo usando la chiave primaria precedente nello slot secondario. Dopo che tutti i client sono stati aggiornati, è possibile rigenerare la chiave secondaria per ritirare infine la chiave primaria precedente.
Se si sa o si sospetta che una chiave sia compromessa ed è necessario revocare le chiavi, è possibile rigenerare sia la chiave primaria che la chiave secondaria di un criterio di autorizzazione di accesso condiviso, sostituendole con nuove chiavi. Se viene eseguita questa procedura, tutti i token firmati con le chiavi precedenti non sono più validi.
Per rigenerare le chiavi primarie e secondarie nel portale di Azure, seguire questa procedura:
Passare allo spazio dei nomi bus di servizio nel portale di Azure.
Selezionare Criteri di accesso condiviso nel menu a sinistra.
Selezionare il criterio dall'elenco. Nell'esempio seguente viene selezionato RootManageSharedAccessKey .
Per rigenerare la chiave primaria, nella pagina Criteri di firma di accesso condiviso: RootManageSharedAccessKey selezionare Rigenera chiave primaria sulla barra dei comandi.
Per rigenerare la chiave secondaria, nella pagina Criteri di firma di accesso condiviso: RootManageSharedAccessKey selezionare ... dalla barra dei comandi e quindi selezionare Rigenera chiave secondaria.
Se si usa Azure PowerShell, usare il New-AzServiceBusKey cmdlet per rigenerare le chiavi primarie e secondarie per uno spazio dei nomi bus di servizio. È anche possibile specificare i valori per le chiavi primarie e secondarie generate usando il -KeyValue parametro .
Se si usa l'interfaccia della riga di comando di Azure, usare il az servicebus namespace authorization-rule keys renew comando per rigenerare le chiavi primarie e secondarie per uno spazio dei nomi bus di servizio. È anche possibile specificare i valori per le chiavi primarie e secondarie generate usando il --key-value parametro .
Autenticazione della firma di accesso condiviso con il bus di servizio
Lo scenario descritto di seguito include la configurazione delle regole di autorizzazione, la generazione di token di firma di accesso condiviso e l'autorizzazione client.
Per un esempio di applicazione bus di servizio che illustra la configurazione e usa l'autorizzazione di firma di accesso condiviso, vedere Autenticazione della firma di accesso condiviso con bus di servizio.
Accedere alle regole di autorizzazione per l'accesso condiviso in un'entità
Usare l'operazione get/update nelle code o negli argomenti delle librerie di gestione per bus di servizio per accedere/aggiornare le regole di autorizzazione di accesso condiviso corrispondenti. È anche possibile aggiungere le regole durante la creazione di code o argomenti usando queste librerie.
Usare l'autorizzazione con firma di accesso condiviso
Le applicazioni che usano uno dei bus di servizio SDK in qualsiasi linguaggio ufficialmente supportato come .NET, Java, JavaScript e Python possono usare l'autorizzazione di firma di accesso condiviso tramite i stringa di connessione passati al costruttore client.
Le stringhe di connessione possono includere un nome di regola (SharedAccessKeyName) e una chiave di regola (SharedAccessKey) o un token rilasciato in precedenza (SharedAccessSignature). Quando sono presenti nella stringa di connessione passata a un costruttore o a un metodo factory che accetta una stringa di connessione, il provider di token di firma di accesso condiviso viene automaticamente creato e popolato.
Per usare l'autorizzazione con firma di accesso condiviso con le sottoscrizioni del bus di servizio è possibile usare le chiavi della firma di accesso condiviso configurate in uno spazio dei nomi o in un argomento del bus di servizio.
Usare la firma di accesso condiviso (a livello HTTP)
Ora che si è appreso come creare firme di accesso condiviso per qualsiasi entità in bus di servizio, è possibile eseguire un HTTP POST:
POST https://<yournamespace>.servicebus.windows.net/<yourentity>/messages
Content-Type: application/json
Authorization: SharedAccessSignature sr=https%3A%2F%2F<yournamespace>.servicebus.windows.net%2F<yourentity>&sig=<yoursignature from code above>&se=1438205742&skn=KeyName
ContentType: application/atom+xml;type=entry;charset=utf-8
Questa procedura funziona per ogni elemento. È possibile creare una firma di accesso condiviso per una coda, un argomento o una sottoscrizione.
Se si assegna un mittente o un client a un token di firma di accesso condiviso, non ha direttamente la chiave e non può invertire l'hash per ottenerlo. Di conseguenza, è necessario controllare a cosa possono accedere e per quanto tempo. È importante tenere presente che, se si modifica la chiave primaria nel criterio, le firme di accesso condiviso create da tale chiave verranno invalidate.
Usare la firma di accesso condiviso (a livello AMQP)
Nella sezione precedente, è stato illustrato come utilizzare il token SAS con una richiesta HTTP POST per l'invio di dati per il Bus di servizio. Com'è noto, è possibile accedere al bus di servizio usando il protocollo AMQP (Advanced Message Queuing Protocol), ovvero il protocollo preferito da usare per motivi di prestazioni in molti scenari. L'utilizzo del token di firma di accesso condiviso con AMQP è descritto nel documento AMQP Claim-Based Security Version 1.0 in working draft dal 2013, ma attualmente è supportato da Azure.
Prima di iniziare a inviare i dati al bus di servizio, il server di pubblicazione deve inviare il token di firma di accesso condiviso all'interno di un messaggio AMQP a un nodo AMQP ben definito denominato "$cbs". Può essere visualizzato come una coda "speciale" usata dal servizio per acquisire e convalidare tutti i token di firma di accesso condiviso. Il server di pubblicazione deve specificare il campo ReplyTo all'interno del messaggio AMQP. Si tratta del nodo in cui il servizio risponde al server di pubblicazione con il risultato della convalida del token (un modello di richiesta/risposta semplice tra publisher e servizio). Questo nodo risposta viene creato al momento in quanto "creazione dinamica di nodo remoto" come descritto nella specifica di AMQP 1.0. Dopo avere verificato che il token di firma di accesso condiviso è valido, il server di pubblicazione può andare avanti e iniziare a inviare dati al servizio.
La procedura seguente illustra come inviare il token di firma di accesso condiviso con il protocollo AMQP usando la libreria AMQP.NET Lite . È utile se non è possibile usare il bus di servizio SDK ufficiale (ad esempio, in WinRT, .NET Compact Framework, .NET Micro Framework e Mono) in C#. Questa libreria è utile per comprendere il funzionamento della sicurezza basata sulle attestazioni a livello di AMQP, come si è visto come funziona a livello HTTP (con una richiesta HTTP POST e il token di firma di accesso condiviso inviato all'interno dell'intestazione "Authorization"). Se non sono necessarie informazioni approfondite su AMQP, è possibile usare l'SDK di bus di servizio ufficiale in uno dei linguaggi supportati come .NET, Java, JavaScript, Python e Go.
C#
/// <summary>
/// Send claim-based security (CBS) token
/// </summary>
/// <param name="shareAccessSignature">Shared access signature (token) to send</param>
private bool PutCbsToken(Connection connection, string sasToken)
{
bool result = true;
Session session = new Session(connection);
string cbsClientAddress = "cbs-client-reply-to";
var cbsSender = new SenderLink(session, "cbs-sender", "$cbs");
var cbsReceiver = new ReceiverLink(session, cbsClientAddress, "$cbs");
// construct the put-token message
var request = new Message(sasToken);
request.Properties = new Properties();
request.Properties.MessageId = Guid.NewGuid().ToString();
request.Properties.ReplyTo = cbsClientAddress;
request.ApplicationProperties = new ApplicationProperties();
request.ApplicationProperties["operation"] = "put-token";
request.ApplicationProperties["type"] = "servicebus.windows.net:sastoken";
request.ApplicationProperties["name"] = Fx.Format("amqp://{0}/{1}", sbNamespace, entity);
cbsSender.Send(request);
// receive the response
var response = cbsReceiver.Receive();
if (response == null || response.Properties == null || response.ApplicationProperties == null)
{
result = false;
}
else
{
int statusCode = (int)response.ApplicationProperties["status-code"];
if (statusCode != (int)HttpStatusCode.Accepted && statusCode != (int)HttpStatusCode.OK)
{
result = false;
}
}
// the sender/receiver might be kept open for refreshing tokens
cbsSender.Close();
cbsReceiver.Close();
session.Close();
return result;
}
Il metodo PutCbsToken() riceve la connessione, vale a dire l'istanza della classe di connessione AMQP indicata dalla libreria AMQP .NET Lite, che rappresenta la connessione TCP al servizio e il parametro sasToken, ovvero il token di firma di accesso condiviso da inviare.
Nota
È importante che la connessione venga creata con il meccanismo di autenticazione SASL impostato su ANONYMOUS (e non sul valore predefinito PLAIN con nome utente e password usato quando non è necessario inviare il token SAS).
Successivamente, il server di pubblicazione crea due collegamenti AMQP per inviare il token SAS e ricevere la risposta (il risultato di convalida del token) dal servizio.
Il messaggio AMQP contiene un insieme di proprietà e altre informazioni rispetto a un semplice messaggio. Il token SAS rappresenta il corpo del messaggio (tramite il relativo costruttore). La proprietà "ReplyTo" è impostata sul nome del nodo per la ricezione del risultato di convalida sul collegamento ricevitore (se si desidera modificare il nome, è possibile farlo e verrà creato in modo dinamico dal servizio). Le ultime tre proprietà personalizzate/relative all'applicazione vengono usate dal servizio per indicare quale tipologia di operazione è necessario eseguire. Come descritto nella bozza di specifica CBS, devono essere il nome dell'operazione ("put-token"), il tipo di token (in questo caso, servicebus.windows.net:sastoken) e il "nome" del gruppo di destinatari a cui viene applicato il token (l'intera entità).
Dopo che il server di pubblicazione invia il token di firma di accesso condiviso sul collegamento del mittente, l'autore deve leggere la risposta nel collegamento del ricevitore. La risposta è un semplice messaggio AMQP con una proprietà dell'applicazione denominata "status-code" che può contenere gli stessi valori di un codice di stato HTTP.
Diritti necessari per le operazioni del bus di servizio
La tabella seguente illustra i diritti di accesso necessari per l'esecuzione di operazioni relative alle risorse del bus di servizio.
| Operazione | Attestazione necessaria | Ambito attestazione |
|---|---|---|
| Spazio dei nomi | ||
| Configurare le regole di autorizzazione relative a uno spazio dei nomi | Gestione | Qualsiasi indirizzo dello spazio dei nomi |
| Registro di sistema del servizio | ||
| Enumerare i criteri privati | Gestione | Qualsiasi indirizzo dello spazio dei nomi |
| Iniziare l'attesa su uno spazio dei nomi del servizio | Ascolto | Qualsiasi indirizzo dello spazio dei nomi |
| Inviare messaggi a un listener in uno spazio dei nomi | Send | Qualsiasi indirizzo dello spazio dei nomi |
| Coda | ||
| Crea una coda | Gestione | Qualsiasi indirizzo dello spazio dei nomi |
| Eliminare una coda | Gestione | Qualsiasi indirizzo valido della coda |
| Enumerare le code | Gestione | /$Resources/Queues |
| Ottenere la descrizione di una coda | Gestione | Qualsiasi indirizzo valido della coda |
| Configurare le regole di autorizzazione per una coda | Gestione | Qualsiasi indirizzo valido della coda |
| Effettuare un invio alla coda | Send | Qualsiasi indirizzo valido della coda |
| Ricevere messaggi da una coda | Ascolto | Qualsiasi indirizzo valido della coda |
| Abbandonare o completare messaggi dopo la ricezione del messaggio in modalità PeekLock (blocco di visualizzazione) | Ascolto | Qualsiasi indirizzo valido della coda |
| Rinviare un messaggio per il successivo recupero | Ascolto | Qualsiasi indirizzo valido della coda |
| Spostare un messaggio nella coda dei messaggi non recapitabili | Ascolto | Qualsiasi indirizzo valido della coda |
| Ottenere lo stato associato a una sessione della coda dei messaggi | Ascolto | Qualsiasi indirizzo valido della coda |
| Impostare lo stato associato a una sessione della coda dei messaggi | Ascolto | Qualsiasi indirizzo valido della coda |
| Pianificare un messaggio per il recapito successivo | Ascolto | Qualsiasi indirizzo valido della coda |
| Argomento | ||
| Creare un argomento | Gestione | Qualsiasi indirizzo dello spazio dei nomi |
| Eliminare un argomento | Gestione | Qualsiasi indirizzo valido dell'argomento |
| Enumerare gli argomenti | Gestione | /$Resources/Topics |
| Ottenere la descrizione di un argomento | Gestione | Qualsiasi indirizzo valido dell'argomento |
| Configurare le regole di autorizzazione per un argomento | Gestione | Qualsiasi indirizzo valido dell'argomento |
| Effettuare un invio all'argomento | Send | Qualsiasi indirizzo valido dell'argomento |
| Abbonamento | ||
| Creare una sottoscrizione | Gestione | Qualsiasi indirizzo dello spazio dei nomi |
| Eliminare una sottoscrizione | Gestione | ../myTopic/Subscriptions/mySubscription |
| Enumerare le sottoscrizioni | Gestione | ../myTopic/Subscriptions |
| Ottenere la descrizione di una sottoscrizione | Gestione | ../myTopic/Subscriptions/mySubscription |
| Abbandonare o completare messaggi dopo la ricezione del messaggio in modalità PeekLock (blocco di visualizzazione) | Ascolto | ../myTopic/Subscriptions/mySubscription |
| Rinviare un messaggio per il successivo recupero | Ascolto | ../myTopic/Subscriptions/mySubscription |
| Spostare un messaggio nella coda dei messaggi non recapitabili | Ascolto | ../myTopic/Subscriptions/mySubscription |
| Ottenere lo stato associato a una sessione dell'argomento | Ascolto | ../myTopic/Subscriptions/mySubscription |
| Impostare lo stato associato a una sessione dell'argomento | Ascolto | ../myTopic/Subscriptions/mySubscription |
| Regole | ||
| Crea una regola | Ascolto | ../myTopic/Subscriptions/mySubscription |
| Eliminare una regola | Ascolto | ../myTopic/Subscriptions/mySubscription |
| Enumerare le regole | Manage o Listen | ../myTopic/Subscriptions/mySubscription/Rules |
Passaggi successivi
Per altre informazioni sulla messaggistica del bus di servizio, vedere gli argomenti seguenti.