Créer une intégration HTTP

Une fois vos API identifiées, ajoutez l’intégration HTTP aux micro-apps.

Pour créer l’intégration HTTP, procédez comme suit :

  1. Dans la page de vue d’ensemble des micro-apps, sélectionnez Démarrer ou Gérer.

    La page Intégrations de micro-apps s’ouvre.

  2. Sélectionnez Ajouter une intégration.
  3. Choisissez Créer une intégration à votre service Web HTTP pour ajouter les détails de configuration.

    Vignette HTTP

  4. Donnez un nom à votre intégration et entrez l’URL de base que vous avez obtenue. L’URL de base est la partie cohérente de votre adresse Web que vous utilisez pour cette intégration.

    Vous ne pouvez ajouter qu’une seule URL de base par intégration. Si vous avez besoin de plus d’URL de base, vous devez créer une autre intégration.

Remarque :

Bien que les protocoles HTTP et HTTPS soient tous deux autorisés comme URL de base, le protocole HTTP est considéré comme une méthode de connexion beaucoup moins sécurisée. Il est donc peu probable que vous l’utilisiez pour votre application d’intégration cible.

Par exemple :

Nom : Intégration Asana

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

Remarque :

Remplacez ${YOUR_WORKSPACE_ID} par votre ID d’espace de travail (par ex. 419224638481718) dans cet exemple.

Configurer l’authentification de service

Lors de la configuration de l’authentification de votre service d’intégration HTTP, vous avez configuré votre compte de service avec votre application cible et possédez les informations d’identification nécessaires conformément aux exigences de votre application cible. Après avoir rassemblé toutes les informations nécessaires sur votre application cible (nom de connexion, mot de passe, informations d’identification de sécurité, etc.), vous pouvez commencer le processus d’intégration des services.

Sélectionnez votre méthode d’authentification parmi les options suivantes :

  • Aucune : aucune information d’identification de sécurité n’est nécessaire.
  • Authentification de base : utilisez votre nom d’utilisateur et votre mot de passe associés à l’application cible pour l’authentification.
  • NTLM : configurez votre intégration HTTP de manière à utiliser une suite de protocoles Microsoft pour se connecter via le serveur d’authentification NTLM (New Technology LAN Manager) afin d’authentifier les utilisateurs NTLM via les informations d’identification Microsoft Windows.
  • Authentification par jeton : configurez le schéma d’authentification de l’intégration cible de manière à utiliser les jetons du porteur générés par le serveur en réponse à une demande de connexion.
  • OAuth 2.0: utilisez le protocole de sécurité OAuth 2.0 pour générer des jetons de demande/autorisation pour l’accès délégué. La mise en œuvre d’OAuth 2.0 varie d’un système à l’autre, mais le workflow général pour OAuth 2.0 fonctionne comme décrit ci-dessous.
  • Clés API : utilisez cette méthode pour authentifier un utilisateur, un développeur ou un programme appelant une API.

Remarque :

Il est recommandé de toujours utiliser OAuth 2.0 comme méthode d’authentification de service lorsque cette méthode est disponible. OAuth 2.0 garantit que votre intégration respecte la conformité maximale en matière de sécurité avec votre micro-app configurée.

Procédez comme suit :

  1. Entrez les paramètres Service d’authentification associés à l’intégration.
  2. (Facultatif) Pour le type d’octroi du code d’autorisation, sélectionnez Se connecter avec compte de service et attendez que la connexion se termine.
  3. (Facultatif) Sélectionnez le bouton radio Authentification de l’action de service et entrez les paramètres d’authentification au niveau de l’action de service.

    Important :

    Si vous utilisez des autorisations déléguées, vous ne disposez peut-être pas d’un accès complet. Dans ce cas, utilisez l’option Authentification de l’action de service pour vous authentifier au niveau de l’action de service. Dans ce cas, vous pouvez utiliser l’authentification de base au niveau du service, mais vous devez utiliser OAuth 2.0 au niveau de l’action de service pour des raisons de sécurité.

  4. Sélectionnez Ajouter.

Authentification OAuth 2.0

OAuth 2.0 permet aux applications d’obtenir un accès spécifique aux comptes utilisateur de service HTTP sur des applications tierces. Cette méthode fonctionne en déléguant l’authentification au service qui contient le compte utilisateur, puis en autorisant les applications tierces à accéder à ce compte utilisateur.

Adresses URL de rappel OAuth

Les adresses URL de rappel pour l’authentification suivent ce modèle :

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

La deuxième partie de cette adresse URL est utilisée uniquement lors de la définition d’actions authentifiées par utilisateur. Les identificateurs de client et géographiques sont variables et uniques à chaque client.

Types d’octroi OAuth 2.0

L’intégration HTTP vous permet de sélectionner parmi trois types d’octroi. Lorsque vous configurez OAuth 2.0, sélectionnez le type d’octroi souhaité dans le menu. Lors de la configuration d’OAuth 2.0, nous vous recommandons d’utiliser le code d’autorisation car il s’agit du flux d’octroi le plus sécurisé. Utilisez les types d’octroi Informations d’identification client et Mot de passe du propriétaire de la ressource si vous en avez besoin pour utiliser des méthodes d’authentification d’action de service supplémentaires :

  • Code d’autorisation : permet d’octroyer un code temporaire que le client échange contre un jeton d’accès. Le code est obtenu à partir du serveur d’autorisation où vous pouvez afficher les informations demandées par le client. Seul ce type d’octroi permet un emprunt d’identité de l’utilisateur sécurisé.
  • Informations d’identification client : ce type d’octroi est utilisé pour obtenir un jeton d’accès en dehors du contexte d’un utilisateur. Cette méthode est utilisée par les clients pour accéder à leurs propres ressources plutôt que pour accéder aux ressources d’un utilisateur.
  • Mot de passe du propriétaire de la ressource : fournissez les informations d’identification correctes pour autoriser la fourniture d’un jeton d’accès au serveur de ressources.

Entrées du type d’octroi

Selon le type d’octroi défini ci-dessus, vous disposez des options suivantes pour activer l’authentification OAuth 2.0 :

  • URL de jeton : permet de définir l’URL du jeton d’autorisation d’accès.
  • Étendue : permet de définir l’étendue de la demande d’accès. Il s’agit d’une chaîne définie par le serveur d’autorisation lors de la configuration de votre application d’intégration cible.
  • ID du client : permet de définir la chaîne représentant les informations d’inscription client uniques au serveur d’autorisation.
  • Clé secrète client : permet de définir la chaîne unique générée lors de la configuration de l’intégration de l’application cible.
  • Nom d’utilisateur : permet de définir le nom d’utilisateur de votre compte d’application cible.
  • Mot de passe : permet de définir le mot de passe de votre compte d’application cible.
  • URL d’autorisation : permet de définir l’adresse URL du serveur d’autorisation fournie lors de la configuration de l’intégration de l’application cible.
  • Paramètres de jeton d’accès : permet de définir les paramètres de jeton d’accès requis par le serveur d’autorisation d’application cible si nécessaire.
  • Se connecter avec compte de service : permet de se connecter avec le compte de service du serveur d’autorisation de votre application cible.
  • Préfixe d’en-tête : (facultatif) entrez le préfixe d’en-tête si le préfixe de votre porteur est différent de l’en-tête par défaut.

Vous trouverez des ressources supplémentaires concernant OAuth 2.0 sur la page Demande de questions de OAuth 2.0.

Dépannage d’OAuth 2.0

Si vous rencontrez des problèmes pour connecter votre application cible à la plate-forme de micro-apps, comparez les erreurs possibles suivantes avec votre propre configuration :

  • invalid_request : votre demande d’autorisation peut comporter un paramètre requis manquant, contenir une valeur de paramètre non prise en charge (ou un autre type d’octroi), répéter un paramètre, inclure plusieurs informations d’identification, utiliser plusieurs mécanismes pour authentifier un client.
  • invalid_client : votre authentification client a échoué pour les raisons suivantes : client inconnu, aucune authentification client incluse ou méthode d’authentification non prise en charge. Le serveur d’autorisation peut renvoyer un code d’état HTTP 401 (Non autorisé) pour indiquer quels schémas d’authentification HTTP sont pris en charge.
  • invalid_grant : le jeton d’octroi d’autorisation ou d’actualisation peut être non valide, peut avoir expiré, peut avoir été révoqué, peut ne pas correspondre à l’URI de redirection utilisé dans la demande d’autorisation émise à un autre client.
  • unauthorized_client : le client authentifié n’est pas autorisé à utiliser ce type d’octroi d’autorisation.
  • unsupported_grant_type : le type d’octroi d’autorisation n’est pas pris en charge par le serveur d’autorisation.
  • invalid_scope : l’étendue demandée n’est pas valide, est inconnue, a un format incorrect ou dépasse l’étendue accordée par le propriétaire de la ressource.

Si vous rencontrez toujours des problèmes lors de la configuration d’OAuth 2.0, vérifiez si vous avez entré l’URL correcte pour le jeton et l’URL d’autorisation, car ces deux éléments sont uniques. Vérifiez également que vos autres entrées sont correctes, telles que le paramètre Étendue. Si les problèmes persistent, vérifiez les paramètres du côté serveur d’applications intégré.

Limite du taux de requêtes (facultatif)

Sélectionnez l’option Limite du taux de requêtes pour activer la limite de taux de requêtes pour votre intégration. Lorsque cette option est activée, vous pouvez définir le nombre de requêtes et l’intervalle de temps (1 seconde ou 1 minute) que vous avez extraits de votre application cible. Configurez la limite du taux de requêtes en fonction des meilleures pratiques/des limites définies dans la documentation de votre application cible.

Instance locale (Tech Preview)

Les micro-apps vous permettent également de connecter votre système d’enregistrement (SoR) local.

Si vous créez une connexion locale, connectez-vous d’abord à l’aide de l’ appliance Citrix Cloud Connector.

Pour trouver cet outil, connectez-vous à Citrix Cloud.

  1. Sélectionnez Modifier ou ajouter dans l’onglet Emplacement des ressources.
  2. Recherchez votre ressource de micro-app dans la liste.
  3. Cliquez sur ID.
  4. Copiez l’ID de ressource dans l’emplacement de ressources local dans la micro-app : Votre intégration locale est configurée.

Remarque :

L’activation de la configuration locale n’est actuellement fournie qu’en tant que version Technical Preview. La configuration locale est masquée par défaut et doit être activée dans Citrix Cloud Operations Dashboard avec le nom de fonctionnalité de l’appliance Connector. Lorsque vous avez activé cette fonctionnalité, la modification est propagée en moins d’une heure (mise en cache des entités activées côté Citrix). La configuration locale prend actuellement en charge uniquement l’intégration HTTP et les intégrations Jira ; le protocole HTTPS est uniquement pris en charge pour la communication avec le système d’enregistrement (SoR).

Autres ressources

Une fois l’intégration HTTP créée, configurez votre intégration.