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.

   

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 plus d’informations, consultez Instance locale.
6. Sélectionnez Authentification de service et Authentification des actions de service selon les besoins. Pour plus d’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 plus d’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 plus d’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 plus d’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 des ressources dans le menu supérieur gauche.
3. Recherchez l’emplacement des ressources que vous souhaitez utiliser et sélectionnez l’icône ID sous le nom de la ressource pour afficher l’ID de votre emplacement de ressources.
4. Copiez l’ID de l’emplacement de ressources.
5. Collez l’ID d’emplacement dans le champ Emplacement des ressources de l’instance locale de l’écran Ajouter une intégration HTTP.
6. (Facultatif) Désactivez Validation du certificat SSL si vous souhaitez que votre intégration accepte les certificats non signés.

Votre intégration locale est configurée.

Configurer l’authentification de service

Lorsque vous configurez l’authentification de votre service d’intégration HTTP, vous devez configurer votre compte de service avec votre application cible (système d’enregistrement). Vous devez également disposer de privilèges de lecture et d’écriture dans votre application cible si vous utilisez le compte de service pour écrire des données dans votre application. 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’autorisation 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 quatre types d’octroi. Lorsque vous configurez OAuth 2.0, sélectionnez le type d’autorisation 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’autorisation permet un emprunt d’identité de l’utilisateur sécurisé.
• Informations d’identification client : ce type d’autorisation 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.
• Flux implicite : le type d’autorisation implicite n’est présent que pour l’authentification des actions de service et uniquement en mode de développement. Vous pouvez définir le type de réponse sur token ou id_token. L’actualisation automatique du jeton d’accès n’est pas fournie. Vous devez fournir à nouveau votre consentement lorsque le jeton d’accès expire.

Entrées du type d’autorisation

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

• É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.
• URL du jeton : permet de définir l’URL du jeton d’autorisation d’accès.
• URL du jeton d’actualisation : (facultatif) permet de définir l’URL du jeton d’actualisation associée au jeton d’autorisation d’accès. Si ce champ n’est pas défini, l’URL du jeton est utilisée.
• 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.
• État de relais : permet de configurer une authentification qui autorise les utilisateurs à accéder à certaines micro-apps sans avoir à entrer de nouveau leurs informations d’identification.

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

État de relais

L’état du relais ne peut être utilisé que si les conditions suivantes sont remplies :

• Vous utilisez Okta comme fournisseur d’identité.
• Le système d’enregistrement (SoR) cible prend en charge Okta en tant que fournisseur d’identité.
• L’état du relais est activé et configuré correctement avec l’URL Okta correcte.

Après une configuration Okta réussie, entrez l’URL SingleSignOnService fournie par Okta dans le champ État de relais de l’URL Okta pour votre intégration. Par exemple : https://{your Okta}.okta.com/app/{SoR ID}/{ID}/sso/saml.

L’état du relais fonctionne uniquement avec les actions de l’utilisateur, et non avec une synchronisation complète/incrémentielle, et transmet uniquement les informations d’identification de l’utilisateur final. Avec certains systèmes d’enregistrement (SoR), les utilisateurs doivent confirmer cette option via une page d’autorisation et la configuration de RelayState ne supprime pas cette exigence.

Vous trouverez des informations supplémentaires sur la configuration d’Okta dans la documentation officielle d’Okta. Par exemple, pour plus d’informations sur la configuration d’Okta dans Salesforce, consultez l’article How to Configure SAML 2.0 for Salesforce.

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’autorisation), 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.

• Configurer l’intégration