Freigeben über

Informationen zu Single Sign-On

  • Artikel

GILT FÜR: SDK v4

Single Sign-On (SSO) ermöglicht den Zugriff auf Ressourcen für unabhängige Anwendungen. Beispielsweise könnte sich ein Benutzer bei einem Dienst in einem Stamm-Bot anmelden und der Stamm-Bot könnte das Zugriffstoken mit einem Skill-Bot teilen. Aktuell wird nur der Identitätsanbieter Microsoft Entra ID unterstützt.

SSO ist für folgende Szenarien relevant:

  • Ein Root-Bot und ein oder mehrere Skillbots. Der Benutzer meldet sich vom Stamm-Bot an. Der Bot ruft dann mehrere Skills im Namen des Benutzers auf.
  • Ein Webchat-Steuerelement, das auf einer Website eingebettet ist. Der Benutzer meldet sich auf der Website an. Die Website ruft dann einen Bot oder Skill im Namen des Benutzers auf.

SSO hat folgende Vorteile:

  • Der Benutzer muss sich nicht mehrmals anmelden.
  • Der Stamm-Bot oder die Website muss die Berechtigungen des Benutzers nicht kennen.

Hinweis

SSO ist in Bot Framework SDK Version 4.8 und höher verfügbar.

Interaktion der SSO-Komponenten

Die folgenden Zeitabfolgediagramme geben Aufschluss über die Interaktionen zwischen den verschiedenen SSO-Komponenten.

  • Das folgende Diagramm veranschaulicht den Ablauf für einen Stamm-Bot.

    SSO-Sequenzdiagramm für einen Stamm-Bot.

  • Das folgende Diagramm veranschaulicht den Flow- und Fallback-Flow für ein Webchat-Steuerelement.

    SSO-Sequenzdiagramm für ein Webchat-Steuerelement.

    Wenn der Token-Exchange fehlschlägt, besteht der Fallback darin, den Benutzer aufzufordern, sich anzumelden. Solche Fehler können auftreten, wenn zusätzliche Berechtigungen erforderlich sind oder das Token für den falschen Dienst gilt.

Sehen wir uns den Ablauf etwas genauer an.

  1. Der Client beginnt eine Konversation mit dem Bot und löst dadurch ein OAuth-Szenario aus.

  2. Der Bot gibt eine OAuth-Karte an den Client zurück.

  3. Der Client fängt die OAuth-Karte ab, bevor sie dem Benutzer angezeigt wird, und überprüft, ob sie eine Eigenschaft vom Typ TokenExchangeResource enthält.

  4. Ist die Eigenschaft vorhanden, sendet der Client eine Anforderung vom Typ TokenExchangeInvokeRequest an den Bot. Der Client muss über ein austauschbares Token für den Benutzer verfügen. Dabei muss es sich um ein Microsoft Entra ID-Token handeln, und die Zielgruppe muss der Eigenschaft TokenExchangeResource.Uri entsprechen. Der Client sendet eine Aufrufaktivität (Invoke) mit dem unten gezeigten Text an den Bot.

    {
    "type": "Invoke",
    "name": "signin/tokenExchange",
    "value": {
        "id": "<any unique ID>",
        "connectionName": "<connection Name on the skill bot (from the OAuth Card)>",
        "token": "<exchangeable token>"
    }
}

  5. Der Bot verarbeitet die Anforderung vom Typ TokenExchangeInvokeRequest und gibt eine Antwort vom Typ TokenExchangeInvokeResponse an den Client zurück. Der Client muss auf die Antwort vom Typ TokenExchangeInvokeResponse warten.

    {
    "status": "<response code>",
    "body": {
        "id":"<unique ID>",
        "connectionName": "<connection Name on the skill bot (from the OAuth Card)>",
        "failureDetail": "<failure reason if status code isn't 200, null otherwise>"
    }
}

  6. Wenn in der Antwort vom Typ TokenExchangeInvokeResponse als Status (status) der Wert 200 angegeben ist, wird die OAuth-Karte nicht angezeigt. Dies ist im Diagramm mit dem normalen Ablauf dargestellt. Sollte der Status nicht status lauten oder die Antwort vom Typ TokenExchangeInvokeResponse nicht empfangen werden, wird dem Benutzer die OAuth-Karte angezeigt. Dies ist im Diagramm mit dem Ausweichablauf dargestellt. Dadurch wird sichergestellt, dass der SSO-Flow auf den normalen OAuthCard-Flow zurückfällt, wenn Fehler oder nicht erfüllte Abhängigkeiten, wie die Benutzereinwilligung, vorliegen.

Nächste Schritte

Hinzufügen von Single Sign-On zu einem Bot