Créer une intégration HTTP

Une fois vos API identifiées, ajoutez une intégration HTTP au service de micro-apps.

  1. Sur la page Intégrations de micro-apps, sélectionnez Ajouter une intégration.
  2. Choisissez Créer une intégration à votre service Web HTTP pour ajouter les détails de configuration.

    Vignette HTTP

  3. 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. Par exemple, https://app.asana.com/api/1.0/workspaces/${YOUR_WORKSPACE_ID}. Remplacez ${YOUR_WORKSPACE_ID} par votre ID d’espace de travail (par ex. 419224638481718).

    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 pour les intégrations SaaS, 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. Les intégrations sur site n’autorisent pas les URL de base HTTP.

  4. Sélectionnez une icône à afficher avec votre intégration. Choisissez une icône dans l’ensemble prédéfini d’icônes ou ajoutez une icône personnalisée. Pour plus d’informations sur l’ajout d’icônes personnalisées, consultez la section Ajouter des icônes personnalisées.
  5. (Facultatif) Pour vous connecter à un système d’enregistrement (SoR) local, activez le paramètre Instance locale. Pour de plus amples informations, consultez Instance locale.
  6. Sélectionnez Authentification de service et Authentification des actions de service selon les besoins. Pour de plus amples informations, consultez Configurer l’authentification de service.
  7. (Facultatif) Pour activer la limitation du taux de demandes pour votre intégration, activez le paramètre Limitation du taux de demandes. Pour de plus amples informations, consultez Limitation du taux de demandes.
  8. Sélectionnez Ajouter en haut à droite pour enregistrer ces configurations d’intégration. Vous pouvez continuer à configurer l’intégration. Pour de plus amples informations, consultez Configurer l’intégration.

Ajouter des icônes personnalisées

Vous pouvez ajouter des icônes personnalisées pour mieux identifier vos intégrations. Lorsque vous publiez votre intégration HTTP à l’attention d’une audience plus large, les fichiers d’icônes sont téléchargés sur le stockage Azure CDN et sont accessibles publiquement.

Le fichier d’icônes doit être conforme aux paramètres suivants :

  • Le fichier est au format PNG, avec un arrière-plan transparent.
  • La résolution du fichier doit être de 128 x 128 pixels exactement.
  • La taille maximale du fichier est de 80 Ko.

Remarque

Les icônes personnalisées sont uniquement utilisées dans la vue d’ensemble des intégrations. Vous ne pouvez pas les propager dans les notifications Workspace.

Pour ajouter une icône, choisissez Ajouter une icône, puis sélectionnez le fichier à télécharger.

Lorsque vous exportez une intégration, puis que vous l’importez vers une autre instance, l’icône est ajoutée à la liste des icônes personnalisées de l’instance cible.

Pour supprimer une icône, sélectionnez une icône dans la fenêtre contextuelle des icônes, puis cliquez sur Supprimer icône. Lorsque vous supprimez une icône, l’icône n’est pas complètement supprimée. L’intégration contient un lien vers l’icône, mais vous ne pouvez pas la sélectionner à nouveau.

Instance locale

Le service de micro-apps vous permet également de connecter votre système d’enregistrement (SoR) local. Les intégrations sur site n’autorisent pas les URL de base HTTP. Pour créer une connexion locale, connectez-vous d’abord à l’aide de l’appliance Connector, puis suivez cette procédure pour obtenir et ajouter l’ID de ressource. Pour de plus amples informations, consultez appliance Citrix Cloud Connector.

  1. Accédez à Citrix Cloud et connectez-vous avec vos informations d’identification.
  2. Après vous être connecté à Citrix Cloud, sélectionnez Emplacements de ressources dans le menu.
  3. Sélectionnez l’icône Ajouter + et recherchez votre ressource de micro-app dans la liste.
  4. Sélectionnez ID et copiez l’ID de ressource dans le champ Emplacement des ressources de l’instance locale de l’écran Ajouter une intégration HTTP.

Votre intégration locale est configurée.

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é.

Limitation du taux de demandes (facultatif)

Sélectionnez l’option Limitation du taux de demandes 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 limitation du taux de demandes en fonction des meilleures pratiques/des limites définies dans la documentation de votre application cible.

Autres ressources

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

Créer une intégration HTTP