Identitetsmodell
Azure Communication Services är en identitetsagnostisk tjänst som erbjuder flera fördelar:
- Återanvänd befintliga identiteter från ditt identitetshanteringssystem och mappa dem med Azure Communication Services-identiteter.
- Fungerar bra med alla befintliga identitetssystem och har inget beroende av en specifik identitetsprovider.
- Håll användarens data, till exempel deras namn, privata eftersom du inte behöver duplicera dem i Azure Communication Services.
Identitetsmodellen för Azure Communication Services fungerar med två viktiga begrepp.
Användaridentitet/mappning
När du skapar en användaridentitet via SDK eller REST API skapar Azure Communication Services en unik användaridentifierare. Externa identifierare som telefonnummer, användar-/enhets-/program-ID:n eller användarnamn kan inte användas direkt i Azure Communication Services. I stället måste du använda kommunikationstjänsternas identiteter och underhålla en mappning till ditt eget användar-ID-system efter behov. Det är kostnadsfritt att skapa användaridentiteter i Azure Communication Service och avgifter tillkommer endast när användaren använder kommunikationsmodaliteter som chatt eller samtal. Hur du använder din genererade Communication Services-identitet beror på ditt scenario. Du kan till exempel mappa en identitet 1:1, 1:N, N:1 eller N:N, och du kan använda den för mänskliga användare eller program. En användare kan delta i flera kommunikationssessioner med flera enheter samtidigt. Att hantera en mappning mellan Azure Communication Services-användaridentiteter och ditt eget identitetssystem är ditt ansvar som utvecklare och kommer inte inbyggt. Du kan till exempel lägga till en CommunicationServicesId kolumn i din befintliga användartabell för att lagra den associerade Azure Communication Services-identiteten. En mappningsdesign beskrivs mer detaljerat under Klient-server-arkitektur.
Åtkomsttokens
När en användaridentitet har skapats behöver en användare sedan en åtkomsttoken med specifika omfång för att delta i kommunikation med hjälp av chatt eller samtal. Till exempel kan endast en användare med en token med omfånget chat delta i chatten och en användare med en token med voip omfång kan delta i ett VoIP-anrop. En användare kan ha flera token samtidigt. Azure Communication Services har stöd för flera tokenomfattningar för att ta hänsyn till användare som behöver fullständig åtkomst jämfört med begränsad åtkomst. Åtkomsttoken har följande egenskaper.
| Property | beskrivning |
|---|---|
| Ämne | Användaridentiteten som representeras av token. |
| Förfallodatum | En åtkomsttoken är giltig i minst 1 timme och upp till 24 timmar. När den har upphört att gälla är åtkomsttoken ogiltig och kan inte användas för att komma åt tjänsten. Om du vill skapa en token med en anpassad förfallotid anger du önskad giltighet i minuter (>=60, <1440). Som standard är token giltig i 24 timmar. Vi rekommenderar att du använder korta livstidstoken för engångsmöten och längre livslängdstoken för användare som använder ditt program under längre tidsperioder. |
| Omfattningar | Omfången definierar vilka kommunikationspri primitiver (Chat/VoIP) som kan nås med token. |
En åtkomsttoken är en JSON-webbtoken (JWT) och har integritetsskydd. Dess anspråk kan alltså inte ändras utan att åtkomsttoken ogiltigförklaras eftersom tokensignaturen inte längre matchar. Om kommunikationspri primitiver används med ogiltiga token nekas åtkomst. Även om token inte är krypterade eller fördunklade bör ditt program inte vara beroende av tokenformatet eller dess anspråk. Tokenformatet kan ändras och ingår inte i det officiella API-kontraktet. Azure Communication Services stöder följande omfång för åtkomsttoken.
Omfång för chatttoken
Tre olika omfång för chatttoken stöds. Behörigheter för varje omfång beskrivs i följande tabell.
chatchat.joinchat.join.limited
| Kapacitet/tokenomfång | chatt | chat.join | chat.join.limited |
|---|---|---|---|
| Skapa chatttråd | Y | N | N |
| Uppdatera chatttråd med ID | Y | N | N |
| Ta bort chatttråd med ID | Y | N | N |
| Lägga till deltagare i en chatttråd | Y | Y | N |
| Ta bort deltagare från en chatttråd | Y | Y | N |
| Hämta chatttrådar | Y | Y | Y |
| Hämta chatttråd med ID | Y | Y | Y |
| Hämta ReadReceipt | Y | Y | Y |
| Skapa ReadReceipt | Y | Y | Y |
| Skapa meddelande för chatttråd med ID | Y | Y | Y |
| Hämta meddelande med meddelande-ID | Y | Y | Y |
| Uppdatera ditt eget meddelande med meddelande-ID | Y | Y | Y |
| Ta bort ditt eget meddelande med meddelande-ID | Y | Y | Y |
| Indikator för att skicka inmatning | Y | Y | Y |
| Hämta deltagare för tråd-ID | Y | Y | Y |
Omfång för VoIP-token
Två VoIP-tokenomfång stöds. Behörigheter för varje omfång beskrivs i följande tabell.
voipvoip.join
| Kapacitet/tokenomfång | voip | voip.join |
|---|---|---|
| Starta ett VoIP-anrop | Y | N |
| Starta ett VoIP-samtal i virtuella rum när användaren redan är inbjuden till rummet | Y | Y |
| Ansluta till ett InProgress VoIP-anrop | Y | Y |
| Anslut till ett InProgress VoIP-anrop i virtuella rum när användaren redan är inbjuden till rummet | Y | Y |
| Alla andra anropsåtgärder som att stänga av/slå på ljudet, skärmresurs osv. | Y | Y |
| Alla andra anropsåtgärder som att stänga av/slå på ljudet, skärmresurs osv. i virtuella rum | Bestäms av användarroll | Bestäms av användarroll |
Du kan använda omfånget voip.join tillsammans med Rum för att skapa ett schemalagt samtal där endast inbjudna användare får åtkomst och där användare inte kan skapa andra samtal.
Återkalla eller uppdatera åtkomsttoken
- Identitetsbiblioteket för Azure Communication Services kan användas för att återkalla en åtkomsttoken innan den upphör att gälla. Tokenåterkallelse är inte omedelbart. Det kan ta upp till 15 minuter att sprida.
- Borttagningen av en identitet, resurs eller prenumeration återkallar alla åtkomsttoken.
- Om du vill ta bort en användares möjlighet att komma åt specifika funktioner återkallar du alla åtkomsttoken för användaren. Utfärda sedan en ny åtkomsttoken som har en mer begränsad uppsättning omfång.
- Rotation av åtkomstnycklar återkallar alla aktiva åtkomsttoken som skapades med hjälp av en tidigare åtkomstnyckel. Därför förlorar alla identiteter åtkomsten till Azure Communication Services och behöver nya åtkomsttoken.
Klientserverarkitektur
Du bör skapa och hantera användaråtkomsttoken via en betrodd tjänst och inte skapa token i klientprogrammet. De anslutningssträng- eller Microsoft Entra-autentiseringsuppgifter som krävs för att skapa användaråtkomsttoken måste skyddas. Om du skickar dem till en klient riskerar det att läcka hemligheten. Om du inte hanterar åtkomsttoken korrekt kan det leda till extra avgifter för din resurs när token delas ut fritt och missbrukas av någon annan.
Om du cachelagrar åtkomsttoken till ett lagringsplats rekommenderar vi att du krypterar token. En åtkomsttoken ger åtkomst till känsliga data och kan användas för skadlig aktivitet om den inte är skyddad. Alla med en användares åtkomsttoken kan komma åt användarens chattdata eller delta i samtal som personifierar användaren.
Se till att endast inkludera dessa omfång i den token som klientprogrammet behöver för att följa säkerhetsprincipen för lägsta behörighet.
- En användare startar klientprogrammet.
- Klientprogrammet kontaktar din identitetshanteringstjänst.
- Identitetshanteringstjänsten autentiserar programanvändaren. Du kan hoppa över autentisering för scenarier där användaren är anonym, men var noga med att sedan lägga till andra skyddsåtgärder, till exempel begränsning och CORS i tjänsten för att minimera tokenmissbruk.
- Skapa eller hitta en Communication Services-identitet för användaren.
- Stabilt identitetsscenario: Identitetshanteringstjänsten upprätthåller en mappning mellan programidentiteter och Kommunikationstjänsters identiteter. (Programidentiteter omfattar dina användare och andra adresserbara objekt, till exempel tjänster eller robotar.) Om programidentiteten är ny skapas en ny kommunikationsidentitet och en mappning lagras.
- Tillfälliga identitetsscenarion: Identitetshanteringstjänsten skapar en ny kommunikationsidentitet. I det här scenariot får samma användare en annan kommunikationsidentitet för varje session.
- Identitetshanteringstjänsten utfärdar en användaråtkomsttoken för den tillämpliga identiteten och returnerar den till klientprogrammet.
Azure App Service eller Azure Functions är två alternativ för att hantera identitetshanteringstjänsten. Dessa tjänster skalas enkelt och har inbyggda funktioner för att autentisera användare. De är integrerade med OpenID och identitetsprovidrar från tredje part som Facebook.
Nästa steg
- Information om hur du utfärdar token finns i Skapa och hantera åtkomsttoken.
- En introduktion till autentisering finns i Autentisera till Azure Communication Services.
- Mer information om datahemvist och sekretess finns i Regiontillgänglighet och datahemvist.
- Information om hur du snabbt skapar identiteter och token för testning finns i snabbstarten för att skapa identiteter.
- Ett fullständigt exempel på en enkel identitetshanteringstjänst finns i självstudien Betrodd tjänst.
- Om du vill ha ett mer avancerat exempel på identitetshantering som integreras med Entra-ID och Microsoft Graph går du vidare till hero-exemplet för autentiseringstjänsten.