Authentifizierungstypen

GILT FÜR: SDK v4

Im Bot Framework gibt es zwei allgemeine Authentifizierungskategorien: Bot-Authentifizierung und Benutzerauthentifizierung. Jede verfügt über ein zugeordnetes Token, um den Zugriff auf gesicherte Ressourcen zu ermöglichen. Die folgende Abbildung zeigt die Elemente, die sowohl bei der Bot- als auch bei der Benutzerauthentifizierung beteiligt sind.

In dieser Abbildung:

• Hostplattform ist die Bot-Hostingplattform. Es kann Azure oder eine beliebige Host-Plattform sein.
• Bot Connector Service erleichtert die Kommunikation zwischen einem Bot und einem Kanal. Er konvertiert Nachrichten, die von Kanälen empfangen werden, in Aktivitätsobjekte und sendet sie an den Messaging-Endpunkt des Bots. Ebenso konvertiert er Aktivitätsobjekte, die vom Bot empfangen werden, in Nachrichten, die vom Kanal verstanden werden und sendet sie an den Kanal.
• Bot-Adapter ist der standardmäßige Bot-Framework-Adapter. Er hat folgende Aufgaben:
  • Konvertiert die JSON-Nutzlast in ein Aktivitätsobjekt.
  • Erstellt einen Turnkontext und fügt das Aktivitätsobjekt hinzu.
  • Führt bei Bedarf Middleware aus.
  • Leitet den Turn-Kontext an den Bot weiter.

Hinweis

Wenn ein benutzerdefinierter Kanaladapter verwendet wird, führt der Adapter selbst die Aufgaben aus, die der Bot Connector Service und der Standard-Bot-Adapter ausführen. Außerdem stellt er den Authentifizierungsmechanismus für die zugehörige Webhook-API bereit. Ein Beispiel finden Sie unter Verbinden eines Bots mit Slack mithilfe des Slack-Adapters.

Botauthentifizierung

Ein Bot wird durch seine MicrosoftAppID und MicrosoftAppPassword identifiziert, die in den Einstellungsdateien des Bots (appsettings.json (.NET), .env (JavaScript), config.py (Python)) oder in einem Geheimnis- oder Schlüsselmanager gespeichert werden. Weitere Informationen finden Sie unter MicrosoftAppID und MicrosoftAppPassword.

Wenn Sie einen Bot im Azure-Portal registrieren, erstellt Azure eine Registrierungsanwendung mit Microsoft Entra ID. Wenn Sie die Bot Framework CLI verwenden, müssen Sie einen speziellen Schritt durchführen, um die Microsoft-Entra-ID-Registrierung zu erstellen. Diese Registrierung verfügt über eine Anwendungs-ID (MicrosoftAppID) und einen geheimen Clientschlüssel (MicrosoftAppPassword). Azure verwendet diese Werte, um ein Token zu generieren, mit dem der Bot auf sichere Ressourcen zugreifen kann.

Wenn ein Kanal über den Bot-Connector-Dienst eine Anfrage an einen Bot sendet, gibt er im Autorisierungsheader der Anfrage ein Token an. Der Bot authentifiziert Anrufe vom Bot Connector-Dienst, indem er die Echtheit des Tokens überprüft.

Wenn der Bot über den Bot-Connector-Dienst eine Anforderung an einen Kanal sendet, gibt er im Autorisierungsheader der Anforderung ein Token an. Alle Anforderungen müssen das Zugriffstoken enthalten, das vom Bot-Connector-Dienst überprüft wird, um die Anforderung zu autorisieren.

Die beschriebenen Vorgänge werden automatisch vom Bot Framework SDK ausgeführt.

Weitere Informationen finden Sie in der REST-API-Dokumentation zum Authentifizieren von Anforderungen vom Bot-Connector-Dienst an Ihren Bot und Authentifizieren von Anforderungen von Ihrem Bot an den Bot-Connector-Dienst.

Kanäle

In der Regel kommunizieren Kanäle mit einem Bot über den Bot-Connector-Dienst, sodass die vorherigen Authentifizierungsgrundsätze im Allgemeinen gelten. Einige Kanäle und Features weisen eindeutige Authentifizierungsüberlegungen auf.

Direct Line

Neben den standardmäßig unterstützten Kanälen kann eine Clientanwendung mit einem Bot über den Direct-Line-Kanal kommunizieren.

Die Clientanwendung authentifiziert Anforderungen an Direct Line (Version 3.0) entweder mithilfe eines Geheimnisses, das von der Seite Direct Line-Kanalkonfiguration im Azure-Portal abgerufen wird, oder, besser noch, mithilfe eines Tokens, das zur Runtime abgerufen wird. Der geheime Schlüssel oder das Token wird im Autorisierungsheader jeder Anforderung angegeben.

Wichtig

Wenn Sie die Azure KI Bot Service-Authentifizierung mit Webchat verwenden, müssen einige wichtige Sicherheitsaspekte beachtet werden. Weitere Informationen finden Sie im Abschnitt Sicherheitshinweise des Artikels zur REST-Authentifizierung.

Weitere Informationen finden Sie unter Veröffentlichen Sie Ihr Geheimnis nicht, tauschen Sie es gegen ein Token ein, und erstellen Sie den Einbettungscode.

Web-Chat

Die Webchat verfügt über zwei Implementierungen: den Kanal und die Steuerung.

• Wenn Sie einen Bot bei Azure registrieren, wird der Webchat-Kanal automatisch so konfiguriert, dass der Bot getestet werden kann. Weitere Informationen finden Sie unter Verbinden eines Bots mit Webchat.
• Sie können eine Webchat-Steuerung mit dem Direct-Line-Kanal verwenden, um Zugriff auf einen Bot in einer Clientanwendung zu ermöglichen. Weitere Informationen zur Steuerung finden Sie unter Bot-Framework-Webchat.

Fähigkeiten

Ein Skill und ein Skillconsumer sind zwei unterschiedliche Bots, jeweils mit ihrer eigenen App-ID und ihrem Passwort.

• Der Verbraucher kann Benutzeraktivitäten an ein Skill weiterleiten und die Antworten der Skills an den Benutzer weiterleiten.
• Für den Skill fungiert der Skillconsumer als Kanal. Der Consumer hat einen Skill-Host-Endpunkt, der als Service-URL fungiert, an den der Skill Aktivitäten sendet.
• Weitere Informationen zu Skills finden Sie unter Übersicht über Skills.

Die Authentifizierung auf Dienstebene wird vom Bot Connector-Dienst verwaltet. Vom Framework werden Bearertoken und Botanwendungs-IDs verwendet, um die Identität der einzelnen Bots zu bestätigen.

Wichtig

Dies setzt voraus, dass alle Bots (der Skillconsumer und alle Skills, die er konsumiert) über gültige Anmeldedaten verfügen.

Anspruchsüberprüfung

Zusätzlich zu dieser grundlegenden Authentifizierungsstufe müssen Sie der Authentifizierungskonfiguration des Skills und des Skillconsumers einen Anspruchsvalidator hinzufügen. Die Ansprüche werden nach dem Authentifizierungsheader ausgewertet. Mit diesem Prozess kann jeder Bot einschränken, von welchen anderen Bots er Aktivitäten akzeptiert.

Beispiele für die Validierung von Ansprüchen finden Sie unter Implementierung eines Skills und Implementierung eines Skillconsumers.

Bot Framework Emulator

Der Bot Framework Emulator verfügt über einen eigenen Authentifizierungsfluss und seine eigenen Token. Der Emulator verfügt über einen eigenen Kanal und einen integrierten Server.

Benutzerauthentifizierung

Gelegentlich muss ein Bot im Namen des Benutzers auf gesicherte Online-Ressourcen zugreifen. Dazu muss der Bot autorisiert sein. Der Grund dafür ist, dass der Bot für bestimmte Vorgänge wie das Abrufen von E-Mails, die Überprüfung des Flugstatus oder die Aufgabe einer Bestellung einen externen Dienst wie Microsoft Graph, GitHub oder den REST-Dienst eines Unternehmens aufrufen muss. OAuth wird verwendet, um den Benutzer zu authentifizieren und den Bot zu autorisieren.

Hinweis

Zwei Makroschritte sind für einen Bot erforderlich, um auf die Ressourcen eines Benutzers zuzugreifen.

1. Authentifizierung. Der Prozess der Überprüfung der Identität des Benutzers.
2. Autorisierung. Der Prozess der Überprüfung, ob der Bot auf die Ressourcen des Benutzers zugreifen kann.

Wenn der erste Schritt erfolgreich ist, wird ein Token basierend auf den Anmeldeinformationen des Benutzers ausgegeben. Im zweiten Schritt verwendet der Bot das Token für den Zugriff auf die Ressourcen des Benutzers.

Weitere Informationen finden Sie unter Benutzerauthentifizierung.

Identitätsanbieter

Ein Identitätsanbieter authentifiziert Benutzer- oder Clientidentitäten und gibt verwendbare Sicherheitstoken aus. Er bietet Benutzerauthentifizierung als Dienst. Clientanwendungen (beispielsweise Webanwendungen) delegieren die Authentifizierung an einen vertrauenswürdigen Identitätsanbieter.

Ein Bot kann einen vertrauenswürdigen Identitätsanbieter verwenden, um:

• Single Sign-On (SSO)-Funktionen zu aktivieren, damit er auf mehrere gesicherte Ressourcen zugreifen kann.
• im Namen eines Nutzers eine Verbindung zu Cloud-Computing-Ressourcen herzustellen, so dass sich die Benutzer nicht erneut authentifizieren müssen.

Hinweis

Das während der Bot-Authentifizierung ausgegebene Token ist nicht dasselbe Token, das während der Benutzerauthentifizierung ausgegeben wird. Das erste wird verwendet, um eine sichere Kommunikation zwischen einem Bot, Kanälen und letztendlich Clientanwendungen herzustellen. Das zweite wird verwendet, um den Bot für den Zugriff auf gesicherte Ressourcen im Namen des Benutzers zu autorisieren.

Beachten Sie, dass Kanäle eine eigene, separate Benutzerauthentifizierung bereitstellen, damit sich ein Benutzer beim Kanal anmelden kann.

Weitere Informationen dazu, wie Bots mithilfe von Identitätsanbietern im Namen eines Benutzers auf Ressourcen zugreifen können, finden Sie unter Identitätsanbieter,