Dela via

Identitetsmodell

Azure Communication Services är en identitetsagnostisk tjänst som erbjuder flera fördelar:

  • Anta en BYOI-modell (Bring Your Own Identity) så att du kan återanvända 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.
  • Organisationer som använder Microsoft Entra-ID för identitets- och åtkomsthantering kan nu komma åt Azure Communication Services-resurser direkt med Entra-ID-användare. Det här nya stödet för Entra ID-autentisering eliminerar behovet av att utveckla eller använda din egen identitetshanterings- eller auktoriseringsproxytjänst. Den här funktionen är för närvarande i offentlig förhandsversion.

Identitetsmodellen för Azure Communication Services fungerar med två viktiga begrepp.

Byoi (Bring Your Own Identity): Integrera med ditt identitetshanteringssystem

Azure Communication Services stöder en BYOI-modell (Bring Your Own Identity) som gör att du kan integrera med ditt befintliga identitetshanteringssystem. Du kan skapa användaridentiteter i Azure Communication Services och mappa dem till ditt eget användaridentitetssystem. Med den här metoden kan du hantera användaridentiteter och åtkomsttoken utan att duplicera användardata i Azure Communication Services.

Följande avsnitt vägleder dig genom huvudbegreppen i BYOI-modellen (Bring Your Own IDENTITY):

Mappning av användaridentitet i BYOI-modellen (Bring Your Own Identity)

När du skapar en användaridentitet via SDK eller REST API skapar Azure Communication Services en unik användaridentifierare. Du kan inte använda externa identifierare som telefonnummer, användar-/enhets-/program-ID:n eller användarnamn 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.

Du kan skapa användaridentiteter för Azure Communication Service kostnadsfritt. De enda avgifterna debiteras när användaren använder kommunikationstjänster, till exempel en chatt eller ett 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. Slutanvändaren 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-arkitekturen för Bring Your Own Identity (BYOI)-modellen.

(Förhandsversion) Förenkla identitetsmappning med customId

Important

Den här funktionen är tillgänglig från och med Identity SDK-versionen 1.4.0-beta1 och REST API-versionen 2025-03-02-preview.

Note

Den här funktionen är för närvarande i förhandsversion.

Tidigare ansvarade utvecklare för att upprätthålla en mappning mellan sina egna användaridentitetssystem och Azure Communication Services-identiteter. Med introduktionen av parametern customId kan du nu associera dina egna användaridentifierare, till exempel e-postadresser eller interna användar-ID:t, direkt när du skapar en Communication Services-identitet.

När du skapar en användare med en customIdreturnerar Azure Communication Services samma identitet om du anropar metoden igen med samma customId. Detta eliminerar behovet av att lagra och hantera mappningen själv.

Den här funktionen stöds i både SDK och REST API och är särskilt användbar för scenarier där du vill upprätthålla en konsekvent identitet mellan sessioner, enheter eller tjänster utan extra lagringsutrymme.

Åtkomsttokens

När du har skapat en användaridentitet behöver slutanvändaren 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 för chat omfång delta i chatten. Endast en användare med en omfångstoken voip 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 Description
Subject Användaridentiteten som representeras av token.
Expiration 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 enskilda möten och längre livstidstoken för användare som behöver ditt program under längre tidsperioder.
Scopes Omfången definierar vilka tjänster (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 kommunikationsprimitiver 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

Identitetsmodellen stöder tre olika omfång för chatttoken. Behörigheter för varje omfång beskrivs i följande tabell.

  • chat
  • chat.join
  • chat.join.limited
Kapacitet/tokenomfång chat 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
Skicka skrivindikator Y Y Y
Hämta deltagare för trådidentifikation Y Y Y

Omfång för VoIP-token

Identitetsmodellen stöder två VoIP-tokenomfång. Behörigheter för varje omfång beskrivs i följande tabell.

  • voip
  • voip.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, exempelvis att stänga av eller aktivera ljudet, skärmdelning och så vidare Y Y
Alla andra anropsåtgärder som att tysta/aktivera ljudet, skärmdelning och så vidare 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 anrop. I det här scenariot får endast inbjudna användare åtkomst och användare får inte skapa andra anrop.

Å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 omedelbar. Det kan ta upp till 15 minuter att sprida.
  • Om du tar bort en identitet, resurs eller prenumeration återkallas 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 med en mer begränsad uppsättning åtkomstområden.
  • Rotation av åtkomstnycklar återkallar alla aktiva åtkomsttoken som skapades med hjälp av en tidigare åtkomstnyckel. Så alla identiteter förlorar åtkomsten till Azure Communication Services och behöver nya åtkomsttoken.

Klientserverarkitektur för BYOI-modellen (Bring Your Own Identity)

Skapa och hantera användaråtkomsttoken via en betrodd tjänst och skapa inte token i klientprogrammet. Du behöver anslutningssträngen eller Microsoft Entra-autentiseringsuppgifterna för att skapa användaråtkomsttoken. Kom ihåg att skydda autentiseringsuppgifterna och att skicka dem till en klient skulle riskera 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 lagringsplatsen rekommenderar vi att du krypterar tokenen. 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 det token som klientprogrammet behöver för att följa säkerhetsprincipen för minsta möjliga behörighet.

Diagram som visar arkitekturen för användaråtkomsttoken.

  1. En användare startar klientprogrammet.
  2. Klientprogrammet kontaktar din identitetshanteringstjänst.
  3. 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.
  4. Skapa eller hitta en Communication Services-identitet för användaren.
    1. 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.
    2. 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.
  5. 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