Freigeben über

Identitätsmodell

  • Artikel

Azure Communication Services ist ein identitätsunabhängiger Dienst, der mehrere Vorteile bietet:

  • Wiederverwenden vorhandener Identitäten aus Ihrem Identitätsverwaltungssystem und Zuordnen dieser Identitäten zu Azure Communication Services-Identitäten
  • Funktioniert gut mit allen vorhandenen Identitätssystemen und weist keine Abhängigkeit von einem bestimmten Identitätsanbieter auf
  • Sicheres Aufbewahren von Benutzerdaten wie Namen, da keine Duplizierung in Azure Communication Services erforderlich ist

Das Azure Communication Services-Identitätsmodell funktioniert mit zwei Schlüsselkonzepten.

Benutzeridentität und Zuordnung

Wenn Sie eine Benutzeridentität über das SDK oder die REST-API erstellen, erstellt Azure Communication Services eine eindeutige Benutzer-ID. Externe Bezeichner wie Telefonnummern, Benutzer-/Geräte-/Anwendungs-IDs oder Benutzernamen können nicht direkt in Azure Communication Services verwendet werden. Stattdessen müssen Sie die Communication Services-Identitäten verwenden und bei Bedarf eine Zuordnung zu Ihrem eigenen Benutzer-ID-System verwalten. Das Erstellen von Azure Communication Services-Benutzeridentitäten ist kostenlos, und es fallen nur Gebühren an, wenn die Benutzenden Kommunikationsmodalitäten wie Chats oder Anrufsfunktionen verwenden. Wie Sie Ihre generierte Communication Services-Identität verwenden, hängt von Ihrem Szenario ab. Sie können beispielsweise eine Identität 1:1, 1:n, n:1 oder n:n zuordnen und sie für menschliche Benutzende oder Anwendungen verwenden. Benutzende können an mehreren Kommunikationssitzungen teilnehmen, wobei mehrere Geräte gleichzeitig verwendet werden. Die Verwaltung einer Zuordnung zwischen Azure Communication Services-Benutzeridentitäten und Ihrem eigenen Identitätssystem liegt in Ihrer Verantwortung als entwickelnde Person und ist nicht integriert. Sie können beispielsweise eine CommunicationServicesId-Spalte in Ihrer vorhandenen Benutzertabelle hinzufügen, um die zugeordnete Azure Communication Services-Identität zu speichern. Ein Zuordnungsentwurf wird im Abschnitt zur Clientserverarchitektur ausführlicher beschrieben.

Zugriffstoken

Nachdem eine Benutzeridentität erstellt wurde, benötigen Benutzende ein Zugriffstoken mit bestimmten Bereichen, um mithilfe von Chats oder Anrufen zu kommunizieren. Beispielsweise können nur Benutzende mit einem Token mit dem chat-Bereich an einem Chat und nur Benutzende mit einem Token mit dem voip-Bereich an einem VoIP-Anruf teilnehmen. Ein Benutzer kann mehrere Token gleichzeitig haben. Azure Communication Services unterstützt mehrere Tokenbereiche, um Benutzende zu berücksichtigen, die Vollzugriff bzw. eingeschränkten Zugriff benötigen. Zugriffstoken weisen die folgenden Eigenschaften auf.

Eigenschaft Beschreibung
Betreff Benutzeridentität, die durch das Token dargestellt wird
Ablauf Ein Zugriffstoken ist mindestens eine Stunde und bis zu 24 Stunden gültig. Nach Ablauf dieser Zeit wird das Zugriffstoken ungültig und kann nicht mehr für den Zugriff auf den Dienst verwendet werden. Um ein Token mit einer benutzerdefinierten Ablaufzeit zu erstellen, geben Sie die gewünschte Gültigkeit in Minuten an (>=60, <1440). Standardmäßig ist das Token 24 Stunden gültig. Es wird empfohlen, Tokens mit kurzer Lebensdauer für einmalige Besprechungen und Tokens mit längerer Lebensdauer für Benutzende zu verwenden, die Ihre Anwendung länger verwenden.
Bereiche Die Bereiche definieren, auf welche Kommunikationsgrundtypen (Chat/VoIP) mit dem Token zugegriffen werden kann.

Ein Zugriffstoken ist ein JSON Web Token (JWT) und verfügt über Integritätsschutz. Das heißt, dass seine Ansprüche nicht geändert werden können, ohne das Zugriffstoken ungültig zu machen, da die Tokensignatur dann nicht mehr übereinstimmt. Wenn Kommunikationsgrundtypen mit ungültigen Tokens verwendet werden, wird der Zugriff verweigert. Obwohl Tokens nicht verschlüsselt oder verschleiert sind, sollte Ihre Anwendung nicht vom Tokenformat oder den zugehörigen Ansprüchen abhängen. Das Tokenformat kann sich ändern und ist nicht Teil des offiziellen API-Vertrags. Azure Communication Services unterstützt die folgenden Bereiche für Zugriffstoken.

Chattokenbereiche

Drei verschiedene Chattokenbereiche werden unterstützt. Die Berechtigungen für jeden Bereich werden in der folgenden Tabelle beschrieben.

  • chat
  • chat.join
  • chat.join.limited
Funktion/Tokenbereich Chat chat.join chat.join.limited
Chatthread erstellen J N N
Aktualisieren des Chatthreads mit ID J N N
Löschen des Chatthreads mit ID J N N
Hinzufügen von Teilnehmern zu einem Chatthread Y Y N
Entfernen eines Teilnehmers aus einem Chatthread Y Y N
Abrufen von Chatthreads Y J J
Abrufen des Chatthreads mit ID Y J J
Abrufen von „ReadReceipt“ Y J J
Erstellen von „ReadReceipt“ Y J J
Erstellen einer Nachricht für einen Chatthread mit ID Y J J
Abrufen einer Nachricht mit der Nachrichten-ID Y J J
Aktualisieren Ihrer eigenen Nachricht mit der Nachrichten-ID Y J J
Löschen Ihrer eigenen Nachricht mit der Nachrichten-ID Y J J
Eingabeindikator senden Y J J
Abrufen der Teilnehmer für die Thread-ID Y J J

VoIP-Tokenbereiche

Zwei VoIP-Tokenbereiche werden unterstützt. Die Berechtigungen für jeden Bereich werden in der folgenden Tabelle beschrieben.

  • voip
  • voip.join
Funktion/Tokenbereich voip voip.join
Starten eines VoIP-Anrufs J N
Starten eines VoIP-Anrufs in Virtual Rooms, wenn die Benutzenden bereits in die Virtual Rooms-Instanz eingeladen sind Y J
Teilnehmen an einem InProgress-VoIP-Anruf Y J
Teilnehmen an einem InProgress VoIP-Anruf in Virtual Rooms, wenn die Benutzenden bereits in die Virtual Rooms-Instanz eingeladen sind Y J
Alle anderen In-Call-Vorgänge wie Stummschaltung/Aufheben der Stummschaltung, Bildschirmfreigabe usw. Y J
Alle anderen In-Call-Vorgänge wie Stummschalten/Aufheben der Stummschaltung, Bildschirmfreigabe usw. in Virtual Rooms Bestimmt von der Benutzerrolle Bestimmt von der Benutzerrolle

Sie können den voip.join-Bereich zusammen mit Rooms-Instanzen verwenden, um einen geplanten Anruf zu erstellen, bei dem nur eingeladene Benutzende Zugriff erhalten und Benutzende keine anderen Anrufe erstellen können.

Widerrufen oder Aktualisieren des Zugriffstokens

  • Die Azure Communication Services-Identitätsbibliothek kann verwendet werden, um ein Zugriffstoken vor dessen Ablauf zu widerrufen. Der Tokenwiderruf ist nicht sofort wirksam. Es kann bis zu 15 Minuten dauern, bis der Widerruf in Kraft tritt.
  • Durch das Löschen einer Identität, Ressource oder eines Abonnements werden alle Zugriffstokens widerrufen.
  • Wenn Sie verhindern möchten, dass Benutzende auf bestimmte Funktionen zugreifen können, widerrufen Sie alle Zugriffstokens für diese Benutzenden. Stellen Sie dann ein neues Zugriffstoken mit einem eingeschränkteren Satz von Bereichen aus.
  • Durch das Rotieren von Zugriffsschlüsseln werden alle aktiven Zugriffstokens widerrufen, die mit einem vorherigen Zugriffsschlüssel erstellt wurden. Folglich verlieren alle Identitäten Zugriff auf Azure Communication Services und benötigen neue Zugriffstokens.

Clientserverarchitektur

Sie sollten Benutzerzugriffstokens über einen vertrauenswürdigen Dienst erstellen und verwalten und keine Tokens in Ihrer Clientanwendung erstellen. Die Verbindungszeichenfolge oder die Microsoft Entra-Anmeldeinformationen, die zum Erstellen von Benutzerzugriffstokens erforderlich sind, müssen geschützt sein. Bei ihrer Übergabe an einen Client besteht das Risiko, dass das Geheimnis veröffentlicht wird. Fehler bei der ordnungsgemäßen Verwaltung von Zugriffstokens können zu zusätzlichen Gebühren für Ihre Ressource führen, wenn Tokens frei ausgegeben und von anderen Personen mit böswilligen Absichten verwendet werden.

Wenn Sie Zugriffstokens in einem Sicherungsspeicher zwischenspeichern, wird empfohlen, die Tokens zu verschlüsseln. Ein Zugriffstoken gewährt Zugriff auf vertrauliche Daten und kann für böswillige Aktivitäten verwendet werden, wenn es nicht geschützt ist. Alle Personen mit den Zugriffstokens von Benutzenden können auf deren Chatdaten zugreifen oder an Anrufen teilnehmen, wobei sie die Identität der Benutzenden annehmen.

Stellen Sie sicher, dass Sie nur diejenigen Bereiche in das Token einschließen, die Ihre Clientanwendung benötigt, um das Sicherheitsprinzip der geringsten Berechtigungen zu befolgen.

Diagramm der Architektur von Benutzerzugriffstoken.

  1. Ein Benutzer startet die Clientanwendung.
  2. Die Clientanwendung kontaktiert Ihren Identitätsverwaltungsdienst.
  3. Der Identitätsverwaltungsdienst authentifiziert die Anwendungsbenutzenden. Sie können die Authentifizierung für Szenarios überspringen, in denen die Benutzenden anonym sind, aber achten Sie darauf, weitere Schutzmaßnahmen wie Drosselung und CORS zu Ihrem Dienst hinzuzufügen, um den Missbrauch von Tokens zu vermeiden.
  4. Erstellen Sie eine Communication Services-Identität für die Benutzenden, oder suchen Sie nach einer vorhandenen Identität.
    1. Stabiles Identitätsszenario: Ihr Identitätsverwaltungsdienst verwaltet eine Zuordnung zwischen Anwendungsidentitäten und Communication Services-Identitäten. (Anwendungsidentitäten umfassen Ihre Benutzer und andere adressierbare Objekte, z. B. Dienste oder Bots.) Wenn die Anwendungsidentität neu ist, wird eine neue Communication Services-Identität erstellt und eine Zuordnung gespeichert.
    2. Kurzlebiges Identitätsszenario: Der Identitätsverwaltungsdienst erstellt eine neue Communication Services-Identität. In diesem Szenario verwenden die Benutzenden unterschiedliche Communication Services-Identitäten für die einzelnen Sitzungen.
  5. Der Identitätsverwaltungsdienst gibt ein Benutzerzugriffstoken für die entsprechende Identität aus und gibt es an die Clientanwendung zurück.

Azure App Service oder Azure Functions sind zwei Alternativen zum Betreiben des Identitätsverwaltungsdiensts. Diese Dienste lassen sich einfach skalieren und verfügen über integrierte Features zum Authentifizieren von Benutzern. Sie sind in OpenID und Identitätsanbieter von Drittanbietern wie Facebook integriert.

Nächste Schritte