Udostępnij przez

Model tożsamości

Azure Communication Services to niezależna od tożsamości usługa, która oferuje wiele korzyści:

  • Wdrożenie modelu "przynieś własną tożsamość" (BYOI, Bring Your Own Identity), co umożliwia ponowne użycie istniejących tożsamości z systemu zarządzania tożsamościami i mapowanie ich przy użyciu tożsamości usług Azure Communication Services.
  • Działa dobrze w przypadku dowolnego istniejącego systemu tożsamości i nie ma zależności od określonego dostawcy tożsamości.
  • Zachowaj dane użytkownika, takie jak ich nazwa, prywatne, ponieważ nie trzeba ich duplikować w usługach Azure Communication Services.
  • Organizacje korzystające z Microsoft Entra ID do zarządzania tożsamością i dostępem mogą teraz uzyskiwać dostęp do zasobów Azure Communication Services bezpośrednio za pomocą użytkowników Microsoft Entra ID. Ta nowa obsługa uwierzytelniania Entra ID eliminuje konieczność tworzenia lub obsługi własnej usługi zarządzania tożsamościami lub serwera proxy autoryzacji. Ta funkcja jest obecnie dostępna w publicznej wersji zapoznawczej.

Model tożsamości usług Azure Communication Services współpracuje z dwoma kluczowymi pojęciami.

Bring Your Own Identity (BYOI): integracja z systemem zarządzania tożsamościami

Usługi Azure Communication Services obsługują model "przynieś własną tożsamość" (BYOI), który umożliwia integrację z istniejącym systemem zarządzania tożsamościami. Można stworzyć tożsamości użytkowników w usługach Azure Communication Services i przypisać je do własnego systemu tożsamości użytkownika. Takie podejście umożliwia zarządzanie tożsamościami użytkowników i tokenami dostępu bez duplikowania danych użytkownika w usługach Azure Communication Services.

W następnych sekcjach przedstawione zostaną kluczowe pojęcia dotyczące modelu "przynieś swoją tożsamość" (BYOI).

Mapowanie tożsamości użytkownika w modelu byOI (Bring Your Own Identity)

Podczas tworzenia tożsamości użytkownika za pomocą zestawu SDK lub interfejsu API REST usługi Azure Communication Services tworzą unikatowy identyfikator użytkownika. Nie można używać identyfikatorów zewnętrznych, takich jak numery telefonów, identyfikatory użytkowników/urządzeń/aplikacji lub nazwy użytkowników bezpośrednio w usługach Azure Communication Services. Zamiast tego należy korzystać z tożsamości z systemu usług komunikacyjnych i utrzymywać odpowiednie mapowanie do własnego systemu identyfikatorów użytkownika, zgodnie z potrzebami.

Tożsamości użytkowników usługi Azure Communication Service można utworzyć bezpłatnie. Opłaty są naliczane tylko wtedy, gdy użytkownik korzysta z usług komunikacyjnych, takich jak czat lub połączenie. Sposób korzystania z wygenerowanej tożsamości usług komunikacyjnych zależy od scenariusza. Można na przykład zamapować tożsamość 1:1, 1:N, N:1 lub N:N i użyć jej dla użytkowników lub aplikacji. Użytkownik końcowy może uczestniczyć w wielu sesjach komunikacji przy użyciu wielu urządzeń jednocześnie.

Zarządzanie mapowaniem tożsamości użytkowników usług Azure Communication Services i własnym systemem tożsamości jest twoim zadaniem jako deweloper i nie jest wbudowane. Możesz na przykład dodać kolumnę CommunicationServicesId w istniejącej tabeli użytkowników do przechowywania skojarzonej tożsamości usług Azure Communication Services. Projekt mapowania został szczegółowo opisany w temacie Architektura serwera klienckiego dla modelu BYOI (Bring Your Own Identity).

(Wersja zapoznawcza) Upraszczanie mapowania tożsamości za pomocą customId

Important

Ta funkcja jest dostępna od wersji 1.4.0-beta1 zestawu Identity SDK i wersji 2025-03-02-previewinterfejsu API REST.

Note

Ta funkcja jest obecnie dostępna w wersji zapoznawczej.

Wcześniej deweloperzy byli odpowiedzialni za utrzymywanie mapowania między własnym systemem tożsamości użytkowników a tożsamościami usług Azure Communication Services. Wraz z wprowadzeniem parametru customId można teraz skojarzyć własne identyfikatory użytkowników — takie jak adresy e-mail lub identyfikatory użytkowników wewnętrznych — bezpośrednio podczas tworzenia tożsamości usług komunikacyjnych.

Podczas tworzenia użytkownika za pomocą customId usług Azure Communication Services, system zwróci tę samą tożsamość, jeśli ponownie wywołasz metodę korzystając z tej samej customId. Eliminuje to konieczność samodzielnego przechowywania mapowania i zarządzania nim.

Ta funkcja jest obsługiwana zarówno w zestawie SDK, jak i interfejsie API REST, i jest szczególnie przydatna w scenariuszach, w których chcesz zachować spójną tożsamość między sesjami, urządzeniami lub usługami bez dodatkowych obciążeń związanych z magazynem.

Tokeny dostępu

Po utworzeniu tożsamości użytkownika użytkownik końcowy potrzebuje tokenu dostępu z określonymi zakresami, aby uczestniczyć w komunikacji przy użyciu czatu lub połączeń. Na przykład tylko użytkownik z tokenem zakresu chat może uczestniczyć w czacie. Tylko użytkownik z tokenem o zakresie voip może uczestniczyć w rozmowie VoIP.

Użytkownik może mieć jednocześnie wiele tokenów. Usługi Azure Communication Services obsługują wiele zakresów tokenów, aby uwzględnić użytkowników, którzy wymagają pełnego dostępu i ograniczonego dostępu. Tokeny dostępu mają następujące właściwości.

Property Description
Subject Tożsamość użytkownika reprezentowana przez token.
Expiration Token dostępu jest ważny przez co najmniej 1 godzinę i do 24 godzin. Po wygaśnięciu token dostępu jest nieprawidłowy i nie można go użyć do uzyskania dostępu do usługi. Aby utworzyć token z niestandardowym czasem wygaśnięcia, określ żądaną ważność w minutach (>=60, <1440). Domyślnie token jest ważny przez 24 godziny. Zalecamy używanie tokenów krótkiego okresu istnienia dla pojedynczych spotkań i tokenów dłuższego okresu istnienia dla użytkowników, którzy potrzebują aplikacji przez dłuższy czas.
Scopes Zakresy określają, do których usług (Chat/VoIP) można uzyskać dostęp za pomocą tokenu.

Token dostępu jest tokenem sieci Web JSON (JWT) i ma ochronę integralności. Oznacza to, że nie można zmienić jego oświadczeń bez unieważnienia tokenu dostępu, ponieważ podpis tokenu nie jest już zgodny. Jeśli prymitywy komunikacyjne są używane z nieprawidłowymi tokenami, dostęp jest zabroniony. Mimo że tokeny nie są szyfrowane ani zaciemnione, aplikacja nie powinna zależeć od formatu tokenu ani jego oświadczeń. Format tokenu może ulec zmianie i nie jest częścią oficjalnego kontraktu interfejsu API. Usługi Azure Communication Services obsługują następujące zakresy tokenów dostępu.

Zakresy tokenu chatowego

Model tożsamości obsługuje trzy różne zakresy tokenów czatu. Uprawnienia dla każdego zakresu opisano w poniższej tabeli.

  • chat
  • chat.join
  • chat.join.limited
Możliwości/Zakres tokenu chat chat.join chat.join.limited
Tworzenie wątku czatu Y N N
Zaktualizuj wątek czatu z identyfikatorem Y N N
Usuwanie wątku czatu o identyfikatorze Y N N
Dodawanie uczestnika do wątku czatu Y Y N
Usuwanie uczestnika z wątku czatu Y Y N
Pobierz wątki czatu Y Y Y
Pobieranie wątku czatu o identyfikatorze Y Y Y
Pobieranie elementu ReadReceipt Y Y Y
Tworzenie elementu ReadReceipt Y Y Y
Tworzenie wiadomości dla wątku czatu o identyfikatorze Y Y Y
Pobierz wiadomość z identyfikatorem wiadomości Y Y Y
Aktualizowanie własnej wiadomości przy użyciu identyfikatora komunikatu Y Y Y
Usuwanie własnej wiadomości z identyfikatorem komunikatu Y Y Y
Wyślij wskaźnik wpisywania Y Y Y
Pobieranie uczestnika dla identyfikatora wątku Y Y Y

Zakresy tokenów VoIP

Model tożsamości obsługuje dwa zakresy tokenów VoIP. Uprawnienia dla każdego zakresu opisano w poniższej tabeli.

  • voip
  • voip.join
Możliwości/Zakres tokenu voip voip.join
Uruchamianie połączenia VoIP Y N
Rozpoczynanie połączenia VoIP w pokojach wirtualnych, gdy użytkownik jest już zaproszony do pokoju Y Y
Dołącz do trwającej rozmowy VoIP Y Y
Dołącz do połączenia VoIP inProgress w pokojach wirtualnych, gdy użytkownik jest już zaproszony do pokoju Y Y
Wszystkie inne operacje wykonywane podczas połączenia, takie jak wyciszanie/wyłączanie wyciszenia, udostępnianie ekranu itd. Y Y
Wszystkie inne operacje wywołania, takie jak wyciszanie/wyciszanie, udostępnianie ekranu itd., w pokojach wirtualnych Określana przez rolę użytkownika Określana przez rolę użytkownika

Zakres można używać voip.join razem z usługą Rooms , aby utworzyć zaplanowane wywołanie. W tym scenariuszu tylko zaproszeni użytkownicy uzyskują dostęp, a użytkownicy nie mogą tworzyć żadnych innych wywołań.

Odwoływanie lub aktualizowanie tokenu dostępu

  • Biblioteka tożsamości usług Azure Communication Services może służyć do odwoływanie tokenu dostępu przed upływem czasu wygaśnięcia. Odwołanie tokenu nie jest natychmiastowe. Propagacja może potrwać do 15 minut.
  • Usunięcie tożsamości, zasobu lub subskrypcji powoduje odwołanie wszystkich tokenów dostępu.
  • Jeśli chcesz usunąć możliwość uzyskania dostępu do określonych funkcji przez użytkownika, odwołaj wszystkie tokeny dostępu dla użytkownika. Następnie wydaj nowy token dostępu, który ma bardziej ograniczony zestaw zakresów.
  • Rotacja kluczy dostępu odwołuje wszystkie aktywne tokeny dostępu, które zostały utworzone przy użyciu byłego klucza dostępu. W związku z tym wszystkie tożsamości utracą dostęp do usług Azure Communication Services i potrzebują nowych tokenów dostępu.

Architektura klient-serwer dla modelu „Bring Your Own Identity” (BYOI)

Tworzenie tokenów dostępu użytkowników i zarządzanie nimi za pośrednictwem zaufanej usługi, a nie tworzenie tokenów w aplikacji klienckiej. Do utworzenia tokenów dostępu użytkowników potrzebne są parametry połączenia lub poświadczenia firmy Microsoft Entra. Pamiętaj, aby chronić poświadczenia, przekazanie ich klientowi może spowodować wyciek sekretu. Niepowodzenie prawidłowego zarządzania tokenami dostępu może spowodować dodatkowe opłaty za zasób, gdy tokeny są swobodnie wydawane i niewłaściwie używane przez kogoś innego.

Jeśli buforujesz tokeny dostępu do magazynu kopii zapasowych, zalecamy szyfrowanie tokenów. Token dostępu zapewnia dostęp do poufnych danych i może być używany do złośliwego działania, jeśli nie jest on chroniony. Każda osoba mająca token dostępu do konta użytkownika może uzyskać dostęp do danych czatu tego użytkownika lub uczestniczyć w rozmowach, podszywając się pod użytkownika.

Pamiętaj, aby uwzględnić w tokenie wyłącznie te zakresy, które są potrzebne aplikacji klienckiej do przestrzegania zasady najmniejszych uprawnień.

Diagram przedstawiający architekturę tokenu dostępu użytkownika.

  1. Użytkownik uruchamia aplikację kliencką.
  2. Aplikacja kliencka kontaktuje się z usługą zarządzania tożsamościami.
  3. Usługa zarządzania tożsamościami uwierzytelnia użytkownika aplikacji. Uwierzytelnianie można pominąć w scenariuszach, w których użytkownik jest anonimowy, ale należy zachować ostrożność, aby dodać inne środki ochronne, takie jak ograniczanie przepustowości i mechanizm CORS do usługi, aby wyeliminować nadużycie tokenu.
  4. Utwórz lub znajdź identyfikator usług komunikacyjnych dla użytkownika.
    1. Scenariusz stabilnej tożsamości: Usługa zarządzania tożsamościami utrzymuje mapowanie tożsamości między tożsamościami aplikacji i tożsamościami usług komunikacyjnych. (Tożsamości aplikacji obejmują użytkowników i inne obiekty adresowalne, takie jak usługi lub boty). Jeśli tożsamość aplikacji jest nowa, zostanie utworzona nowa tożsamość komunikacji i zostanie zapisane mapowanie.
    2. Scenariusz tożsamości efemerycznej: usługa zarządzania tożsamościami tworzy nową tożsamość komunikacji. W tym scenariuszu ten sam użytkownik otrzymuje inną tożsamość komunikacyjną dla każdej sesji.
  5. Usługa zarządzania tożsamościami wystawia token dostępu użytkownika dla odpowiedniej tożsamości i zwraca go do aplikacji klienckiej.

Usługa Azure App Service lub Azure Functions to dwie alternatywy do uruchamiania usługi zarządzania tożsamościami. Te usługi można łatwo skalować i mieć wbudowane funkcje do uwierzytelniania użytkowników. Są one zintegrowane z dostawcami tożsamości openID i dostawcami tożsamości innych firm, takimi jak Facebook.

Microsoft Entra ID: Integracja z identyfikatorem Entra

Important

Ta funkcja usługi Azure Communication Services jest obecnie dostępna w wersji próbnej. Funkcje w wersji zapoznawczej są publicznie dostępne i mogą być używane przez wszystkich nowych i istniejących klientów firmy Microsoft.

API i zestawy SDK w wersji zapoznawczej są dostarczane bez umowy na poziomie usług. Zalecamy, aby nie używać ich do obciążeń produkcyjnych. Niektóre funkcje mogą nie być obsługiwane lub mogą być ograniczone.

Aby uzyskać więcej informacji, zobacz Warunki dodatkowe korzystania z testowych wersji Microsoft Azure.

Usługi Azure Communication Services obsługują teraz uwierzytelnianie identyfikatora Entra firmy Microsoft, co umożliwia bezpośredni dostęp do zasobów usług Azure Communication Services za pomocą użytkowników identyfikatora Entra. Ta nowa obsługa uwierzytelniania Entra ID eliminuje konieczność tworzenia lub obsługi własnej usługi zarządzania tożsamościami lub serwera proxy autoryzacji, wymienionych w sekcji Architektura klient-serwer.

W poniższych sekcjach przedstawiono podstawowe aspekty integracji identyfikatora Entra firmy Microsoft:

Tokeny dostępu za pomocą identyfikatora Entra firmy Microsoft

Tylko tokeny dostępu usług Azure Communication Services są obsługiwane w przypadku uwierzytelniania i autoryzacji w usługach Azure Communication Services, w tym funkcji czatu i połączeń. Aby uzyskać więcej informacji na temat struktury tokenów i zarządzania nimi, zobacz Access tokens (Tokeny dostępu). Podczas publicznej wersji zapoznawczej Microsoft Entra ID obsługiwane są tylko zakresy tokenów dostępu dla połączeń (VoIP) za pośrednictwem integracji Entra ID.

Dzięki integracji identyfikatora Entra firmy Microsoft uwierzytelniasz użytkowników za pośrednictwem identyfikatora Entra ID, uzyskujesz token dostępu użytkownika Entra ID z uprawnieniami interfejsu API dla aplikacji klienckich usług Azure Communication Services i wymieniasz go na token dostępu usług Azure Communication Services. Wspólne zestawy SDK usług Azure Communication Services oferują bezproblemowe uwierzytelnianie, automatycznie uzyskując token dostępu usług Azure Communication Services dla użytkownika entra ID. Aby uzyskać więcej informacji na temat implementowania logiki za pomocą wspólnego zestawu SDK usług Azure Communication Services, zobacz Uzyskiwanie tokenów dostępu dla użytkowników usługi Microsoft Entra ID

Uprawnienia interfejsu API dla aplikacji Klienci usług Azure Communication Services są nazwane spójnie z zakresami tokenów dostępu usług Azure Communication Services opisanymi w sekcjach Zakresy tokenów czatu i Zakresy tokenów VoIP. W poniższej tabeli przedstawiono mapowanie między uprawnieniami interfejsu API a zakresami tokenu dostępu.

Important

Uprawnienia interfejsu API czatu (Chat, Chat.Join, Chat.Join.Limited) nie są jeszcze obsługiwane za pośrednictwem identyfikatora Entra firmy Microsoft w publicznej wersji zapoznawczej. Na razie dostępne są tylko uprawnienia związane z voIP (VoIP, VoIP.Join). Obsługa czatów jest planowana na przyszłą aktualizację.

Uprawnienia interfejsu API klientów usług Azure Communication Services Zakres tokenu dostępu usług Azure Communication Services
Chat (Publiczna wersja zapoznawcza Entra ID: tylko VoIP — nadchodzący czat) chat
Chat.Join (Publiczna wersja zapoznawcza Entra ID: tylko VoIP — nadchodzący czat) chat.join
Chat.Join.Limited (Publiczna wersja zapoznawcza Entra ID: tylko VoIP — nadchodzący czat) chat.join.limited
VoIP voip
VoIP.Join voip.join

Tokeny dostępu usług Azure Communication Services są wystawiane z tym samym wygaśnięciem co token dostępu użytkownika Microsoft Entra ID.

Architektura klienta dla identyfikatora Entra firmy Microsoft

Dzięki integracji identyfikatora Entra firmy Microsoft możesz uprościć architekturę bezpośrednio przy użyciu identyfikatora Entra na potrzeby uwierzytelniania i autoryzacji. W poniższych krokach opisano proces:

Diagram przedstawiający architekturę integracji identyfikatora Entra firmy Microsoft.

  1. Użytkownik uruchamia aplikację kliencką.
  2. Aplikacja kliencka uwierzytelnia użytkownika za pomocą identyfikatora Entra firmy Microsoft. Aplikacja kliencka uzyskuje token dostępu użytkownika Entra ID z uprawnieniami API dla aplikacji klientów usług Azure Communication Services.
  3. Aplikacja kliencka uzyskuje token dostępu usług Azure Communication Services dla użytkownika Entra ID przy użyciu jednej z następujących metod:
    • Korzystając ze wspólnych zestawów SDK usług Azure Communication Services: klient inicjuje CommunicationTokenCredential z opcjami poświadczeń tokenu dla Entra ID, które automatycznie obsługują uzyskiwanie tokenu dostępu do usług Azure Communication Services dla użytkownika Entra ID w tle. Następnie aplikacja używa tego poświadczenia do uzyskiwania dostępu do interfejsów API usług Azure Communication Services.
    • Implementacja niestandardowa: aplikacja kliencka wywołuje interfejs API Exchange Entra ID token for Azure Communication Services access token, aby uzyskać token dostępu usług Azure Communication Services. Wynikowy token dostępu do usług Azure Communication Services jest następnie używany do uzyskiwania dostępu do interfejsów API tych usług.

Ta architektura eliminuje potrzebę oddzielnej usługi zarządzania tożsamościami, ponieważ identyfikator Entra firmy Microsoft obsługuje uwierzytelnianie użytkownika i autoryzację bezpośrednio.

Ograniczenia

Integracja identyfikatora Entra firmy Microsoft jest obecnie dostępna w wersji zapoznawczej i ma następujące ograniczenia:

  • Ciągła ocena dostępu jest niedostępna. Aby natychmiast odwołać tokeny dostępu, postępuj zgodnie z instrukcjami w temacie Odwoływanie tokenów dostępu.
  • Usunięcie użytkownika entra ID nie powoduje automatycznego usunięcia wszystkich skojarzonych danych z zasobu usług komunikacyjnych. Aby upewnić się, że wszystkie dane zostały usunięte, postępuj zgodnie z instrukcjami w temacie Usuwanie tożsamości.
  • Uprawnienia interfejsu API czatu (Chat, Chat.Join, Chat.Join.Limited) nie mogą być przyznawane ani używane za pośrednictwem integracji identyfikatora Entra firmy Microsoft w publicznej wersji zapoznawczej. Obsługiwane są tylko uprawnienia związane z voIP (VoIP, VoIP.Join). Użyj modelu tożsamości BYOI, aby uzyskać tokeny dostępu do czatu do momentu osiągnięcia statusu GA.

Dalsze kroki

  • Last updated on