Microaplicaciones

Crear una integración HTTP

Ahora que ha identificado sus API, vamos a agregar la integración HTTP al servicio de microaplicaciones.

  1. En la página Integraciones de microaplicaciones, seleccione Agregar integración.
  2. Elija Crear una nueva integración para el servicio web HTTP para agregar los detalles de configuración.

    Mosaico HTTP

  3. Asigne un nombre a su integración e introduzca la URL base que recopiló. La URL base es la parte integrante de su dirección web que utilizará para esta integración.

    Solo se puede agregar una URL base por integración. Si necesita más URL base, debe crear otras integraciones.

Nota:

Aunque HTTP y HTTPS están permitidos como URL base, HTTP se considera un método de conexión mucho menos seguro, y es poco probable que lo utilice para su aplicación de integración de destino.

Por ejemplo:

Nombre: Integración de Asana

URL base: https://app.asana.com/api/1.0/workspaces/${YOUR_WORKSPACE_ID}

Nota:

Sustituya ${YOUR_WORKSPACE_ID} por su ID de espacio de trabajo (por ejemplo, 419224638481718).

Instancia local

El servicio de microaplicaciones también permite conectar su sistema de registro local (SoR). Para crear una conexión local, conéctese en primer lugar utilizando el dispositivo Connector y, a continuación, siga este procedimiento para recopilar y agregar el identificador de recurso. Para obtener más información, consulte dispositivo Citrix Cloud Connector.

  1. Vaya a Citrix Cloud e inicie sesión con sus credenciales.
  2. Después de iniciar sesión en Citrix Cloud, seleccione Ubicaciones de recursos en el menú.
  3. Seleccione el icono de agregar + y busque su recurso de microaplicaciones en la lista.
  4. Seleccione ID y copie el identificador de recurso en el campo Ubicación de recursos de instancia local de la pantalla Agregar integración HTTP.

La integración local está configurada.

Configurar autenticación del servicio

Al configurar la autenticación del servicio de integración HTTP, ha configurado su cuenta de servicio con la aplicación de destino y cuenta con las credenciales necesarias según los requisitos de la aplicación de destino. Después de haber recopilado toda la información necesaria en su aplicación de destino (inicio de sesión, contraseñas, credenciales de seguridad, etc.), puede comenzar el proceso de integración del servicio.

Seleccione un método de autenticación entre los siguientes:

  • Ninguno: No se necesitan credenciales de seguridad.
  • Básico: Utilice el nombre de usuario y la contraseña de la aplicación de destino para la autenticación.
  • NTLM: Configure su integración HTTP para utilizar un conjunto de protocolos de Microsoft para conectarse a través del servidor de autenticación de New Technology LAN Manager (NTLM) para autenticar usuarios NTLM con las credenciales de Microsoft Windows.
  • Portador: Configure el esquema de autenticación de la integración de destino para usar tokens de portador generados por el servidor en respuesta a una solicitud de inicio de sesión.
  • OAuth 2.0: Utilice el protocolo de seguridad OAuth 2.0 para generar tokens de solicitud/autorización para el acceso delegado. La implementación de OAuth 2.0 varía de un sistema a otro, pero el flujo de trabajo general con OAuth 2.0 funciona como se describe a continuación.
  • Claves API: Utilice el método Claves API para autenticar a un usuario, desarrollador o programa de llamada a una API.

Nota:

Se recomienda utilizar OAuth 2.0 como método de autenticación del servicio siempre que esté disponible. OAuth 2.0 garantiza que la integración es conforme a los requisitos de seguridad más estrictos con la microaplicación configurada.

Siga estos pasos:

  1. Introduzca los parámetros de autenticación del servicio para la integración.
  2. (Opcional) Para el tipo de concesión Código de autorización, seleccione Iniciar sesión con su cuenta de servicio y espere a que se complete el inicio de sesión.
  3. (Opcional) Seleccione el botón de opción Autenticación de acción de servicio e introduzca los parámetros de autenticación en el nivel de acción de servicio.

    Importante:

    Si utiliza permisos delegados, es posible que no tenga pleno acceso. En este caso, utilice Autenticación de acción de servicio para autenticarse en el nivel de acción de servicio. En esta situación, puede utilizar la autenticación básica en el nivel de servicio, pero deberá utilizar OAuth 2.0 en el nivel de acción de servicio por motivos de seguridad.

  4. Seleccione Agregar.

Autenticación OAuth 2.0

OAuth 2.0 permite a las aplicaciones obtener acceso específico a las cuentas de usuario del servicio HTTP en aplicaciones de terceros. Funciona delegando la autenticación en el servicio que contiene la cuenta de usuario y, a continuación, autoriza a las aplicaciones de terceros a acceder a esa cuenta de usuario.

URL de respuesta OAuth

Las URL de respuesta para la autenticación siguen este patrón:

https://{id_cliente}.{geo_cliente}.iws.cloud.com/admin/api/gwsc/auth/serverContext,
https://{id_cliente}.{geo_cliente}.iws.cloud.com/app/api/auth/serviceAction/callback

La segunda parte de esta URL solo se utiliza cuando se definen acciones autenticadas por el usuario. Los identificadores geográficos y de cliente son variables y únicos de cada cliente.

Tipos de concesión de OAuth 2.0

La integración HTTP le permite seleccionar entre tres tipos de concesión. Al configurar OAuth 2.0, seleccione el tipo de concesión en el menú. Al configurar OAuth 2.0, recomendamos que utilice el código de autorización, ya que este es el flujo de concesión más seguro. Utilice los tipos de concesión Credenciales de cliente y Contraseña del propietario del recurso si los necesita como métodos adicionales de autenticación de acciones de servicio:

  • Código de autorización: Concede un código temporal que el cliente intercambia por un token de acceso. El código se obtiene del servidor de autorización, donde se puede ver la información que solicita el cliente. Solo este tipo de concesión permite la suplantación segura de usuarios.
  • Credenciales de cliente: Este tipo de concesión se utiliza para obtener un token de acceso fuera del contexto de un usuario. Lo utilizan los clientes para acceder a sus propios recursos, en lugar de acceder a los recursos de un usuario.
  • Contraseña del propietario del recurso: Proporciona las credenciales correctas para autorizar la provisión de un token de acceso del servidor de recursos.

Entradas de tipo de concesión

Dependiendo del tipo de concesión definido anteriormente, se le ofrecerán las siguientes opciones para habilitar la autenticación OAuth 2.0:

  • URL de token: Define la URL del token de autorización de acceso.
  • Ámbito: Define el ámbito de la solicitud de acceso, que es una cadena definida por el servidor de autorización al configurar la aplicación de integración de destino.
  • ID de cliente: Define la cadena que representa la información de registro del cliente exclusiva del servidor de autorización.
  • Secreto del cliente: Define la cadena única emitida al configurar la integración de la aplicación de destino.
  • Nombre de usuario: Define el nombre de usuario de su cuenta en la aplicación de destino.
  • Contraseña: Define la contraseña de su cuenta en la aplicación de destino.
  • URL de autorización: Define la URL del servidor de autorización proporcionada al configurar la integración de la aplicación de destino.
  • Parámetros de token de acceso: Define los parámetros del token de acceso según lo requiera el servidor de autorización de aplicaciones de destino.
  • Iniciar sesión con su cuenta de servicio: Inicia sesión en la cuenta de servicio del servidor de autorización de su aplicación de destino.
  • Prefijo de encabezado: (Optativo) Introduzca el prefijo de encabezado si el prefijo de portador es distinto del encabezado predeterminado.

Se pueden encontrar recursos adicionales con respecto a OAuth 2.0 en la página solicitud de preguntas de OAuth 2.0.

Solución de problemas de OAuth 2.0

Si tiene problemas para conectar su aplicación de destino a la plataforma de microaplicaciones, compruebe los siguientes errores y soluciones con respecto a su propia configuración:

  • invalid_request: (solicitud_no_válida) Su solicitud de autorización puede omitir un parámetro requerido, contener un valor de parámetro (u otro tipo de concesión) no admitido, un parámetro repetido, incluir varias credenciales, utilizar más de un mecanismo para autenticar un cliente.
  • invalid_client: (cliente_no_válido) Error de autenticación del cliente por los siguientes motivos: cliente desconocido, no se incluye autenticación de cliente o método de autenticación no admitido. El servidor de autorización puede devolver un código de estado HTTP 401 (no autorizado) para indicar qué esquemas de autenticación HTTP son compatibles.
  • invalid_grant: (concesión_no_válida) El token de autorización o actualización puede no ser válido, estar caducado, haber sido revocado o no coincidir con el URI de redirección utilizado en la solicitud de autorización que se emitió para otro cliente.
  • unauthorized_client: (cliente_no_autorizado) El cliente autenticado no está autorizado a utilizar este tipo de concesión de autorización.
  • unsupported_grant_type: (tipo_de_concesión_no_admitido) El servidor de autorización no admite el tipo de concesión de autorización.
  • invalid_scope: (ámbito_no_válido) El ámbito solicitado no es válido, es desconocido, está mal formado o supera el ámbito concedido por el propietario del recurso.

Si sigue teniendo problemas para configurar OAuth 2.0, compruebe que ha introducido la URL correcta para URL de token y autorización, ya que ambas son únicas. Vuelva a comprobar también que sus otras entradas son correctas, como Ámbito, etc. Si los problemas persisten, compruebe la configuración en el lado del servidor de aplicaciones integradas.

Limitación de solicitudes (opcional)

Puede seleccionar la limitación de solicitudes para su integración. Al activar esta opción, puede definir el número de solicitudes y el intervalo de tiempo (1 segundo o 1 minuto) extraído de la aplicación de destino. Configure la limitación siguiendo las prácticas recomendadas/límites Indicados en la documentación de la aplicación de destino.

Escuchas de webhooks

Configure las escuchas de webhook (también conocidas como API de inserción HTTP) para permitir que sus microaplicaciones proporcionen datos casi en tiempo real a los usuarios finales. La configuración de un webhook permite a sus aplicaciones entregar datos a otras aplicaciones a una velocidad mucho mayor que la sincronización desde el lado de la plataforma de microaplicaciones. Para agregar escuchas, debe estar familiarizado con la aplicación de destino “Sistema de registro” (SoR) y tener las herramientas y los privilegios de administración necesarios definidos para configurar sus webhooks en esas ubicaciones.

Configure sus webhooks después de haber configurado su integración a través de Carga de datos y siga estos pasos:

  1. Haga clic en Escuchas de webhooks en la barra izquierda de la pantalla Integración HTTP:

    Escuchas de webhooks

  2. Introduzca el nombre del webhook deseado.
  3. Seleccione Copiar para copiar la URL del webhook que se utilizará en la interfaz de administración del sistema de registro de destino.

Método de autorización

Al configurar el método de autorización, puede seleccionar Token o Ninguno. Para configurar el método Token siga estos pasos:

  1. Seleccione Token en el menú Método de autorización.
  2. Seleccione Generar token y, a continuación, Copiar para agregar el token al portapapeles y usarlo en la interfaz de administración del sistema de registro de destino.
  3. Seleccione Leer token de para elegir:
    • Encabezado personalizado
    • Parámetro de la consulta
    • Encabezado de la autorización
  4. Defina el Nombre o el Prefijo según el método de lectura seleccionado.

El token ya está configurado.

Definir estructura de datos

Puede definir la estructura de datos siguiendo un método similar al descrito al Obtener estructura de datos durante la configuración de Carga de datos. Para obtener más información, consulte Configurar la integración.

Para definir la estructura de datos de webhook, siga estos pasos:

  1. Establezca el período de retención de datos deseado.
  2. Seleccione Generar tablas.

    Se abrirá la pantalla Generar tablas.

    Pegue su solicitud de muestra JSON desde la aplicación de destino Sistema de registro (SoR) aquí.

  3. Establezca el nombre base de las tablas creadas.
  4. (Opcional) Establezca la ruta de acceso raíz si es necesario.
  5. Seleccione Generar.

Con este proceso completado, junto con las medidas de configuración en la administración de la aplicación de destino Sistema de registro, seleccione Agregar.

Su webhook ahora está configurado.

Qué hacer a continuación

Ahora que ha creado la integración HTTP, configure la integración:

Crear una integración HTTP