Acerca del inicio de sesión único

  • Artículo

SE APLICA A: SDK v4

El inicio de sesión único (SSO) permite compartir recursos entre aplicaciones independientes. Por ejemplo, un usuario podría iniciar sesión en un servicio de un bot raíz y el bot raíz podría compartir el token de acceso con un bot de capacidad. Actualmente, solo se admite el proveedor de identidades de Microsoft Entra ID.

El inicio de sesión único se aplica en los siguientes escenarios:

  • Un bot raíz y uno o varios bots de capacidad. El usuario inicia sesión desde el bot raíz. A continuación, el asistente invoca varias capacidades en nombre del usuario.
  • Un control de Chat en web incrustado en un sitio web. El usuario inicia sesión en el sitio web. A continuación, el sitio web invoca un bot o una capacidad en nombre del usuario.

El inicio de sesión único ofrece las siguientes ventajas:

  • El usuario no tiene que iniciar sesión varias veces.
  • El bot raíz o el sitio web no necesita conocer los permisos del usuario.

Nota:

El inicio de sesión único está disponible en la versión 4.8 del SDK de Bot Framework y versiones posteriores.

Interacción de los componentes del inicio de sesión único

Los siguientes diagramas de secuencia de tiempo muestran las interacciones entre los distintos componentes del inicio de sesión único.

  • En el diagrama siguiente, se muestra el flujo de un bot raíz:

    SSO sequence diagram for a root bot.

  • En el diagrama siguiente se muestra el flujo y el flujo de reserva de un control de Chat en web.

    SSO sequence diagram for a Web Chat control.

    Si se produce un error en el intercambio de tokens, el retroceso consiste en pedir al usuario que inicie sesión. Estos errores pueden producirse cuando se requieren permisos adicionales o el token es para el servicio incorrecto.

Vamos a analizar el flujo.

  1. El cliente inicia una conversación con el bot que desencadena un escenario de OAuth.

  2. El bot envía una tarjeta de OAuth al cliente.

  3. El cliente intercepta la tarjeta de OAuth antes de mostrarla al usuario y comprueba si contiene la propiedad TokenExchangeResource.

  4. Si la propiedad existe, el cliente envía una solicitud TokenExchangeInvokeRequest al bot. El cliente debe tener un token intercambiable para el usuario, que debe ser un token de Microsoft Entra ID y cuya audiencia debe ser la misma que la de la propiedad TokenExchangeResource.Uri. El cliente envía una actividad Invoke al bot con el cuerpo que se muestra a continuación.

    {
    "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. El bot procesa la solicitud TokenExchangeInvokeRequest y devuelve una respuesta TokenExchangeInvokeResponse al cliente. El cliente debe esperar hasta que reciba la respuesta TokenExchangeInvokeResponse.

    {
    "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. Si TokenExchangeInvokeResponse tiene una propiedad status con el valor 200, el cliente no muestra la tarjeta de OAuth. Consulte el diagrama del flujo normal. Para cualquier otro valor de status o si no se recibe la respuesta TokenExchangeInvokeResponse, el cliente muestra la tarjeta de OAuth al usuario. Consulte el diagrama del flujo de reserva. Esto garantiza que el flujo de SSO recurre al flujo de OAuthCard normal en el caso de que se produzcan errores o no se hayan cumplido algunas dependencias, como el consentimiento del usuario.

Pasos siguientes

Adición del inicio de sesión único a un bot