Model identit

Azure Communication Services je služba nezávislá na identitě, která nabízí několik výhod:

• Osvojte si model přineste si vlastní identitu (BYOI), který umožňuje opakovaně používat existující identity ze systému správy identit a mapovat je s identitami Azure Communication Services.
• Funguje dobře s jakýmkoli existujícím systémem identit a nemá žádnou závislost na konkrétním zprostředkovateli identity.
• Udržujte data uživatele, například jeho jméno, soukromá, protože je nemusíte duplikovat ve službě Azure Communication Services.
• Organizace, které používají MICROSOFT Entra ID pro správu identit a přístupu, teď můžou přistupovat k prostředkům Azure Communication Services přímo s uživateli Entra ID. Tato nová podpora ověřování Entra ID eliminuje nutnost vyvíjet nebo provozovat vlastní službu správy identit nebo autorizačního proxy serveru. Tato funkce je aktuálně ve verzi Public Preview.

Model identit azure Communication Services funguje se dvěma klíčovými koncepty.

Přineste si vlastní identitu (BYOI): Integrace se systémem správy identit

Azure Communication Services podporuje model přineste si vlastní identitu (BYOI), který umožňuje integraci se stávajícím systémem správy identit. Ve službě Azure Communication Services můžete vytvářet identity uživatelů a mapovat je na vlastní systém identit uživatelů. Tento přístup umožňuje spravovat identity uživatelů a přístupové tokeny bez duplikování uživatelských dat ve službě Azure Communication Services.

Následující části vás provedou klíčovými koncepty modelu přineste si vlastní identitu (BYOI):

• Mapování identit uživatelů: Mapování identit uživatelů v modelu přineste si vlastní identitu (BYOI).
• Vytváření a správa přístupových tokenů: Přístupové tokeny
• Jak implementovat architekturu klienta-server pro správu identit: Architektura klienta-server pro model přineste si vlastní identitu (BYOI).

Mapování identit uživatelů v modelu Přineste si vlastní identitu (BYOI)

Když vytvoříte identitu uživatele pomocí sady SDK nebo rozhraní REST API, služba Azure Communication Services vytvoří jedinečný identifikátor uživatele. Nemůžete použít externí identifikátory, jako jsou telefonní čísla, ID uživatelů, zařízení nebo aplikací nebo uživatelská jména přímo ve službě Azure Communication Services. Místo toho musíte použít identity komunikačních služeb a podle potřeby udržovat mapování na váš vlastní systém uživatelských identifikátorů.

Identity uživatelů služby Azure Communication Service můžete vytvářet zdarma. Jediné poplatky se účtují, když uživatel využívá komunikační služby, jako je chat nebo hovor. Způsob použití vygenerované identity komunikační služby závisí na vašem scénáři. Můžete například namapovat identitu 1:1, 1:N, N:1 nebo N:N a můžete ji použít pro lidské uživatele nebo aplikace. Koncový uživatel se může účastnit více komunikačních relací pomocí více zařízení současně.

Správa mapování mezi identitami uživatelů Azure Communication Services a vaším vlastním systémem identit je vaší zodpovědností za vývojáře a není integrovaná. Můžete například přidat CommunicationServicesId sloupec ve stávající tabulce uživatele, do které se uloží přidružená identita služby Azure Communication Services. Návrh mapování je podrobněji popsaný v architektuře klientského serveru pro model přineste si vlastní identitu (BYOI).

(Preview) Zjednodušení mapování identit pomocí customId

Important

Tato funkce je dostupná od verze 1.4.0-beta1 sady SDK identity a verze 2025-03-02-previewrozhraní REST API.

Note

Tato funkce je aktuálně dostupná jako ukázková verze.

Dříve byli vývojáři zodpovědní za udržování mapování mezi vlastním systémem identit uživatelů a identitami azure Communication Services. Po zavedení parametru customId teď můžete při vytváření identity komunikační služby přidružit vlastní identifikátory uživatelů, jako jsou e-mailové adresy nebo interní ID uživatelů.

Když vytvoříte uživatele se stejnou identitou customId, služba Azure Communication Services vrátí stejnou identitu, pokud metodu znovu zavoláte se stejným customId. Tím se eliminuje nutnost ukládat a spravovat mapování sami.

Tato funkce je podporovaná v sadě SDK i v rozhraní REST API a je užitečná hlavně pro scénáře, ve kterých chcete zachovat konzistentní identitu napříč relacemi, zařízeními nebo službami bez dalších režijních nákladů na úložiště.

Přístupové tokeny

Po vytvoření identity uživatele potřebuje koncový uživatel přístupový token s konkrétními obory pro účast v komunikaci pomocí chatu nebo volání. Například se chatu může účastnit pouze uživatel, který má token s rozsahem chat. K účasti na VoIP volání může být povolen pouze uživatel s tokenem oboru voip.

Uživatel může mít současně více tokenů. Azure Communication Services podporuje více oborů tokenů, které umožňují zohlednit uživatele, kteří vyžadují úplný přístup a omezený přístup. Přístupové tokeny mají následující vlastnosti.

Property	Description
Subject	Identita uživatele reprezentovaná tokenem.
Expiration	Přístupový token je platný alespoň 1 hodinu a až 24 hodin. Po vypršení platnosti je přístupový token neplatný a nejde ho použít pro přístup ke službě. Pokud chcete vytvořit token s vlastním časem vypršení platnosti, zadejte požadovanou platnost v minutách (>=60, <1440). Ve výchozím nastavení je token platný po dobu 24 hodin. Doporučujeme používat krátké tokeny životnosti pro jednotlivé schůzky a delší životnost tokeny pro uživatele, kteří potřebují vaši aplikaci po delší dobu.
Scopes	Obory definují, ke kterým službám (Chat/VoIP) je možné získat přístup pomocí tokenu.

Přístupový token je webový token JSON (JWT) a má ochranu integrity. To znamená, že jeho deklarace identity nelze změnit bez zneplatnění přístupového tokenu, protože podpis tokenu už neodpovídá. Pokud se primitivy komunikace používají s neplatnými tokeny, přístup se odepře. I když tokeny nejsou šifrované ani nezašifrované, neměla by vaše aplikace záviset na formátu tokenu ani na jeho deklarací identity. Formát tokenu se může změnit a není součástí oficiálního kontraktu rozhraní API. Azure Communication Services podporuje pro přístupové tokeny následující obory.

Obory tokenů chatu

Model identity podporuje tři různé obory tokenů chatu. Oprávnění pro každý obor jsou popsaná v následující tabulce.

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

Možnosti / rozsah tokenů	chat	chat.join	chat.join.limited
Vytvoření vlákna chatu	Y	N	N
Aktualizace vlákna chatu s ID	Y	N	N
Odstraňte vlákno chatu s ID	Y	N	N
Přidání účastníka do vlákna chatu	Y	Y	N
Odebrání účastníka z vlákna chatu	Y	Y	N
Získání vláken chatu	Y	Y	Y
Získejte vlákno chatu s ID	Y	Y	Y
Získat ReadReceipt	Y	Y	Y
Vytvoření readReceipt	Y	Y	Y
Vytvoření zprávy pro vlákno chatu s ID	Y	Y	Y
Získat zprávu s ID zprávy	Y	Y	Y
Aktualizace vlastní zprávy pomocí ID zprávy	Y	Y	Y
Smazat svou vlastní zprávu s ID zprávy	Y	Y	Y
Odeslat indikátor psaní	Y	Y	Y
Získání účastníka pro ID vlákna	Y	Y	Y

Obory tokenů VoIP

Model identity podporuje dva obory tokenů VoIP. Oprávnění pro každý obor jsou popsaná v následující tabulce.

• voip
• voip.join

Možnosti / rozsah tokenů	voip	voip.join
Zahájení volání VoIP	Y	N
Spuštění hovoru VoIP ve virtuálních místnostech, když už je uživatel pozvaný do místnosti	Y	Y
Připojte se k probíhajícímu hovoru VoIP	Y	Y
Připojte se k hovoru VoIP inProgress ve virtuálních místnostech, když už je uživatel pozvaný do místnosti.	Y	Y
Všechny ostatní operace volání, jako je ztlumení nebo zrušení ztlumení, sdílení obrazovky atd.	Y	Y
Veškeré další operace během hovoru, jako ztlumení/aktivace zvuku, sdílení obrazovky atd., ve virtuálních místnostech.	Určeno rolí uživatele	Určeno rolí uživatele

Rozsah voip.join můžete použít společně s místnostmi k vytvoření naplánovaného hovoru. V tomto scénáři mají přístup jenom pozvaní uživatelé a uživatelé nebudou mít možnost vytvářet další volání.

Odvolání nebo aktualizace přístupového tokenu

• Knihovnu identit služby Azure Communication Services je možné použít k odvolání přístupového tokenu před vypršením jeho platnosti. Odvolání tokenu není okamžité. Rozšíření může trvat až 15 minut.
• Odstranění identity, prostředku nebo předplatného odvolá všechny přístupové tokeny.
• Pokud chcete uživateli odebrat možnost přístupu ke konkrétním funkcím, odvolejte všechny přístupové tokeny pro uživatele. Pak vytvořte nový přístupový token, který má omezenější sadu oborů.
• Obměna přístupových klíčů odvolá všechny aktivní přístupové tokeny vytvořené pomocí bývalého přístupového klíče. Všechny identity tak ztratí přístup ke službě Azure Communication Services a potřebují nové přístupové tokeny.

Architektura klientského serveru pro model přineste si vlastní identitu (BYOI)

Vytvářejte a spravujte přístupové tokeny uživatelů prostřednictvím důvěryhodné služby a nevytvořte tokeny v klientské aplikaci. K vytvoření přístupových tokenů uživatele potřebujete připojovací řetězec nebo přihlašovací údaje Microsoft Entra. Nezapomeňte chránit přihlašovací údaje a jejich předání klientovi by riskovalo únik tajného klíče. Nesprávné řízení přístupových tokenů může vést k dodatečným poplatkům za prostředek, pokud jsou tokeny volně vydávány a mohou být zneužity někým jiným.

Pokud do mezipaměti ukládáte přístupové tokeny do záložního úložiště, doporučujeme šifrovat tokeny. Přístupový token poskytuje přístup k citlivým datům a dá se použít pro škodlivou aktivitu, pokud není chráněná. Každý, kdo má přístupový token uživatele, má přístup k datům chatu daného uživatele nebo se může účastnit hovorů, které uživatele zosobní.

Nezapomeňte do tokenu zahrnout pouze ty obory, které vaše klientská aplikace potřebuje, aby dodržovala princip zabezpečení s nejnižšími oprávněními.

1. Uživatel spustí klientskou aplikaci.
2. Klientská aplikace kontaktuje vaši službu správy identit.
3. Služba správy identit ověřuje uživatele aplikace. Můžete přeskočit ověřování pro scénáře, kdy je uživatel anonymní, ale dávejte pozor, abyste do služby přidali další ochranná opatření, jako je omezování frekvence a CORS, aby zmírnila zneužití tokenů.
4. Vytvořte nebo vyhledejte identitu komunikační služby pro uživatele.
   1. Scénář stabilní identity: Služba správy identit udržuje mapování mezi identitami aplikací a identitami komunikačních služeb. (Identity aplikací zahrnují uživatele a další adresovatelné objekty, jako jsou služby nebo roboti.) Pokud je identita aplikace nová, vytvoří se nová komunikační identita a uloží se mapování.
   2. Scénář dočasné identity: Služba pro správu identit vytvoří novou komunikační identitu. V tomto scénáři skončí stejný uživatel s jinou identitou komunikace pro každou relaci.
5. Služba správy identit vydá přístupový token uživatele pro příslušnou identitu a vrátí ho do klientské aplikace.

Aplikace Azure Služba nebo Azure Functions jsou dvě alternativy pro provoz služby správy identit. Tyto služby se snadno škálují a mají integrované funkce pro ověřování uživatelů. Jsou integrované s OpenID a poskytovateli identity třetích stran, jako je Facebook.

Microsoft Entra ID: Integrace s Entra ID

Important

Tato funkce služeb Azure Communication Services je aktuálně ve verzi Preview. Funkce ve verzi Preview jsou veřejně dostupné a můžou je používat všichni noví a stávající zákazníci Microsoftu.

API a sady SDK ve verzi Preview jsou poskytovány bez smlouvy o úrovni služeb. Doporučujeme je nepoužívat pro produkční úlohy. Některé funkce nemusí být podporované nebo můžou být omezené.

Další informace najdete v dodatečných podmínkách použití pro verze Preview v Microsoft Azure.

Služba Azure Communication Services teď podporuje ověřování Microsoft Entra ID, které umožňuje přístup k prostředkům služby Azure Communication Services přímo s uživateli Entra ID. Tato nová podpora ověřování Entra ID eliminuje nutnost vyvíjet nebo provozovat vlastní službu správy identit nebo autorizačního proxy serveru uvedenou v části Architektura klientského serveru.

Následující části vás provedou základními aspekty integrace Microsoft Entra ID:

• Jak získat a spravovat přístupové tokeny: Přístupové tokeny pomocí Microsoft Entra ID.
• Jak implementovat architekturu klienta s Microsoft Entra ID: Architektura klienta pro Microsoft Entra ID.
• Aktuální omezení a doporučené pokyny: Omezení

Přístupové tokeny s ID Microsoft Entra

Ověřování a autorizace ve službě Azure Communication Services, včetně funkcí chatu a volání, se podporují pouze přístupové tokeny Azure Communication Services. Další informace o struktuře a správě tokenů najdete v tématu Přístupové tokeny. Během veřejné verze Public Preview Microsoft Entra ID se podporují pouze rozsahy přístupového tokenu pro volání (VoIP) prostřednictvím integrace Entra ID.

S integrací Microsoft Entra ID ověřujete uživatele prostřednictvím Id Entra, získáte přístupový token uživatele Entra ID s oprávněními rozhraní API pro aplikaci Klienti Azure Communication Services a vyměníte ho za přístupový token služby Azure Communication Services. Běžné sady SDK služby Azure Communication Services nabízejí bezproblémové ověřování tím, že automaticky získávají přístupový token služby Azure Communication Services pro uživatele Entra ID. Další informace o tom, jak implementovat logiku pomocí běžné sady SDK služby Azure Communication Services, najdete v tématu Získání přístupových tokenů pro uživatele Microsoft Entra ID.

Oprávnění rozhraní API pro aplikaci Klienti služby Azure Communication Services jsou pojmenována konzistentně s obory přístupového tokenu služby Azure Communication Services popsanými v částech Rozsahy tokenů chatu a obory tokenů VoIP. Následující tabulka ukazuje mapování mezi oprávněními rozhraní API a obory přístupového tokenu.

Important

Oprávnění rozhraní API pro chat (zasílání zpráv) (Chat, Chat.Join, Chat.Join.Limited) se zatím nepodporují prostřednictvím ID Microsoft Entra ve verzi Public Preview. Prozatím jsou k dispozici pouze oprávnění související s VoIP (VoIP, VoIP.Join). Plánuje se zavedení podpory chatu v budoucí aktualizaci.

Oprávnění klientů rozhraní API služby Azure Communication Services	Obor přístupového tokenu služby Azure Communication Services
Chat (Entra ID Public Preview: Pouze VoIP – připravuje se chat)	chat
Chat.Join (Entra ID veřejná ukázka: Pouze VoIP – připravuje se chat)	chat.join
Chat.Join.Limited (Entra ID veřejný náhled: Pouze VoIP – připravuje se chat)	chat.join.limited
VoIP	voip
VoIP.Join	voip.join

Přístupové tokeny služby Azure Communication Services se vydávají se stejným vypršením platnosti jako přístupový token uživatele Microsoft Entra ID.

Architektura klienta pro Microsoft Entra ID

Díky integraci Microsoft Entra ID můžete architekturu zjednodušit přímo pomocí ID Entra pro ověřování a autorizaci. Následující kroky popisují proces:

1. Uživatel spustí klientskou aplikaci.
2. Klientská aplikace ověřuje uživatele prostřednictvím ID Microsoft Entra. Klientská aplikace získá uživatelský přístupový token Entra ID s oprávněními API pro aplikaci Klienti Azure Communication Services.
3. Klientská aplikace získá přístupový token služby Azure Communication Services pro uživatele Entra ID pomocí jedné z následujících metod:
   • Použití běžných sad SDK služby Azure Communication Services: Klient inicializuje CommunicationTokenCredential s možnostmi přihlašovacích údajů tokenu Entra ID, které automaticky zpracovává získání přístupového tokenu služby Azure Communication Services pro uživatele Entra ID na pozadí. Aplikace pak pomocí těchto přihlašovacích údajů přistupuje k rozhraním API služby Azure Communication Services.
   • Vlastní implementace: Klientská aplikace volá rozhraní API pro výměnu tokenu Entra ID za přístupový token služby Azure Communication Services, aby získala přístupový token služby Azure Communication Services. Výsledný přístupový token služby Azure Communication Services se pak použije pro přístup k rozhraním API služby Azure Communication Services.

Tato architektura eliminuje potřebu samostatné služby správy identit, protože ID Microsoft Entra zpracovává ověřování a autorizaci uživatelů přímo.

Omezení

Integrace Microsoft Entra ID je aktuálně ve verzi Preview a má následující omezení:

• Průběžné vyhodnocování přístupu není k dispozici. Pokud chcete přístupové tokeny okamžitě odvolat, postupujte podle pokynů v části Odvolání přístupových tokenů.
• Odebrání uživatele Entra ID automaticky neodebere všechna přidružená data z prostředku Komunikační služby. Pokud chcete zajistit odstranění všech dat, postupujte podle pokynů v tématu Odstranění identity.
• Oprávnění rozhraní API pro chat (zasílání zpráv) (Chat, Chat.Join, Chat.Join.Limited) není možné udělit ani použít prostřednictvím integrace s ID Microsoft Entra ve verzi Public Preview. Podporují se pouze oprávnění související s VoIP (VoIP, VoIP.Join). Pomocí modelu identity BYOI můžete získat přístupové tokeny chatu, dokud nedosáhnete obecné dostupnosti (GA).

Další kroky

• Informace o vydávání tokenů najdete v tématu Vytváření a správa přístupových tokenů pro koncové uživatele.
• Úvod k ověřování najdete v tématu Ověřování ve službě Azure Communication Services.
• Podrobnosti o tom, jak funguje ověřování ve scénářích s jedním tenantem a v scénářích pro více tenantů s Microsoft Entra ID, najdete v tématu Tenancy in Microsoft Entra ID.
• Pro rychlý návod na ověření uživatelů Microsoft Entra ID viz Ověření uživatelů Microsoft Entra ID.
• Informace o rezidenci dat a ochraně osobních údajů najdete v tématu Dostupnost regionů a rezidence dat.
• Úplnou ukázku jednoduché služby pro správu identit najdete v kurzu důvěryhodné služby.
• Pokud chcete pokročilejší příklad správy identit, který se integruje s Entra ID a Microsoft Graph, podívejte se na ukázkovou implementaci služby ověřování jako hrdiny.