Protección de flujos de trabajo del agente conversacional con autenticación sencilla (autenticación de App Service) en Azure Logic Apps (versión preliminar)

Se aplica a: Azure Logic Apps (estándar)

Los flujos de trabajo del agente amplían las opciones de integración porque pueden intercambiar mensajes con autores de llamadas más diversos, como personas, agentes, servidores y clientes del Protocolo de contexto de modelos (MCP), agentes de herramientas y servicios externos. Aunque los flujos de trabajo sin agente interactúan con un pequeño conjunto conocido y fijo de llamantes, los llamantes de agente pueden provenir de redes dinámicas, desconocidas y que no son de confianza. Por lo tanto, debe autenticar y aplicar permisos para cada interlocutor.

Para ayudar a proteger los flujos de trabajo del agente conversacional en producción, configure Easy Auth para autenticar y autorizar llamadas o personas que quieran interactuar con el agente de conversación. La autenticación sencilla, también conocida como autenticación de App Service, proporciona las siguientes funcionalidades que puede usar:

• Proporcione una identidad validada para cada solicitud del autor de la llamada.
• Asigne conexiones a cada usuario.
• Aplicar directivas de acceso condicional.
• Emitir credenciales revocables.
• Conceda permisos basados en principios de privilegios mínimos, roles y ámbitos.
• Proporcione un cliente de chat externo fuera de Azure Portal para que los usuarios puedan interactuar con el agente de conversación.

Estas medidas permiten autenticar y autorizar a cada autor de llamada en un nivel específico y revocar el acceso rápidamente cuando sea necesario. Sin estos controles, corre el riesgo de acceso no controlado, secretos filtrados, como direcciones URL de firma de acceso compartido (SAS) y claves de acceso, pistas de auditoría débiles y otros riesgos de seguridad.

Easy Auth funciona con el identificador de Entra de Microsoft como una capa de seguridad independiente para proporcionar funcionalidades integradas de autenticación y autorización que satisfagan sus necesidades. Con la aplicación de seguridad funcionando fuera del flujo de trabajo, puede centrarse más en el desarrollo de la lógica empresarial. Esta separación de preocupaciones hace que los flujos de trabajo del agente sean más sencillos y más fáciles de compilar, depurar, operar, supervisar, mantener, controlar y auditar.

La seguridad del flujo de trabajo no reactivo suele implicar SAS estáticos, secretos giratorios y controles de límite de red, como restricciones de acceso, listas de direcciones IP permitidas, etiquetas de servicio, integración de red virtual y puntos de conexión privados. Con los flujos de trabajo del agente, diseña la autorización en torno a los usuarios finales, las identidades administradas, las entidades de servicio y sus ámbitos y roles. Este enfoque permite un alcance global más seguro, pero sigue permitiendo que las acciones de flujo de trabajo de nivel inferior respeten los permisos específicos.

En esta guía se muestra cómo crear un registro de aplicación y, a continuación, configurar Easy Auth para tu recurso de aplicación lógica Standard, que puede contener flujos de trabajo de agente y no agente.

Para obtener más información, consulte los artículos siguientes:

• Autenticación y autorización integradas con Easy Auth para flujos de trabajo de agente
• Registro de una aplicación en el identificador de Microsoft Entra

Prerrequisitos

• Una cuenta y una suscripción de Azure. Si no tiene una suscripción, regístrese para obtener una cuenta gratuita de Azure.

• Rol integrado Desarrollador de Aplicaciones de Microsoft Entra en su cuenta de Azure para crear un registro de la aplicación.

• Un recurso de aplicación lógica estándar implementado con un flujo de trabajo del agente conversacional.

  Para más información, consulte Creación de flujos de trabajo de agente conversacional para interacciones de chat en Azure Logic Apps.

• Rol de colaborador de Azure o superior en el recurso de aplicación lógica, con permiso para crear registros de aplicaciones para la entidad de destino mediante Microsoft Entra.

  Importante

  Para configurar Easy Auth, asegúrese de que tiene el rol colaborador de Azure de nivel superior, que difiere del rol Colaborador estándar de Logic Apps .

• (Opcional) Elija si solo admite flujos de usuario con inicio de sesión interactivo o también llamadores que usan una identidad administrada o una entidad de servicio.

  Para más información, consulte Autenticación y autorización en Azure App Service y Azure Functions.

• (Opcional) Un dominio personalizado si desea aplicar URI de redirección específicos para ese dominio.

Crear un registro de aplicación

Para comenzar de la mejor manera la configuración de Easy Auth, cree un registro de aplicación en Microsoft Entra ID directamente desde su recurso de Logic Apps. Si en su lugar tiene que volver a usar un registro de aplicación existente, debe actualizar el registro de la aplicación para que funcione limpiamente con los clientes de Easy Auth y Azure.

1. En el portal de Azure, abra el recurso de aplicación lógica estándar.

2. En el menú de la barra lateral del recurso, en Configuración, seleccione Autenticación.

3. En la página Autenticación, seleccione Agregar proveedor de identidades.

   

   La página Autenticación muestra ahora la pestaña Aspectos básicos para configurar el proveedor de identidades.

4. En la pestaña Aspectos básicos , en Proveedor de identidades, seleccione Microsoft para Microsoft Entra ID.

5. En la sección Registro de aplicaciones, en Tipo de registro de aplicación, seleccione (Recomendado para agentes conversacionales) Crear nuevo registro de aplicaciones, que muestra las opciones correspondientes para esta selección.

6. Proporcione un nombre único para mostrar para el registro de la aplicación, por ejemplo: agent-logic-app-reg-prod

7. En Identidad administrada asignada por el usuario, seleccione Crear nueva identidad administrada asignada por el usuario.

   Puede crear una nueva identidad proporcionando un nombre o seleccionando una identidad existente.

8. En Tipos de cuenta admitidos, seleccione Inquilino actual: inquilino único a menos que quiera aceptar intencionadamente otros inquilinos.

   La configuración de inquilino único hace referencia a las cuentas solo en el directorio organizativo actual. Por lo tanto, todas las cuentas de usuario e invitado de este directorio pueden usar la aplicación o la API. Por ejemplo, si la audiencia de destino es interna para su organización, use esta configuración.

   En el ejemplo siguiente se muestra cómo podría ser un registro de una aplicación:

   

   Importante

   A menos que tenga configuradas directivas explícitas de gobernanza y acceso condicional, no elija Ningún directorio de Microsoft Entra: multiinquilino.

   Para obtener más información, consulte los artículos siguientes:

   • Introducción a la gobernanza de Azure
   • Configuración de la gobernanza en Azure
   • ¿Qué es el acceso condicional?

9. En Comprobaciones adicionales, seleccione los valores siguientes si aún no está seleccionado:

   Configuración	Importancia
   Requisito de la aplicación cliente	Permitir solicitudes solo desde esta propia aplicación
   Requisito de identidad	Permitir solicitudes de identidades específicas
   Identidades permitidas	Aparece solo con Permitir solicitudes de identidades específicas seleccionadas. El valor predeterminado rellenado previamente es el identificador de objeto que representa al usuario actual, a saber, usted mismo. Puede actualizar este valor de las maneras siguientes: - Incluir identificadores de objeto para otros desarrolladores o usuarios. - Use reclamaciones de grupo para incluir un grupo específico, en lugar de identificadores de objeto individuales. Seleccione un registro de aplicación existente para su recurso de aplicación lógica. Si lo haces, asegúrate de actualizar el registro de la aplicación para que funcione limpiamente con Easy Auth. Para obtener más información, consulte Uso de una directiva de autorización integrada.
   Requisito de inquilino	Permitir solicitudes solo desde el inquilino del emisor

10. Omita la sección Rutas de acceso excluidas .

11. Opcionalmente, en Configuración de autenticación de App Service, revise la siguiente configuración y realice las acciones adecuadas:

    Configuración	Acción
    Restringir el acceso	A menos que planee permitir algunos puntos de conexión autenticados, seleccione Requerir autenticación para bloquear todas las solicitudes anónimas.
    Solicitudes no autenticadas	En función de si los autores de llamadas son agentes o basado en agentes, seleccione HTTP 302 Found redirigir: recomendado para agentes.

12. Cuando haya terminado, seleccione Agregar para terminar de agregar el proveedor de identidades.

    Azure crea el registro de la aplicación, actualiza la configuración de la aplicación y habilita el entorno de ejecución de Easy Auth. Cuando Azure termine, la página de Autenticación de la aplicación lógica enumera Microsoft como proveedor de identidades. Los clientes y autores de llamadas ahora deben autenticar sus identidades. La aplicación lógica rechaza clientes y usuarios que realizan llamadas no autenticados como se esperaba y emite una respuesta de redirección 302 Found o una respuesta 401 Unauthorized cuando las solicitudes no incluyen tokens válidos.

    Después de terminar de crear el registro de la aplicación, mantenga la configuración de la aplicación lógica lo más mínima posible hasta que pueda confirmar que la autenticación funciona según lo previsto. Más adelante puede agregar los ámbitos de permisos o roles de aplicación que quiera aplicar; para ello, vaya a las páginas siguientes en el recurso de registro de la aplicación:

    • En la barra lateral de registro de la aplicación, en Administrar, seleccione Exponer una API para agregar un ámbito de permisos. Para obtener más información, vea Agregar un ámbito.

    • En la barra lateral de registro de la aplicación, en Administrar, seleccione Roles de aplicación para asignar un rol de aplicación. Para obtener más información, consulte Asignación de roles de aplicación.

    O bien, puede revisar los pasos correspondientes en la sección siguiente , Actualizar un registro de aplicación existente.

13. Para comprobar que el registro de la aplicación está configurado correctamente, consulta Probar y validar la configuración de la autenticación sencilla.

Usar el registro de aplicaciones existente

Si tiene que volver a usar un registro de aplicación existente que se comparte con otra API o un prototipo anterior, siga estos pasos para revisar y ajustar la configuración especificada para que el registro de la aplicación pueda trabajar limpiamente con los clientes easy Auth y agent.

1. En el cuadro de búsqueda de Azure Portal, busque y seleccione Microsoft Entra ID.

2. En el menú de la barra lateral, en Administrar, seleccione Registros de aplicaciones y, a continuación, busque y seleccione el registro de la aplicación.

3. En el menú de la barra lateral de registro de aplicaciones, expanda Administrar.

4. En Administrar, seleccione Marca y propiedades y confirme que la configuración de la página principal especifica la URL del sitio web de su aplicación lógica.

   Nota:

   La dirección URL de la página principal es opcional para las API de solo back-end o agente. Establezca este valor solo si los usuarios finales necesitan una página de aterrizaje o documentación. Las redirecciones de tokens no usan este valor.

5. En Administrar, seleccione Autenticación.

   1. En Configuraciones de plataforma, asegúrese de que existe la entrada web .

   2. En la entrada Web, en URIs de redirección, busque el URI de devolución de llamada de Easy Auth (Autenticación de App Service) predefinido, que sigue esta sintaxis:

      https://<logic-app-name>.azurewebsites.net/.auth/login/aad/callback

      Mantenga este valor predeterminado a menos que el escenario necesite exponer identificadores de aplicación de API personalizados. Este URI de callback es la audiencia predeterminada del token de acceso y especifica qué recursos pueden aceptar tokens de acceso de clientes que desean acceso a estos recursos.

      El propósito detrás de una audiencia de tokens permitidos es aceptar solo las solicitudes que presentan tokens válidos para estos recursos. Una solicitud de token de acceso implica dos partes: el cliente que solicita el token y el recurso que acepta el token. El destinatario se conoce como el token "audiencia", que es su aplicación lógica en este contexto.

      Para obtener más información, consulte ¿Qué es un URI de redirección?

   3. Si Azure no rellena previamente la configuración URI de redirección, escriba manualmente el URI con el nombre de la aplicación lógica, por ejemplo:

      https://my-chatbox-logic-app.azurewebsites.net/.auth/login/aad/callback

      Importante

      No use URI de redirección personalizados a menos que hospede un front-end interactivo.

   4. Omita la configuración de la URL de cierre de sesión del canal frontal.

   5. En Concesión implícita y flujos híbridos, seleccione las dos opciones siguientes:

      • Tokens de acceso (usados para flujos implícitos)
      • Tokens de identificador (usados para flujos implícitos e híbridos)

      Para más información, consulte la siguiente documentación:

      • Plataforma de identidad de Microsoft y flujo de concesión implícita de OAuth 2.0
      • Solicitud de un token de identificador (flujo híbrido)

   6. En Tipos de cuenta admitidos, seleccione la opción que coincida con la necesidad empresarial.

      En la mayoría de los casos, elija Solo cuentas en este directorio organizativo (solo Microsoft: inquilino único). Para la opción multiinquilino, asegúrese de que tiene configuradas las directivas explícitas de gobernanza de Azure y acceso condicional. Para obtener más información sobre estas opciones, consulte Diferencias de validación por tipos de cuenta admitidos.

   7. En Configuración avanzada, en Permitir flujos de cliente públicos, mantenga la opción No para habilitar los flujos móviles y de escritorio especificados.

      La excepción existe cuando los clientes públicos nativos deben evitar el flujo de credenciales de contraseña del propietario del recurso (ROPC) mediante código de autenticación o dispositivo.

   8. Cuando termine, seleccione Save (Guardar).

6. En Administrar, seleccione Certificados y secretos. En la pestaña Credenciales federadas , configure una nueva identidad administrada asignada por el usuario que tenga acceso a la aplicación lógica para que pueda usar la identidad administrada como una credencial de identidad federada en el registro de la aplicación.

   Si no tiene una identidad administrada asignada por el usuario con acceso a la aplicación lógica, siga estos pasos:

   1. Crear una identidad administrada asignada por el usuario.
   2. Agregue la identidad asignada por el usuario a la aplicación lógica.
   3. Configure la identidad asignada por el usuario como una credencial de identidad federada en el registro de la aplicación.

7. Opcionalmente, si necesita configurar notificaciones como roles, ámbitos, grupos de usuarios o XMS_CC, siga estos pasos:

   1. En Administrar, seleccione Configuración del token.

   2. En la sección Reclamaciones opcionales, agregue sus reclamaciones.

      Nota:

      Para evitar el exceso de tokens, configure verificaciones de roles o ámbitos, en lugar de claims de grupo grandes.

8. En Administrar, seleccione Permisos de API y siga estos pasos:

   1. En Permisos configurados, seleccione Agregar un permiso.
   2. En el panel Solicitar permisos de API , en la pestaña API de Microsoft , busque y seleccione Microsoft Graph.
   3. Para el tipo de permisos, seleccione Permisos delegados.
   4. En el cuadro Seleccionar permisos , escriba User.Read.
   5. En la columna Permiso , expanda Usuario y seleccione el permiso User.Read .

   Para obtener más información, consulte Agregar permisos para acceder a Microsoft Graph.

9. Opcionalmente, en Administrar, seleccione Exponer una API para que pueda definir y exponer ámbitos de permisos.

   Para la configuración del URI de ID de Aplicación, el URI rellenado previamente es un identificador único que representa el recurso de la aplicación lógica como destinataria en los tokens de acceso y utiliza el siguiente formato:

   api://<application-client-ID>

   En la sección Ámbitos definidos por esta API , si desea confiar solo en la validación de roles y audiencias, no tiene que definir ni exponer ningún ámbito de permiso. Sin embargo, si desea que los clientes de Azure soliciten permisos delegados, defina estos ámbitos siguiendo estos pasos:

   1. Seleccione Agregar un ámbito y proporcione la siguiente información:

      Configuración	Obligatorio	Importancia
      Nombre de ámbito	Sí	user_impersonation
      ¿Quién puede dar el consentimiento?	Sí	Administradores y usuarios
      Nombre para mostrar del consentimiento del administrador	Sí	Etiqueta o nombre del ámbito de permiso que muestra el mensaje de consentimiento cuando los administradores del arrendatario dan su consentimiento para el ámbito. Por ejemplo: Acceso a <logic-app-name>
      Definición del consentimiento del administrador	Sí	Descripción detallada del ámbito de permiso que muestra la pantalla de consentimiento cuando los administradores de inquilinos expanden el ámbito en la pantalla de consentimiento. Por ejemplo: Permitir que la aplicación acceda <a logic-app-name> en nombre del usuario que ha iniciado sesión.
      Nombre para mostrar del consentimiento del usuario	No	Nombre opcional para el ámbito de permiso que muestra la pantalla de consentimiento cuando los usuarios finales proporcionan su consentimiento para este ámbito. Por ejemplo: Acceso a <logic-app-name>
      Definición de consentimiento del usuario	No	Descripción detallada opcional del ámbito de permiso que muestra la pantalla de consentimiento cuando los usuarios finales expanden el ámbito en la pantalla de consentimiento. Por ejemplo: Permita que la aplicación acceda <a logic-app-name> en su nombre.
      Estado	Sí	Enabled

   2. Cuando termine, seleccione Agregar ámbito.

   3. En la lista Ámbitos, revise la configuración de ámbito actualizada para confirmar que aparecen según lo esperado.

10. Al terminar de actualizar el registro de aplicación, vaya al recurso de aplicación lógica estándar.

11. En la barra lateral de la aplicación lógica, en Configuración, seleccione Autenticación.

12. En la página Autenticación , junto a Configuración de autenticación, seleccione Editar para revisar la configuración. En el panel Editar configuración de autenticación , confirme los valores siguientes:

Prueba y validación de la configuración de Easy Auth

Después de configurar Easy Auth, la interfaz de chat interna de la página Chat del flujo de trabajo en Azure Portal deja de estar disponible. En su lugar, debe interactuar con el agente conversacional mediante el cliente de chat externo que está disponible fuera de Azure Portal. Para confirmar que Easy Auth funciona según lo previsto, realice las pruebas en el cliente de chat externo siguiendo estos pasos:

1. En la barra de herramientas del diseñador o en la barra lateral del flujo de trabajo, seleccione Chat.

   La interfaz de chat interna ya no aparece en la página Chat .

2. En la sección Essentials , seleccione el vínculo Dirección URL del cliente de chat , que abre una nueva pestaña del explorador.

3. En el mensaje de solicitud de permisos, proporcione su consentimiento y acepte la solicitud.

   

   La página del explorador se actualiza y muestra la interfaz del cliente de chat externo.

   Sugerencia

   También puede insertar la dirección URL del cliente de chat en un elemento HTML de iFrame que puede usar con su sitio web donde desea proporcionar el cliente de chat, por ejemplo:

   <iframe src="https:/<logic-app-name>.azurewebsites.net/api/agentsChat/<workflow-name>/IFrame" title="<chat-client-name>"></iframe>

4. En la interfaz de chat externo, inicie o continúe interactuando con el agente de conversación.

5. Para revisar el historial de ejecución del flujo de trabajo, siga estos pasos:

   1. Vuelva al flujo de trabajo en Azure Portal.

   2. En la barra lateral del flujo de trabajo, en Herramientas, seleccione Historial de ejecución y, a continuación, seleccione la ejecución del flujo de trabajo más reciente.

   3. En la vista de supervisión, confirme que el historial de ejecución y los estados de la operación aparecen según lo previsto.

Solución de errores durante las pruebas de autenticación sencilla

En la tabla siguiente se describen los problemas comunes que pueden surgir al configurar Easy Auth, posibles causas y acciones que puede realizar:

Uso de una identidad en el flujo de trabajo

Cuando Easy Auth valida una solicitud, Easy Auth inserta datos de identidad en encabezados de solicitud basados en el proveedor de identidades. La aplicación lógica usa estos encabezados para autenticar al autor de la llamada.

Para obtener más información, consulte los artículos siguientes:

• Tokens de OAuth para App Service
• Tutorial: Autenticación y autorización de usuarios de extremo a extremo en Azure App Service

Contenido relacionado

• Autenticación y autorización en flujos de trabajo del agente de IA