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 semplicemente il mapping con identità Servizi di comunicazione di Azure.
- Offre flessibilità di integrazione perché il modello indipendente dall'identità funziona bene con il sistema di identità esistente.
- È possibile mantenere i dati dell'utente, ad esempio il nome, privato, perché non è necessario duplicarlo in Servizi di comunicazione di Azure.
Servizi di comunicazione di Azure modello di identità funziona con due concetti chiave.
Identità utente/mapping
Identifica in modo univoco un utente tramite un identificatore utente, generato da Servizi di comunicazione di Azure quando viene creato un utente. Gli identificatori esterni, ad esempio numeri di telefono, utenti, dispositivi, applicazioni e GUID, non possono essere usati per l'identità in Servizi di comunicazione di Azure. È possibile creare gratuitamente identità utente del Servizio di comunicazione di Azure. Gli addebiti vengono addebitati solo quando l'utente utilizza modalità di comunicazione, ad esempio una chat o una chiamata. È possibile eseguire il mapping dell'identità degli utenti a Servizi di comunicazione di Azure'identità utente nelle configurazioni 1:1, 1:N, N:1, N:N. Un utente può partecipare a più sessioni di comunicazione, usando più dispositivi contemporaneamente. Il mapping tra Servizi di comunicazione di Azure'identità utente e l'identità utente privata del cliente viene mantenuto e gestito dal cliente. Ad esempio, i clienti possono aggiungere una CommunicationServicesId colonna nella tabella utente per archiviare l'identità di Servizi di comunicazione di Azure associata.
Token di accesso
Dopo aver creato un'identità utente, a un utente viene concessa la possibilità di partecipare alle comunicazioni tramite chat o chiamate, usando i token di accesso. Ad esempio, solo un utente con token di chat può partecipare alla chat e all'utente con token VoIP può partecipare a una chiamata VoIP. Un utente può avere più token contemporaneamente. Servizi di comunicazione di Azure supporta più tipi di token da tenere in considerazione per gli utenti che richiedono l'accesso completo e l'accesso limitato. I token di accesso hanno le proprietà seguenti.
| Proprietà | Descrizione |
|---|---|
| Identità | Identifica in modo univoco un token |
| Scadenza | Un token di accesso è valido per un periodo di tempo compreso tra 1 e 24 ore. Dopo la scadenza, il token di accesso viene invalidato e non può essere usato per accedere ad alcuna primitiva. Per generare un token con una validità personalizzata, specificare il periodo di validità desiderato durante la generazione del token. Se non viene specificata alcuna validità personalizzata, il token sarà valido per 24 ore. È consigliabile usare token di durata breve per riunioni occasionali e token di durata più lunghi per gli agenti che usano l'applicazione per periodi di tempo più lunghi |
| Ambito | Il parametro scope definisce un set nonempty di primitive (Chat/VoIP) che possono essere usate. |
Un token di accesso è un token JSON Web (JWT) e ha la protezione dell'integrità. Ovvero, le attestazioni non possono essere modificate dopo che è stata rilasciata. Pertanto, una modifica manuale delle proprietà, ad esempio identità, scadenza o ambiti invaliderà il token di accesso. Se le primitive vengono usate con token invalidati, l'accesso verrà negato alle primitive. Servizi di comunicazione di Azure supporta gli ambiti seguenti per i token di accesso.
Ambiti del token di chat
Sono supportati tre tipi di ambiti di token di chat. Le autorizzazioni per ogni token sono descritte di seguito.
- 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 |
| Invia indicatore di digitazione | S | Y | S |
| Ottenere un partecipante per l'ID thread | S | Y | S |
Ambiti del token VoIP
Sono supportati due tipi di ambiti di token VoIP. Le autorizzazioni per ogni token sono descritte di seguito.
- 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 |
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.
- La rimozione 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. 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. In questo caso tutte le identità perdono l'accesso a Servizi di comunicazione di Azure e devono emettere nuovi token di accesso.
Considerazioni
- È consigliabile emettere token di accesso nel servizio lato server e non nell'applicazione del client. Il motivo è che il rilascio richiede una chiave di accesso o l'autenticazione di Microsoft Entra. La condivisione di segreti con l'applicazione del client non è consigliata per motivi di sicurezza.
- L'applicazione client deve usare un endpoint di servizio attendibile in grado di autenticare i client. L'endpoint deve emettere token di accesso per loro conto. Per altre informazioni, vedere Architettura client e server.
- Se si memorizzano nella cache i token di accesso a un archivio di backup, è consigliabile usare la crittografia. Un token di accesso è costituito da dati sensibili. Può essere usato per attività dannose se non è protetto. Un utente con un token di accesso può avviare l'SDK e accedere all'API. L'API accessibile è limitata solo in base agli ambiti di cui dispone il token di accesso.
- È consigliabile emettere token di accesso con solo gli ambiti necessari.
Passaggi successivi
- Per un'introduzione alla gestione dei token di accesso, vedere Creare e gestire i token di accesso.
- Per un'introduzione all'autenticazione, vedere Eseguire l'autenticazione per Servizi di comunicazione di Azure.
- Per un'introduzione alla residenza e alla privacy dei dati, vedere Disponibilità dell'area e residenza dei dati.
- Per informazioni su come creare rapidamente le identità per il test, vedere la guida introduttiva alla creazione rapida delle identità.