Identiteitsmodel
Azure Communication Services is een identiteitsagnostische service, die meerdere voordelen biedt:
- Bestaande identiteiten opnieuw gebruiken vanuit uw identiteitsbeheersysteem en deze eenvoudig toewijzen met Azure Communication Services-identiteiten.
- Biedt integratieflexybiliteit als identiteitsagnostisch model werkt goed met uw bestaande identiteitssysteem.
- U kunt de gegevens van uw gebruiker, zoals hun naam, privé houden, omdat u deze niet hoeft te dupliceren in Azure Communication Services.
Azure Communication Services-identiteitsmodel werkt met twee belangrijke concepten.
Gebruikersidentiteit/toewijzing
Identificeert een gebruiker op unieke wijze via een gebruikers-id, die wordt gegenereerd door Azure Communication Services wanneer een gebruiker wordt gemaakt. Externe id's, zoals telefoonnummers, gebruikers, apparaten, toepassingen en GUID's, kunnen niet worden gebruikt voor identiteit in Azure Communication Services. U kunt gratis azure Communication Service-gebruikersidentiteiten maken. Er worden alleen kosten in rekening gebracht wanneer de gebruiker communicatiemodaliteiten gebruikt, zoals een chatgesprek of een gesprek. Uw gebruikersidentiteit kan worden toegewezen aan azure Communication Services-gebruikersidentiteit in configuraties 1:1, 1:N, N:1, N:N. Een gebruiker kan deelnemen aan meerdere communicatiesessies, met meerdere apparaten tegelijk. Toewijzing tussen de gebruikersidentiteit van Azure Communication Services en de persoonlijke gebruikersidentiteit van de klant wordt bewaard en onderhouden door de klant. Klanten kunnen bijvoorbeeld een CommunicationServicesId kolom toevoegen in hun gebruikerstabel om de bijbehorende Azure Communication Services-identiteit op te slaan.
Toegangstokens
Nadat een gebruikersidentiteit is gemaakt, krijgt een gebruiker de mogelijkheid om deel te nemen aan communicatie via chat of oproepen, met behulp van toegangstokens. Zo kan alleen een gebruiker met een chattoken deelnemen aan chat en kan een gebruiker met VoIP-token deelnemen aan een VoIP-oproep. Een gebruiker kan meerdere tokens tegelijk hebben. Azure Communication Services ondersteunt meerdere typen tokens voor gebruikers die volledige toegang en beperkte toegang nodig hebben. Toegangstokens hebben de volgende eigenschappen.
| Eigenschappen | Beschrijving |
|---|---|
| Identiteit | Een token uniek identificeren |
| Verloop | Een toegangstoken is gedurende een periode tussen 1 en 24 uur geldig. Nadat het is verlopen, wordt het toegangstoken ongeldig en kan het niet worden gebruikt voor toegang tot primitieven. Als u een token met een aangepaste geldigheid wilt genereren, geeft u de gewenste geldigheidsperiode op bij het genereren van het token. Als er geen aangepaste geldigheid is opgegeven, is het token 24 uur geldig. We raden u aan korte levensduurtokens te gebruiken voor eenmalige vergaderingen en tokens voor langere levensduur voor agents die de toepassing gedurende langere tijd gebruiken |
| Bereik | De bereikparameter definieert een lege set primitieven (Chat/VoIP) die kunnen worden gebruikt. |
Een toegangstoken is een JSON Web Token (JWT) en heeft integriteitsbeveiliging. Dat wil zeggen dat de claims niet kunnen worden gewijzigd nadat deze zijn uitgegeven. Een handmatige wijziging van eigenschappen, zoals identiteit, verlooptijd of bereiken, zorgt er dus voor dat het toegangstoken ongeldig wordt. Als primitieven worden gebruikt met ongeldige tokens, wordt de toegang tot de primitieven geweigerd. Azure Communication Services ondersteunt de volgende bereiken voor toegangstokens.
Bereiken van chattoken
Er worden drie typen chattokenbereiken ondersteund. Machtigingen voor elk token worden hieronder beschreven.
- chat
- chat.join
- chat.join.limited
| Mogelijkheid/tokenbereik | chat | chat.join | chat.join.limited |
|---|---|---|---|
| Chatthread maken | J | N | N |
| Chatthread bijwerken met id | J | N | N |
| Chatthread verwijderen met id | J | N | N |
| Deelnemer toevoegen aan een chatgesprek | J | Y | N |
| Deelnemer verwijderen uit een chatgesprek | J | Y | N |
| Chatthreads ophalen | J | J | J |
| Chatthread ophalen met id | J | J | J |
| ReadReceipt ophalen | J | J | J |
| ReadReceipt maken | J | J | J |
| Bericht maken voor chatthread met id | J | J | J |
| Bericht ophalen met bericht-id | J | J | J |
| Uw eigen bericht bijwerken met bericht-id | J | J | J |
| Uw eigen bericht verwijderen met bericht-id | J | J | J |
| Indicator voor typen verzenden | J | J | J |
| Deelnemer ophalen voor thread-id | J | J | J |
VoIP-tokenbereiken
Er worden twee typen VoIP-tokenbereiken ondersteund. Machtigingen voor elk token worden hieronder beschreven.
- Voip
- voip.join
| Mogelijkheid/tokenbereik | Voip | voip.join |
|---|---|---|
| Een VoIP-oproep starten | J | N |
| Start een VoIP-aanroep in virtuele ruimten wanneer de gebruiker al is uitgenodigd voor de ruimte | J | J |
| Deelnemen aan een InProgress VoIP-aanroep | J | J |
| Deelnemen aan een InProgress VoIP-aanroep in virtuele ruimten wanneer de gebruiker al is uitgenodigd voor de ruimte | J | J |
| Alle andere aanroepbewerkingen, zoals dempen/dempen opheffen, schermshare, enzovoort. | J | J |
| Alle andere aanroepbewerkingen, zoals dempen/dempen opheffen, schermshare, enzovoort in virtuele ruimten | Bepaald door de gebruikersrol | Bepaald door de gebruikersrol |
Toegangstoken intrekken of bijwerken
- Azure Communication Services Identity-bibliotheek kan worden gebruikt om een toegangstoken in te trekken vóór de verlooptijd. Het intrekken van tokens is niet onmiddellijk. Het kan tot 15 minuten duren voordat het is doorgegeven.
- Als u een identiteit, resource of abonnement verwijdert, worden alle toegangstokens ingetrokken.
- Als u de mogelijkheid van een gebruiker om toegang te krijgen tot specifieke functionaliteit wilt verwijderen, trekt u alle toegangstokens in. Geef vervolgens een nieuw toegangstoken met een beperktere set bereiken.
- Bij rotatie van toegangssleutels worden alle actieve toegangstokens ingetrokken die zijn gemaakt met behulp van een voormalige toegangssleutel. In dit geval verliezen alle identiteiten de toegang tot Azure Communication Services en moeten ze nieuwe toegangstokens uitgeven.
Overwegingen
- U wordt aangeraden toegangstokens uit te geven in de service aan de serverzijde en niet in de clienttoepassing. De redenering is dat voor het uitgeven een toegangssleutel of Microsoft Entra-verificatie is vereist. Het delen van geheimen met de toepassing van de client wordt niet aanbevolen om veiligheidsredenen.
- Clienttoepassing moet een vertrouwd service-eindpunt gebruiken waarmee clients kunnen worden geverifieerd. Het eindpunt moet namens hen toegangstokens uitgeven. Zie Client- en serverarchitectuur voor meer informatie.
- Als u toegangstokens in de cache opslaat in een back-uparchief, raden we u aan versleuteling te gebruiken. Een toegangstoken is gevoelige gegevens. Deze kan worden gebruikt voor schadelijke activiteiten als deze niet is beveiligd. Iemand met een toegangstoken kan de SDK starten en toegang krijgen tot de API. De toegankelijke API is alleen beperkt op basis van de bereiken die het toegangstoken heeft.
- U wordt aangeraden toegangstokens uit te geven die alleen de vereiste bereiken hebben.
Volgende stappen
- Zie Toegangstokens maken en beheren voor een inleiding tot toegangstokens.
- Zie Verifiëren bij Azure Communication Services voor een inleiding tot verificatie.
- Zie Beschikbaarheid en gegevenslocatie van regio's voor een inleiding tot gegevenslocatie en privacy.
- Zie de quickstart voor het maken van identiteiten om snel identiteiten te maken voor testen.