Tipos de autenticación

SE APLICA A: SDK v4

En Bot Framework, existen dos categorías de autenticación generales: autenticación del bot y autenticación de usuarios. Cada una tiene un token asociado para permitir el acceso a los recursos protegidos. En la ilustración siguiente se muestran los elementos implicados en la autenticación del bot y de usuarios.

Diagram illustrating the difference between the token for a bot and the token for a user.

En esta ilustración:

  • Host Platform es la plataforma de hospedaje del bot. Puede ser Azure o cualquier plataforma host que elija.
  • El servicio Bot Connector facilita la comunicación entre un bot y un canal. Convierte los mensajes recibidos de los canales en objetos de actividad y los envía al punto de conexión de mensajería del bot. Del mismo modo, convierte los objetos de actividad recibidos del bot en mensajes que comprende el canal y los envía al canal.
  • Bot Adapter es el adaptador predeterminado de Bot Framework. Este:
    • Convierte la carga JSON en un objeto de actividad.
    • Crea un contexto de turno y agrega el objeto de actividad al mismo.
    • Ejecuta el middleware, si lo hubiera.
    • Reenvía el contexto de turno al bot.

Nota:

Cuando se usa un adaptador de canal personalizado, el propio adaptador realiza las tareas que realiza el servicio Bot Connector y el adaptador de bot predeterminado. Además, proporciona el mecanismo de autenticación para la API de webhook relacionada. Para ver un ejemplo, consulte Conexión de un bot a Slack mediante el adaptador de Slack.

Autenticación del bot

Un bot se identifica mediante su MicrosoftAppID y MicrosoftAppPassword, que se guardan en los archivos de configuración del bot (appsettings.json (.NET), .env (JavaScript), config.py (Python)) o en un administrador de secretos o claves. Para obtener más información, consulte MicrosoftAppID y MicrosoftAppPassword.

Al registrar un bot en Azure Portal, Azure crea una aplicación de registro de Microsoft Entra ID. Si usa la CLI de Bot Framework, debe realizar específicamente un paso para crear el registro de Microsoft Entra ID. Este registro tiene un identificador de aplicación (MicrosoftAppID) y un secreto de cliente (MicrosoftAppPassword). Azure usa estos valores para generar un token con el que el bot puede acceder a recursos seguros.

Cuando un canal envía una solicitud al bot a través del servicio Bot Connector, especifica un token en el encabezado de autorización de la solicitud. El bot autentica las llamadas desde el servicio Bot Connector mediante la verificación de la autenticidad del token.

Cuando el bot envía una solicitud a un canal a través del servicio Bot Connector, debe especificar el token en el encabezado de autorización de la solicitud. Todas las solicitudes deben incluir el token de acceso, que verifica el servicio Bot Connector para autorizar la solicitud.

El SDK de Bot Framework realiza automáticamente las operaciones descritas.

Para obtener más información, consulte la documentación de la API de REST sobre cómo autenticar las solicitudes del servicio Bot Connector en el bot y autenticar las solicitudes del bot en el servicio Bot Connector.

Canales

Normalmente, los canales se comunican con un bot a través del servicio Bot Connector, por lo que los principios de autenticación anteriores se aplican generalmente. Algunos canales y características tienen consideraciones de autenticación únicas.

Direct Line

Además de los canales estándar admitidos, una aplicación cliente puede comunicarse con un bot mediante el canal de Direct Line.

La aplicación cliente autentica las solicitudes en Direct Line (versión 3.0) ya sea mediante un secreto, que se obtiene en la página de configuración del canal de Direct Line en Azure Portal, o mediante un token, que se obtiene en el tiempo de ejecución. El secreto o token se especifica en el encabezado de autorización de cada solicitud.

Importante

Cuando se usa la autenticación de Azure AI Bot Service con Chat en web hay algunos aspectos de seguridad importantes que debe tener en cuenta. Para más información, consulte la sección Consideraciones de seguridad del artículo de autenticación REST.

Para obtener más información, consulte Mantener el secreto oculto, intercambiar el secreto por un token y generar la inserción.

Chat en web

El Chat en web tiene dos implementaciones: el canal y el control .

  • Cuando se registra un bot con Azure, el canal Chat en web se configura automáticamente para permitir las pruebas del bot. Para obtener más información, consulte Conexión de un bot a un Chat en web.
  • Puede usar un control de Chat en web con el canal de Direct Line para proporcionar acceso a un bot en una aplicación cliente. Para obtener más información, consulte Chat en web de Bot Framework.

Aptitudes

Una capacidad y un consumidor de capacidades son dos bots distintos, cada uno con su propio identificador de aplicación y contraseña.

  • El consumidor puede reenviar las actividades del usuario a una capacidad y las respuestas de la capacidad al usuario.
  • Para la capacidad, el consumidor de capacidades actúa como un canal. El consumidor tiene un punto de conexión de host de capacidad que actúa como la dirección URL del servicio a la que la capacidad envía las actividades.
  • Para obtener más información sobre las capacidades, consulte el resumen de capacidades.

El servicio Bot Connector administra la autenticación en el nivel de servicio. Este servicio usa tokens de portador e identificadores de aplicación de bot para comprobar la identidad de cada bot.

Importante

Esto requiere que todos los bots (el consumidor de capacidades y las capacidades que consume) tengan unas credenciales de aplicación válidas.

Validación de notificaciones

Además de este nivel básico de autenticación, debe agregar un validador de notificaciones a la configuración de autenticación de la capacidad y al consumidor de capacidades. Las notificaciones se evalúan después del encabezado de autenticación. Este proceso permite a cada bot restringir de qué otros bots aceptará actividades.

Para la validación de notificaciones de ejemplo, consulte cómo implementar una capacidad e implementar un consumidor de capacidades.

Bot Framework Emulator

Bot Framework Emulator tiene su propio flujo de autenticación y sus propios tokens. El emulador tiene su propio canal y un servidor integrado.

Autenticación de usuarios

A veces, un bot debe acceder a recursos en línea protegidos en nombre del usuario. Para ello, el bot debe estar autorizado. El motivo es que, para realizar determinadas operaciones, como comprobar el correo electrónico, comprobar el estado de un vuelo o realizar un pedido, el bot deberá llamar a un servicio externo, como Microsoft Graph, GitHub o un servicio REST de la empresa. Se utiliza OAuth para autenticar al usuario y autorizar al bot.

Nota:

Hay dos pasos de macro implicados para que un bot acceda a los recursos de un usuario.

  1. Autenticación. Proceso de verificación de la identidad de un usuario.
  2. Autorización. Proceso de verificación de que el bot pueda acceder a los recursos del usuario.

Si el primer paso es correcto, se emite un token basado en las credenciales del usuario. En el segundo paso, el bot usa el token para acceder a los recursos del usuario.

Para más información, consulte Autenticación de usuario.

Proveedores de identidades

Un proveedor de identidades autentica identidades de clientes o usuarios y emite tokens de seguridad que se pueden consumir. Proporciona la autenticación de usuario como servicio. Las aplicaciones cliente, como las aplicaciones web, delegan la autenticación en un proveedor de identidades de confianza.

Un bot puede usar un proveedor de identidades de confianza para:

  • Habilitar características de inicio de sesión único (SSO), lo que le permite acceder a varios recursos protegidos.
  • Conectarse a los recursos de informática en la nube en nombre de un usuario, lo que reduce la necesidad de que los usuarios vuelvan a autenticarse.

Nota:

El token emitido durante la autenticación del bot no es el mismo token emitido durante la autenticación de usuarios. La primera se usa para establecer una comunicación segura entre un bot, los canales y, en última instancia, las aplicaciones cliente. El segundo se usa para autorizar al bot a acceder al recurso protegido en nombre del usuario.

Tenga en cuenta que los canales proporcionan su propia autenticación de usuarios independiente para permitir que un usuario inicie sesión en el canal.

Consulte Proveedores de identidades para obtener más información sobre cómo los bots pueden usar proveedores de identidades para acceder a los recursos en nombre de un usuario.