Identiteitsmodel
Azure Communication Services is een identiteitsagnostische service, die meerdere voordelen biedt:
- Bestaande identiteiten opnieuw gebruiken vanuit uw identiteitsbeheersysteem en deze toewijzen met 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.
Azure Communication Services-identiteitsmodel werkt met twee belangrijke concepten.
Gebruikersidentiteit/toewijzing
Wanneer u een gebruikersidentiteit maakt via SDK of REST API, maakt Azure Communication Services een unieke gebruikers-id. Externe id's, zoals telefoonnummers, gebruikers-/apparaat-/toepassings-id's of gebruikersnamen, kunnen niet rechtstreeks in Azure Communication Services worden gebruikt. In plaats daarvan moet u de Communication Services-identiteiten gebruiken en zo nodig een toewijzing aan uw eigen gebruikers-id-systeem onderhouden. Het maken van Azure Communication Service-gebruikersidentiteiten is gratis en er worden alleen kosten in rekening gebracht wanneer de gebruiker communicatiemodaliteiten 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. Een gebruiker kan deelnemen aan meerdere communicatiesessies, met meerdere apparaten tegelijk. 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 gedetailleerder beschreven onder client-serverarchitectuur.
Toegangstokens
Nadat een gebruikersidentiteit is gemaakt, heeft een gebruiker 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 met het chat bereik deelnemen aan chat en kan een gebruiker met een token met voip een bereik deelnemen aan een VoIP-oproep. 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.
| Eigenschappen | Beschrijving |
|---|---|
| Onderwerp | De gebruikersidentiteit die wordt vertegenwoordigd door het token. |
| Verloop | 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 korte levensduurtokens te gebruiken voor eenmalige vergaderingen en langere levensduurtokens voor gebruikers die uw toepassing gedurende langere tijd gebruiken. |
| Bereiken | De bereiken bepalen welke communicatieprimitief (Chat/VoIP) toegankelijk is 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
Er worden drie verschillende bereiken voor chattoken ondersteund. Machtigingen voor elk bereik worden beschreven in de volgende tabel.
chatchat.joinchat.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
Twee VoIP-tokenbereiken worden ondersteund. Machtigingen voor elk bereik worden beschreven in de volgende tabel.
voipvoip.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 |
U kunt het voip.join bereik samen met Ruimten gebruiken om een geplande oproep te maken waarbij alleen uitgenodigde gebruikers toegang krijgen en waar gebruikers geen andere oproepen mogen 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.
- Door het verwijderen van een identiteit, resource of abonnement 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 met een beperktere set bereiken.
- Bij rotatie van toegangssleutels worden alle actieve toegangstokens ingetrokken die zijn gemaakt met behulp van een voormalige toegangssleutel. Daarom hebben alle identiteiten geen toegang meer tot Azure Communication Services en hebben ze nieuwe toegangstokens nodig.
Client-serverarchitectuur
U moet tokens voor gebruikerstoegang maken en beheren via een vertrouwde service en geen tokens maken in uw clienttoepassing. De verbindingsreeks- of Microsoft Entra-referenties die nodig zijn om tokens voor gebruikerstoegang te maken, moeten worden beveiligd. Als ze worden doorgegeven aan een client, loopt het risico dat het geheim wordt gelekt. Als u toegangstokens niet goed beheert, kunnen er extra kosten in rekening worden gebracht voor uw resource wanneer tokens vrijelijk worden uitgedeeld en worden 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 bereiken opneemt in het token dat uw clienttoepassing nodig heeft om het beveiligingsprincipe van minimale bevoegdheden te volgen.
- Een gebruiker start de clienttoepassing.
- De clienttoepassing neemt contact op met uw identiteitsbeheerservice.
- 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.
- Maak of zoek een Communication Services-identiteit voor de gebruiker.
- Stabiel identiteitsscenario: uw identiteitsbeheerservice onderhoudt een toewijzing tussen toepassings-id's en Communication Services-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.
- Kortstondige identiteitsscenario: De identiteitsbeheerservice maakt een nieuwe communicatie-identiteit. In dit scenario eindigt dezelfde gebruiker met een andere communicatie-identiteit voor elke sessie.
- 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.
Volgende stappen
- Zie Toegangstokens maken en beheren voor meer informatie over het uitgeven van tokens.
- Zie Verifiëren bij Azure Communication Services voor een inleiding tot verificatie.
- Zie Beschikbaarheid en gegevenslocatie van regio's voor meer informatie over gegevenslocatie en privacy.
- Zie de quickstart voor het maken van identiteiten en tokens voor het testen.
- Voor een volledig voorbeeld van een eenvoudige identiteitsbeheerservice gaat u naar de zelfstudie over vertrouwde services.
- Voor een geavanceerder voorbeeld van identiteitsbeheer dat kan worden geïntegreerd met Entra ID en Microsoft Graph, gaat u naar het hero-voorbeeld van de verificatieservice.