Crear una integración HTTP

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

Para crear la integración HTTP, haga lo siguiente:

  1. En la página de descripción general de las microaplicaciones, seleccione Introducción o Administrar.

    Se abrirá la página Integraciones de microaplicaciones.

  2. Seleccione Agregar integración.
  3. Elija Crear una nueva integración para el servicio web HTTP para agregar los detalles de configuración.

    Mosaico HTTP

  4. 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).

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.

Instancia local (Tech Preview)

Las microaplicaciones también le permiten conectar su sistema de registro local (SoR).

Si está creando una conexión local, conéctese primero mediante el dispositivo Citrix Cloud Connector

Para encontrar este, inicie sesión en Citrix Cloud.

  1. Seleccione Modificar o agregar en la ficha Ubicación de recursos.
  2. Busque su recurso de microaplicaciones en la lista.
  3. Haga clic en ID.
  4. Copie el identificador del recurso en la ubicación de recursos local en las microaplicaciones: Su integración local está configurada.

Tenga en cuenta

que la función local habilitada solo se proporciona actualmente como una vista previa técnica. La función local está oculta de forma predeterminada y debe habilitarse en el panel de operaciones de Citrix Cloud con el nombre de función del dispositivo conector. Una vez que ha habilitado esta función, el cambio se propaga en menos de una hora (almacenamiento en caché de las funciones habilitadas en el lado de Citrix). Actualmente, la función local admite solo la integración de HTTP y las integraciones Jira, y solo se admite el protocolo HTTPS para la comunicación con el sistema de registro (SoR).

Qué hacer a continuación

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