Identiteitsmodel

Azure Communication Services is een identiteitsagnostische service, die meerdere voordelen biedt:

• Gebruik een BYOI-model (Bring Your Own Identity), zodat u bestaande identiteiten uit uw identiteitsbeheersysteem opnieuw kunt gebruiken en deze kunt toewijzen aan Azure Communication Services-identiteiten.
• Werkt goed met elk bestaand identiteitssysteem en heeft geen afhankelijkheid van een specifieke id-provider.
• Bewaar de gegevens van uw gebruiker, zoals hun naam, privé omdat u deze niet hoeft te dupliceren in Azure Communication Services.
• Organisaties die Gebruikmaken van Microsoft Entra ID voor identiteits- en toegangsbeheer hebben nu rechtstreeks toegang tot Azure Communication Services-resources met Entra ID-gebruikers. Deze nieuwe ondersteuning voor Entra ID-verificatie elimineert de noodzaak om uw eigen identiteitsbeheer of autorisatieproxyservice te ontwikkelen of te gebruiken. Deze functie is momenteel beschikbaar als openbare preview.

Azure Communication Services-identiteitsmodel werkt met twee belangrijke concepten.

Bring Your Own Identity (BYOI): Integreren met uw identiteitsbeheersysteem

Azure Communication Services ondersteunt een BYOI-model (Bring Your Own Identity), waarmee u kunt integreren met uw bestaande identiteitsbeheersysteem. U kunt gebruikersidentiteiten maken in Azure Communication Services en deze toewijzen aan uw eigen gebruikersidentiteitssysteem. Met deze aanpak kunt u gebruikersidentiteiten en toegangstokens beheren zonder gebruikersgegevens in Azure Communication Services te dupliceren.

In de volgende secties wordt u begeleid bij de belangrijkste concepten van het BYOI-model (Bring Your Own Identity):

• Identiteitsmapping voor gebruikers: Mapping van gebruikersidentiteiten in het Bring Your Own Identity (BYOI)-model.
• Toegangstokens maken en beheren: Toegangstokens.
• Een clientserverarchitectuur implementeren voor identiteitsbeheer: Client-serverarchitectuur voor het BYOI-model (Bring Your Own Identity).

Gebruikersidentiteitstoewijzing in het BYOI-model (Bring Your Own Identity)

Wanneer u een gebruikersidentiteit maakt via SDK of REST API, maakt Azure Communication Services een unieke gebruikers-id. U kunt geen externe id's gebruiken, zoals telefoonnummers, gebruikers-/apparaat-/toepassings-id's of gebruikersnamen rechtstreeks in Azure Communication Services. In plaats daarvan moet u de Communication Services-identiteiten gebruiken en zo nodig een koppeling naar uw eigen gebruikers-ID-systeem onderhouden.

U kunt gratis azure Communication Service-gebruikersidentiteiten maken. De enige kosten worden gemaakt wanneer de gebruiker communicatieservices gebruikt, zoals een chatgesprek of een gesprek. Hoe u uw gegenereerde Communication Services-identiteit gebruikt, is afhankelijk van uw scenario. U kunt bijvoorbeeld een identiteit toewijzen 1:1, 1:N, N:1 of N:N, en u kunt deze gebruiken voor menselijke gebruikers of toepassingen. Uw eindgebruiker kan tegelijkertijd deelnemen aan meerdere communicatiesessies, met meerdere apparaten.

Het beheren van een toewijzing tussen azure Communication Services-gebruikersidentiteiten en uw eigen identiteitssysteem is uw verantwoordelijkheid als ontwikkelaar en is niet ingebouwd. U kunt bijvoorbeeld een CommunicationServicesId kolom toevoegen in uw bestaande gebruikerstabel om de bijbehorende Azure Communication Services-identiteit op te slaan. Een toewijzingsontwerp wordt uitgebreid beschreven onder Client-serverarchitectuur voor het BYOI-model (Bring Your Own Identity).

(Preview) Vereenvoudig identiteitstoewijzing met customId

Important

Deze functie is beschikbaar vanaf de Identity SDK-versie 1.4.0-beta1 en REST API-versie 2025-03-02-preview.

Note

Deze functie is momenteel beschikbaar als preview-versie.

Voorheen waren ontwikkelaars verantwoordelijk voor het onderhouden van een koppeling tussen hun eigen gebruikersidentiteitssysteem en de identiteiten van Azure Communication Services. Met de introductie van de customId parameter kunt u nu uw eigen gebruikers-id's, zoals e-mailadressen of interne gebruikers-id's, rechtstreeks koppelen bij het maken van een Communication Services-identiteit.

Wanneer u een gebruiker maakt met een customId, retourneert Azure Communication Services dezelfde identiteit als u de methode opnieuw aanroept met hetzelfde customId. Hierdoor hoeft u niet zelf de toewijzing op te slaan en te beheren.

Deze functie wordt ondersteund in zowel de SDK als de REST API, en is vooral handig voor scenario's waarin u een consistente identiteit wilt behouden voor sessies, apparaten of services zonder extra opslagoverhead.

Toegangstokens

Nadat u een gebruikersidentiteit hebt gemaakt, heeft de eindgebruiker vervolgens een toegangstoken met specifieke bereiken nodig om deel te nemen aan communicatie via chat of gesprekken. Zo kan alleen een gebruiker met een token van chat het bereik deelnemen aan een chatsessie. Alleen een gebruiker met een token van voip het bereik kan deelnemen aan een VoIP-aanroep.

Een gebruiker kan meerdere tokens tegelijk hebben. Azure Communication Services ondersteunt meerdere tokenbereiken om rekening te houden met gebruikers die volledige toegang en beperkte toegang nodig hebben. Toegangstokens hebben de volgende eigenschappen.

Property	Description
Subject	De gebruikersidentiteit die wordt vertegenwoordigd door het token.
Expiration	Een toegangstoken is minimaal 1 uur en maximaal 24 uur geldig. Nadat het is verlopen, is het toegangstoken ongeldig en kan het niet worden gebruikt voor toegang tot de service. Als u een token met een aangepaste verlooptijd wilt maken, geeft u de gewenste geldigheid op in minuten (>=60, <1440). Het token is standaard 24 uur geldig. We raden u aan om tokens voor korte levensduur te gebruiken voor individuele vergaderingen en tokens voor langere levensduur voor gebruikers die uw toepassing gedurende langere tijd nodig hebben.
Scopes	De reikwijdten bepalen welke services (Chat/VoIP) toegankelijk zijn met het token.

Een toegangstoken is een JSON Web Token (JWT) en heeft integriteitsbeveiliging. Dat wil zeggen dat de claims niet kunnen worden gewijzigd zonder het toegangstoken ongeldig te maken, omdat de tokenhandtekening niet meer overeenkomt. Als communicatieprimitieven worden gebruikt met ongeldige tokens, wordt de toegang geweigerd. Hoewel tokens niet zijn versleuteld of verborgen, mag uw toepassing niet afhankelijk zijn van de tokenindeling of de bijbehorende claims. De tokenindeling kan worden gewijzigd en maakt geen deel uit van het officiële API-contract. Azure Communication Services ondersteunt de volgende bereiken voor toegangstokens.

Bereiken van chattoken

Het identiteitsmodel ondersteunt drie verschillende bereiksopties voor chat-token. Machtigingen voor elk bereik worden beschreven in de volgende tabel.

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

Mogelijkheid/tokenbereik	chat	chat.join	chat.join.limited
Chatthread maken	Y	N	N
Chatthread bijwerken met id	Y	N	N
Verwijder chatgesprek met ID	Y	N	N
Deelnemer toevoegen aan een chatgesprek	Y	Y	N
Deelnemer verwijderen uit een chatgesprek	Y	Y	N
Chatdraadjes ophalen	Y	Y	Y
Chatdraad ophalen met ID	Y	Y	Y
ReadReceipt ophalen	Y	Y	Y
ReadReceipt maken	Y	Y	Y
Maak bericht voor de chat-thread met ID	Y	Y	Y
Bericht ophalen met bericht-ID	Y	Y	Y
Uw eigen bericht bijwerken met bericht-id	Y	Y	Y
Uw eigen bericht verwijderen met bericht-id	Y	Y	Y
Typindicatie verzenden	Y	Y	Y
Deelnemer ophalen voor thread-id	Y	Y	Y

VoIP-tokenbereiken

Het identiteitsmodel ondersteunt twee VoIP-tokenbereiken. Machtigingen voor elk bereik worden beschreven in de volgende tabel.

• voip
• voip.join

Mogelijkheid/tokenbereik	voip	voip.join
Een VoIP-oproep starten	Y	N
Start een VoIP-aanroep in virtuele ruimten wanneer de gebruiker al is uitgenodigd voor de ruimte	Y	Y
Deelnemen aan een InProgress VoIP-aanroep	Y	Y
Deelnemen aan een InProgress VoIP-aanroep in virtuele ruimten wanneer de gebruiker al is uitgenodigd voor de ruimte	Y	Y
Alle andere aanroepbewerkingen, zoals dempen/dempen opheffen, schermshare, enzovoort	Y	Y
Alle andere aanroepbewerkingen, zoals dempen/dempen opheffen, schermshare, enzovoort, in virtuele ruimten	Bepaald door de gebruikersrol	Bepaald door de gebruikersrol

U kunt het voip.join bereik samen met Ruimten gebruiken om een gepland gesprek te maken. In dit scenario krijgen alleen uitgenodigde gebruikers toegang en kunnen gebruikers geen andere oproepen maken.

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 tot specifieke functionaliteit wilt verwijderen, trekt u alle toegangstokens voor de gebruiker in. Geef vervolgens een nieuw toegangstoken uit met een beperktere set scopes.
• Bij rotatie van toegangssleutels worden alle actieve toegangstokens ingetrokken die zijn gemaakt met behulp van een voormalige toegangssleutel. Alle identiteiten hebben dus geen toegang meer tot Azure Communication Services en hebben nieuwe toegangstokens nodig.

Client-serverarchitectuur voor het BYOI-model (Bring Your Own Identity)

Maak en beheer tokens voor gebruikerstoegang via een vertrouwde service en maak geen tokens in uw clienttoepassing. U hebt de verbindingsreeks- of Microsoft Entra-referenties nodig om tokens voor gebruikerstoegang te maken. Vergeet niet om de referenties te beveiligen; als je ze aan een cliënt zou doorgeven, loop je het risico het geheim te lekken. Als u geen toegangstokens goed beheert, kunnen er extra kosten in rekening worden gebracht voor uw resource wanneer tokens vrijelijk worden gebruikt en misbruikt door iemand anders.

Als u toegangstokens in de cache opslaat in een back-uparchief, raden we u aan de tokens te versleutelen. Een toegangstoken biedt toegang tot gevoelige gegevens en kan worden gebruikt voor schadelijke activiteiten als het niet is beveiligd. Iedereen met het toegangstoken van een gebruiker heeft toegang tot de chatgegevens van die gebruiker of kan deelnemen aan oproepen die de gebruiker imiteren.

Zorg ervoor dat u alleen die scopes opneemt in het token die uw client-applicatie nodig heeft om het beveiligingsprincipe van minimale bevoegdheden te volgen.

1. Een gebruiker start de clienttoepassing.
2. De clienttoepassing neemt contact op met uw identiteitsbeheerservice.
3. De identiteitsbeheerservice verifieert de toepassingsgebruiker. U kunt verificatie overslaan voor scenario's waarin de gebruiker anoniem is, maar wees voorzichtig met het toevoegen van andere beschermende maatregelen, zoals beperking en CORS aan uw service om tokenmisbruik te beperken.
4. Maak of zoek een Communication Services-identiteit voor de gebruiker.
   1. Scenario voor stabiele identiteit: Uw identiteitsbeheerservice onderhoudt een koppeling tussen toepassings-id's en communicatiediensten-identiteiten. (Toepassingsidentiteiten omvatten uw gebruikers en andere adresseerbare objecten, zoals services of bots.) Als de toepassingsidentiteit nieuw is, wordt er een nieuwe communicatie-identiteit gemaakt en wordt er een toewijzing opgeslagen.
   2. Kortstondige identiteitsscenario: De identiteitsbeheerservice maakt een nieuwe communicatie-identiteit. In dit scenario eindigt dezelfde gebruiker met een andere communicatie-identiteit voor elke sessie.
5. De identiteitsbeheerservice geeft een gebruikerstoegangstoken voor de toepasselijke identiteit uit en retourneert het naar de clienttoepassing.

Azure-app Service of Azure Functions zijn twee alternatieven voor het uitvoeren van de identiteitsbeheerservice. Deze services kunnen eenvoudig worden geschaald en beschikken over ingebouwde functies om gebruikers te verifiëren . Ze zijn geïntegreerd met OpenID en id-providers van derden, zoals Facebook.

Microsoft Entra-id: Integreren met Entra-id

Important

Deze functie van Azure Communication Services is momenteel beschikbaar als preview-versie. Functies in preview zijn openbaar beschikbaar en kunnen worden gebruikt door alle nieuwe en bestaande Microsoft-klanten.

Preview-API's en SDK's worden geleverd zonder een serviceniveau-overeenkomst. U wordt aangeraden deze niet te gebruiken voor productieworkloads. Bepaalde functies worden mogelijk niet ondersteund of mogelijkheden zijn mogelijk beperkt.

Voor meer informatie, zie Aanvullende Gebruiksvoorwaarden voor Microsoft Azure Previews.

Azure Communication Services biedt nu ondersteuning voor Microsoft Entra ID-verificatie, zodat u rechtstreeks toegang hebt tot Azure Communication Services-resources met Entra ID-gebruikers. Deze nieuwe ondersteuning voor Entra ID-verificatie elimineert de noodzaak om uw eigen identiteitsbeheer of autorisatieproxyservice te ontwikkelen of te gebruiken die wordt vermeld in de sectie Client-serverarchitectuur.

In de volgende secties wordt u begeleid bij de essentiële aspecten van microsoft Entra ID-integratie:

• Toegangstokens verkrijgen en beheren: Toegangstokens met Microsoft Entra-id.
• Een clientarchitectuur implementeren met Microsoft Entra ID: Clientarchitectuur voor de Microsoft Entra-id.
• Huidige beperkingen en aanbevolen richtlijnen: beperkingen.

Toegangstokens met Microsoft Entra-id

Alleen Azure Communication Services-toegangstokens worden ondersteund voor verificatie en autorisatie in Azure Communication Services, inclusief chat- en gespreksfuncties. Zie Toegangstokens voor meer informatie over tokenstructuur en -beheer. Tijdens de openbare preview van Microsoft Entra ID worden alleen toegangstokenbereiken (VoIP) ondersteund via entra-id-integratie.

Met Microsoft Entra ID-integratie verifieert u gebruikers via Entra ID, verkrijgt u een Entra ID-toegangstoken voor gebruikers met API-machtigingen voor de toepassing Azure Communication Services-clients en wisselt u het uit voor een Azure Communication Services-toegangstoken. De algemene SDK's van Azure Communication Services bieden naadloze verificatie door automatisch een Azure Communication Services-toegangstoken voor entra ID-gebruiker te verkrijgen. Zie Toegangstokens verkrijgen voor Microsoft Entra ID-gebruikers voor meer informatie over het implementeren van de logica met de Algemene SDK van Azure Communication Services

De API-machtigingen voor de toepassing Azure Communication Services-clients worden consistent benoemd met de azure Communication Services-toegangstokenbereiken die worden beschreven in de secties Chattokenbereiken en VoIP-tokenbereiken. In de volgende tabel wordt de toewijzing tussen API-machtigingen en de scopes van het toegangstoken weergegeven.

Important

API-machtigingen voor chat (berichten) (Chat, Chat.Join, Chat.Join.Limited) worden nog niet ondersteund via Microsoft Entra-id in de openbare preview. Voorlopig zijn alleen voIP-gerelateerde machtigingen (VoIP, VoIP.Join) beschikbaar. Chatondersteuning is gepland voor een toekomstige update.

Api-machtiging voor Azure Communication Services-clients	Bereik van toegangstoken van Azure Communication Services
Chat (Openbare preview Entra ID: alleen VoIP - chat komt binnenkort)	chat
Chat.Join (Openbare preview Entra ID: alleen VoIP, chat komt eraan)	chat.join
Chat.Join.Limited (Entra ID openbare preview: alleen VoIP, chat binnenkort beschikbaar)	chat.join.limited
VoIP	voip
VoIP.Join	voip.join

Azure Communication Services-toegangstokens worden uitgegeven met dezelfde vervaldatum als het toegangstoken voor gebruikers van Microsoft Entra ID.

Clientarchitectuur voor Microsoft Entra-id

Met Microsoft Entra ID-integratie kunt u uw architectuur vereenvoudigen door rechtstreeks entra-id te gebruiken voor verificatie en autorisatie. In de volgende stappen wordt het proces beschreven:

1. Een gebruiker start de clienttoepassing.
2. De clienttoepassing verifieert de gebruiker via Microsoft Entra ID. De clientapplicatie verkrijgt een Entra ID-gebruikerstoegangstoken met API-machtigingen voor de Azure Communication Services Clients-applicatie.
3. De clienttoepassing verkrijgt een Azure Communication Services-toegangstoken voor Entra ID-gebruiker met een van de volgende methoden:
   • Met behulp van de algemene SDK's van Azure Communication Services: de client initialiseert de CommunicationTokenCredential met de referentieopties voor entra-id-tokens, die automatisch het verkrijgen van een Azure Communication Services-toegangstoken voor entra-id-gebruiker op de achtergrond afhandelt. De toepassing gebruikt deze referentie vervolgens voor toegang tot Azure Communication Services-API's.
   • Aangepaste implementatie: de clienttoepassing roept het Exchange Entra ID-token aan voor de API voor het toegangstoken van Azure Communication Services om een Azure Communication Services-toegangstoken te verkrijgen. Het resulterende Azure Communication Services-toegangstoken wordt vervolgens gebruikt voor toegang tot Azure Communication Services-API's.

Deze architectuur elimineert de noodzaak van een afzonderlijke identiteitsbeheerservice, omdat Microsoft Entra ID gebruikersverificatie en autorisatie rechtstreeks afhandelt.

Beperkingen

De integratie van Microsoft Entra ID is momenteel in preview en heeft de volgende beperkingen:

• Continue toegangsevaluatie is niet beschikbaar. Als u toegangstokens onmiddellijk wilt intrekken, volgt u de instructies in Toegangstokens intrekken.
• Als u een Entra ID-gebruiker verwijdert, worden niet automatisch alle gekoppelde gegevens uit de Communication Services-resource verwijderd. Volg de instructies in Een identiteit verwijderen om ervoor te zorgen dat alle gegevens worden verwijderd.
• API-machtigingen voor chatten (Chat, Chat.Join, , Chat.Join.Limited) kunnen niet worden verleend of gebruikt via Microsoft Entra ID-integratie in de openbare preview. Alleen voIP-gerelateerde machtigingen (VoIP, VoIP.Join) worden ondersteund. Gebruik het BYOI-identiteitsmodel om toegangstokens voor chats te verkrijgen totdat GA is bereikt.

Volgende stappen

• Als u tokens wilt uitgeven, raadpleegt u Toegangstokens maken en beheren voor eindgebruikers.
• Zie Verifiëren bij Azure Communication Services voor een inleiding tot verificatie.
• Raadpleeg Tenancy in Microsoft Entra ID voor meer informatie over de werking van verificatie in scenario's met één tenant en multitenant Microsoft Entra ID.
• Voor een quickstart over het verifiëren van Microsoft Entra ID-gebruikers, zie Microsoft Entra ID-gebruikers verifiëren.
• Zie Beschikbaarheid en gegevenslocatie van regio's voor meer informatie over gegevenslocatie en privacy.
• Voor een volledig voorbeeld van een eenvoudige identiteitsbeheerservice, zie Zelfstudie voor Trusted service.
• Zie het hero-voorbeeld van de verificatieservice voor een geavanceerdere voorbeeld van identiteitsbeheer dat kan worden geïntegreerd met Entra ID en Microsoft Graph.