Modello di identità

Servizi di comunicazione di Azure è un servizio indipendente dall'identità, che offre diversi vantaggi:

• Riutilizzare le identità esistenti dal sistema di gestione delle identità ed eseguirne il mapping con identità Servizi di comunicazione di Azure.
• Funziona bene con qualsiasi sistema di identità esistente e non ha alcuna dipendenza da un provider di identità specifico.
• Mantenere i dati dell'utente, ad esempio il nome, privati perché non è necessario duplicarli in Servizi di comunicazione di Azure.

Servizi di comunicazione di Azure modello di identità funziona con due concetti chiave.

Identità utente/mapping

Quando si crea un'identità utente tramite SDK o API REST, Servizi di comunicazione di Azure crea un identificatore utente univoco. Gli identificatori esterni, ad esempio numeri di telefono, ID utente/dispositivo/applicazione o nomi utente non possono essere usati direttamente in Servizi di comunicazione di Azure. È invece necessario usare le identità di Servizi di comunicazione e mantenere un mapping al proprio sistema id utente in base alle esigenze. La creazione di identità utente del Servizio di comunicazione di Azure è gratuita e gli addebiti vengono addebitati solo quando l'utente utilizza modalità di comunicazione, ad esempio una chat o una chiamata. Il modo in cui si usa l'identità di Servizi di comunicazione generata dipende dallo scenario in uso. Ad esempio, è possibile eseguire il mapping di un'identità 1:1, 1:N, N:1 o N:N ed è possibile usarla per utenti o applicazioni umane. Un utente può partecipare a più sessioni di comunicazione, usando più dispositivi contemporaneamente. La gestione di un mapping tra Servizi di comunicazione di Azure identità utente e il proprio sistema di identità è responsabilità dello sviluppatore e non è integrata. Ad esempio, è possibile aggiungere una CommunicationServicesId colonna nella tabella utente esistente per archiviare l'identità di Servizi di comunicazione di Azure associata. Una progettazione di mapping è descritta in modo più dettagliato in Architettura client-server.

Token di accesso

Dopo aver creato un'identità utente, un utente deve quindi disporre di un token di accesso con ambiti specifici per partecipare alle comunicazioni tramite chat o chiamate. Ad esempio, solo un utente con un token con ambito chat può partecipare alla chat e un utente con un token con voip ambito può partecipare a una chiamata VoIP. Un utente può avere più token contemporaneamente. Servizi di comunicazione di Azure supporta più ambiti di token per tenere conto degli utenti che richiedono l'accesso completo e l'accesso limitato. I token di accesso hanno le proprietà seguenti.

Proprietà	Descrizione
Oggetto	Identità utente rappresentata dal token.
Scadenza	Un token di accesso è valido per almeno 1 ora e fino a 24 ore. Dopo la scadenza, il token di accesso non è valido e non può essere usato per accedere al servizio. Per creare un token con una scadenza personalizzata, specificare la validità desiderata in minuti (>=60, <1440). Per impostazione predefinita, il token è valido per 24 ore. È consigliabile usare token di durata breve per riunioni occasionali e token di durata più lunghi per gli utenti che usano l'applicazione per periodi di tempo più lunghi.
Ambiti	Gli ambiti definiscono le primitive di comunicazione (Chat/VoIP) a cui è possibile accedere con il token.

Un token di accesso è un token JSON Web (JWT) e ha la protezione dell'integrità. Ciò significa che le attestazioni non possono essere modificate senza invalidare il token di accesso perché la firma del token non corrisponde più. Se le primitive di comunicazione vengono usate con token non validi, l'accesso viene negato. Anche se i token non sono crittografati o offuscati, l'applicazione non deve dipendere dal formato del token o dalle relative attestazioni. Il formato del token può cambiare e non fa parte del contratto API ufficiale. Servizi di comunicazione di Azure supporta gli ambiti seguenti per i token di accesso.

Ambiti del token di chat

Sono supportati tre ambiti di token di chat diversi. Le autorizzazioni per ogni ambito sono descritte nella tabella seguente.

• chat
• chat.join
• chat.join.limited

Ambito funzionalità/token	chat	chat.join	chat.join.limited
Creare un thread di chat	Y	N	N
Aggiornare il thread di chat con ID	Y	N	N
Eliminare il thread di chat con ID	Y	N	N
Aggiungere un partecipante a un thread di chat	S	Y	N
Rimuovere un partecipante da un thread di chat	S	Y	N
Ottenere thread di chat	S	Y	S
Ottenere il thread di chat con ID	S	Y	S
Get ReadReceipt	S	Y	S
Creare ReadReceipt	S	Y	S
Creare un messaggio per il thread di chat con ID	S	Y	S
Ottenere un messaggio con ID messaggio	S	Y	S
Aggiornare il proprio messaggio con l'ID messaggio	S	Y	S
Eliminare il proprio messaggio con l'ID messaggio	S	Y	S
Indicatore di digitazione	S	Y	S
Ottenere un partecipante per l'ID thread	S	Y	S

Ambiti del token VoIP

Sono supportati due ambiti di token VoIP. Le autorizzazioni per ogni ambito sono descritte nella tabella seguente.

• voip
• voip.join

Ambito funzionalità/token	voip	voip.join
Avviare una chiamata VoIP	Y	N
Avviare una chiamata VoIP in Virtual Rooms, quando l'utente è già invitato alla sala	S	S
Partecipare a una chiamata VoIP InProgress	S	S
Partecipare a una chiamata VoIP InProgress in Virtual Rooms, quando l'utente è già invitato alla sala	S	S
Tutte le altre operazioni in chiamata, ad esempio disattivazione/disattivazione, condivisione dello schermo e così via.	S	S
Tutte le altre operazioni in chiamata, ad esempio disattivazione/disattivazione, condivisione dello schermo e così via, in Virtual Rooms	Determinato dal ruolo utente	Determinato dal ruolo utente

È possibile usare l'ambito voip.join insieme a Rooms per creare una chiamata pianificata in cui solo gli utenti invitati ottengono l'accesso e dove gli utenti non possono creare altre chiamate.

Revocare o aggiornare il token di accesso

• Servizi di comunicazione di Azure libreria di identità può essere usata per revocare un token di accesso prima della scadenza. La revoca dei token non è immediata. La propagazione può richiedere fino a 15 minuti.
• L'eliminazione di un'identità, una risorsa o una sottoscrizione revoca tutti i token di accesso.
• Se si vuole rimuovere la capacità di un utente di accedere a funzionalità specifiche, revocare tutti i token di accesso per l'utente. Rilasciare quindi un nuovo token di accesso con un set di ambiti più limitato.
• La rotazione delle chiavi di accesso revoca tutti i token di accesso attivi creati usando una chiave di accesso precedente. Di conseguenza, tutte le identità perdono l'accesso a Servizi di comunicazione di Azure e necessitano di nuovi token di accesso.

Architettura client-server

È necessario creare e gestire i token di accesso utente tramite un servizio attendibile e non creare token nell'applicazione client. Le credenziali di stringa di connessione o Microsoft Entra necessarie per creare token di accesso utente devono essere protette, passandole a un client rischierebbe di perdere il segreto. L'impossibilità di gestire correttamente i token di accesso può comportare addebiti aggiuntivi per la risorsa quando i token vengono erogati liberamente e vengono usati in modo improprio da qualcun altro.

Se si memorizzano nella cache i token di accesso a un archivio di backup, è consigliabile crittografare i token. Un token di accesso consente l'accesso ai dati sensibili e può essere usato per attività dannose, se non è protetto. Chiunque disponga del token di accesso di un utente può accedere ai dati della chat dell'utente o partecipare a chiamate che rappresentano l'utente.

Assicurarsi di includere solo gli ambiti nel token necessario all'applicazione client per rispettare il principio di sicurezza dei privilegi minimi.

1. Un utente avvia l'applicazione client.
2. L'applicazione client contatta il servizio di gestione delle identità.
3. Il servizio di gestione delle identità autentica l'utente dell'applicazione. È possibile ignorare l'autenticazione per gli scenari in cui l'utente è anonimo, ma prestare attenzione ad aggiungere altre misure di protezione, ad esempio la limitazione e CORS al servizio, per attenuare l'abuso dei token.
4. Creare o trovare un'identità di Servizi di comunicazione per l'utente.
   1. Scenario di identità stabile: il servizio di gestione delle identità gestisce un mapping tra identità dell'applicazione e identità di Servizi di comunicazione. Le identità dell'applicazione includono gli utenti e altri oggetti indirizzabili, ad esempio servizi o bot. Se l'identità dell'applicazione è nuova, viene creata una nuova identità di comunicazione e viene archiviato un mapping.
   2. Scenario temporaneo di identità: il servizio di gestione delle identità crea una nuova identità di comunicazione. In questo scenario, lo stesso utente termina con un'identità di comunicazione diversa per ogni sessione.
5. Il servizio di gestione delle identità rilascia un token di accesso utente per l'identità applicabile e lo restituisce all'applicazione client.

Servizio app di Azure e Funzioni di Azure sono due alternative per il funzionamento del servizio di gestione delle identità. Questi servizi si ridimensionano facilmente e dispongono di funzionalità predefinite per autenticare gli utenti. Sono integrati con OpenID e provider di identità di terze parti come Facebook.

Passaggi successivi

• Per informazioni su come rilasciare token, vedere Creare e gestire i token di accesso.
• Per un'introduzione all'autenticazione, vedere Eseguire l'autenticazione per Servizi di comunicazione di Azure.
• Per informazioni sulla residenza e la privacy dei dati, vedere Disponibilità e residenza dei dati nell'area.
• Per informazioni su come creare rapidamente identità e token per il test, vedere la guida introduttiva alla creazione rapida delle identità.
• Per un esempio completo di un semplice servizio di gestione delle identità, vedere l'esercitazione sul servizio attendibile.
• Per un esempio di gestione delle identità più avanzato che si integra con Entra ID e Microsoft Graph, passare all'esempio di hero del servizio di autenticazione.