Freigeben über


Authentifizierung

Beim Ausführen von REST-Aufrufen sind mehrere Schritte erforderlich, um sich ordnungsgemäß zu authentifizieren. Azure Communication Services-SDKs behandeln diesen Prozess für Sie, aber das manuelle Durchführen von Anforderungen bedeutet, dass Sie ihn selbst behandeln müssen.

Authentifizierungstypen

Azure Communication Services hat drei Arten von Authentifizierung, sie werden für verschiedene Zwecke verwendet:

  • Zugriffstastenauthentifizierung für SMS-, Netzwerk-Traversal-, Anrufautomatisierungs-, Identitäts- und Zugriffstokenvorgänge. Die Zugriffstastenauthentifizierung eignet sich für Anwendungen, die in einer vertrauenswürdigen Dienstumgebung ausgeführt werden.
  • Azure RBAC-Authentifizierung, um den Zugriff auf Ressourcen zu steuern, indem Azure RBAC durch Zuweisen von Azure-Rollen verwendet wird.
  • Benutzerzugriffstokenauthentifizierung für Chat und Anrufe. Benutzerzugriffstoken ermöglichen es Ihren Clientanwendungen, sich direkt bei Azure Communication Services zu authentifizieren. Diese Token werden auf einem serverseitigen Tokenbereitstellungsdienst generiert, den Sie erstellen. Sie werden dann Clientgeräten bereitgestellt, die das Token zum Initialisieren der Chat- und Anrufclientbibliotheken verwenden.

Zugriffstastenauthentifizierung

Die Zugriffstastenauthentifizierung wird verwendet, wenn Anforderungen nicht von Ihrer Endbenutzeranwendung vorgenommen werden. Führen Sie diese Anforderungen in einer vertrauenswürdigen Dienstumgebung aus.

Bei dieser Authentifizierungsmethode werden Anforderungen mithilfe eines vom Client generierten hashbasierten Nachrichtenauthentifizierungscode (HMAC)signiert.

Stellen Sie vor den ersten Schritten folgendes sicher:

  • Zugriffsschlüssel für Azure Communication Services
  • Ihr Azure Communication Service-Endpunkt
  • Der URL-Pfad und das HTTP-Verb, das Sie aufrufen
  • Eine Entwicklungsumgebung, in der HMACs, SHA256-Hashes und Base64-Vorgänge ausgeführt werden können.

Sobald Sie diese Elemente haben, können Sie ihre Anforderung weiterhin signieren.

Signieren einer HTTP-Anforderung

  1. Stellen Sie sicher, dass die folgenden Werte verfügbar sind:

    • HTTP-Anforderungsmethode (z. B. GET oder PUT)
    • Koordinierter Weltzeitstempel (UTC) für die Anforderung gemäß dem RFC1123 Standard
    • HTTP-Anforderungshost (die <authority> URI-Komponente, wie in RFC2396 angegeben)
    • HTTP-Anforderungstext mit Hashing mithilfe des SHA256-Algorithmus
    • HTTP-Anforderungspfad (der <path> und <query> durch ? Komponenten verkettet, wie in RFC2396 angegeben)
    Verb=<http_method>
    Timestamp=<current_datetime>
    Host=<uri_authority>
    ContentHash=SHA256(<request_body>)
    URIPathAndQuery=<uri_path>?<uri_query>
    
  2. Erstellen Sie die Zeichenfolge, die signiert werden soll, indem Sie die Werte wie folgt verketten:

    StringToSign=Verb + "\n"
    URIPathAndQuery + "\n"
    Timestamp + ";" + Host + ";" + ContentHash
    
  3. Generieren Sie eine HMAC-256-Signatur der UTF-8-codierten Zeichenfolge, die Sie im vorherigen Schritt erstellt haben. Codieren Sie als Nächstes Ihre Ergebnisse als Base64. Sie müssen auch Base64-decodieren, um Ihren Zugriffsschlüssel zu decodieren. Verwenden Sie das folgende Format (als Pseudocode dargestellt):

    Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_access_key>)))
    
  4. Fügen Sie der Anforderung die folgenden Header hinzu:

    x-ms-date: <Timestamp>
    x-ms-content-sha256: <ContentHash>
    host: <URIPathAndQuery>   
    Authorization: "HMAC-SHA256 SignedHeaders=x-ms-date;host;x-ms-content-sha256&Signature=<Signature>"
    

Nach Erhalt der Anforderung überprüft der Dienst die Signatur und den Zeitstempel, um vor bestimmten Sicherheitsangriffen, einschließlich Replay-Angriffen, zu schützen. Informationen zum Signieren der HTTP-Anforderung in verschiedenen Programmiersprachen finden Sie im HMAC-Headersignatur-Lernprogramm.

Azure RBAC-Authentifizierung

Die Azure-Plattform bietet rollenbasierten Zugriff (Azure RBAC), um den Zugriff auf die Ressourcen zu steuern. Der Azure RBAC-Sicherheitsprinzipal stellt eine Benutzer-, Gruppen-, Dienstprinzipal- oder verwaltete Identität dar, die den Zugriff auf Azure-Ressourcen anfordert.

Die Microsoft Entra-Authentifizierung bietet eine überlegene Sicherheit und benutzerfreundlichkeit gegenüber anderen Autorisierungsoptionen. Wenn Sie beispielsweise verwaltete Identität verwenden, müssen Sie ihren Kontozugriffsschlüssel nicht in Ihrem Code speichern, wie bei der Zugriffstastenauthentifizierung. Sie können die Access Key-Authentifizierung zwar weiterhin mit Anwendungen für Kommunikationsdienste verwenden, aber Microsoft empfiehlt, nach Möglichkeit zur Microsoft Entra-ID zu wechseln.

Azure RBAC umfasst viele integrierte Rollen, kann in verschiedenen Bereichen zugewiesen werden und ermöglicht ihnen das Erstellen eigener benutzerdefinierter Rollen. Sie umfasst mehr als 100 integrierte Rollen. Es gibt fünf grundlegende Azure-Rollen : Besitzer, Mitwirkender, Leser, Rollenbasierter Zugriffssteuerungsadministrator und Benutzerzugriffsadministrator. Weitere Informationen zu diesen Rollen finden Sie im Lernprogramm Rollenbasierte Zugriffssteuerung.

Von Azure Communication Services (ACS) unterstützte Berechtigungen

ACS bietet spezifische Berechtigungen (acs.read und acs.write), die den kontrollierten Zugriff auf verschiedene Ressourcen ermöglichen.

  • acs.read-Berechtigung: gewährt die Möglichkeit, Daten abzurufen oder anzuzeigen.
  • acs.write-Berechtigung: Erlaubt änderungen oder Erstellen von Daten innerhalb derselben Ressourcentypen.

Darüber hinaus unterstützt ACS E-Mail-bezogene Berechtigungen:

  • acs.email.read: Ermöglicht das Lesen oder Zugreifen auf E-Mail-bezogene Dienstdaten.
  • acs.email.write: ermöglicht Änderungen oder Erstellung von E-Mail-bezogenen Dienstdaten.

Diese Berechtigungen sind entscheidend, um eine präzise Zugriffssteuerung und Sicherheit über ACS-Ressourcen sicherzustellen.

Abrufen zusätzlicher RBAC-Token

Zum Abrufen eines Tokens für ACS können Sie MSAL (Microsoft Authentication Library) verwenden. Hier ist eine schrittweise Anleitung:

  1. Registrieren Sie eine Anwendung in Azure AD: Stellen Sie sicher, dass Ihre App in Azure AD registriert ist.
  2. Installieren Sie MSAL: Installieren Sie die MSAL-Bibliothek für Ihre Plattform (z. B. Microsoft.Identity.Client für .NET).
  3. Konfigurieren Sie MSAL: Richten Sie MSAL mit der Client-ID, Mandanten-ID und dem geheimen Clientschlüssel Ihrer Anwendung ein.
  4. Token erwerben: Verwenden Sie MSAL, um ein Token mit dem erforderlichen Bereich (https://communication.azure.com/.default) zu erwerben.

Ausführliche Anweisungen und Codebeispiele finden Sie in der offiziellen MSAL-Dokumentation und Access Token-Dokumentation.

Beispiel-HTTP-Anforderung zum Ausgeben des ACS-Zugriffstokens

Bitten:

POST https://my-resource.communication.azure.com/identities/{identity}/:issueAccessToken?api-version=2023-10-01
Authorization: Bearer <your-access-token>
Content-Type: application/json
{
  "scopes": [
    "chat",
    "voip"
  ]
}

Antwort:

{
  "token": "token",
  "expiresOn": "2023-10-10T21:39:39.3244584+00:00"
}

Benutzerzugriffstokenauthentifizierung

Benutzerzugriffstoken ermöglichen Es Ihren Clientanwendungen, sich direkt bei Azure Communication Services als bestimmter Benutzer oder Identität zu authentifizieren.

Generieren/Abrufen eines Benutzerzugriffstokens

Benutzerzugriffstoken werden von Ihnen in einer vertrauenswürdigen Umgebung generiert. Die Generierung mit dem Azure Communication Services Identity SDK ist die einfachste Möglichkeit. Weitere Informationen finden Sie unter Erstellen und Verwalten von Benutzerzugriffstoken.

Verwenden eines Benutzerzugriffstokens in einer Anforderung

Sobald Sie über ein geeignetes Benutzerzugriffstoken verfügen, können Sie es in Ihre Anforderungen an die REST-API von Azure Communication Services einschließen. Dazu müssen Sie sie im Authorization Header mithilfe des Bearer HTTP-Authentifizierungsschemas Authorization: Bearer <token>angeben.

Siehe auch

Weitere Informationen zur Azure Communication Services-Authentifizierung finden Sie auch unter: