Intégration Azure
Dernière mise à jour
Dernière mise à jour
Cette section fournit des instructions sur :
: Comment configurer la synchronisation des utilisateurs et des groupes avec Azure Active Directory.
: Comment configurer l'authentification WorkflowGen avec OpenID Connect et Azure Active Directory.
: Comment autoriser l'accès aux applications mobiles avec OpenID Connect et Azure Active Directory.
: Comment autoriser WorkflowGen pour accéder aux scripts côté serveur avec OpenID et Azure Active Directory.
: Comment autoriser WorkflowGen pour accéder aux applications monopages avec OpenID Connect et Azure Active Directory.
: Comment configurer la base de données de WorkflowGen avec la base de données Azure SQL.
: Comment configurer la fonctionnalité facultative de lecture du Scale-Out.
: Comment configurer l'équilibreur de charge d'Azure pour une plus haute disponibilité et une infrastructure plus évolutive.
: Comment configurer un partage Azure Files pour utilisation avec WorkflowGen.
: Comment configurer un SMTP Azure SendGrid avec WorkflowGen.
Elle fournit également des informations supplémentaires sur , et .
Note : Dans les instructions, remplacez <workflowgen url>
par le domaine et le chemin de votre instance de WorkflowGen; par exemple, localhost/wfgen
ou www.macompagnie.com/wfgen
.
Cette section contient les instructions sur la configuration du connecteur de synchronisation Azure Active Directory (AD) de WorkflowGen, qui s'appuie sur les fonctionnalités d'approvisionnement des utilisateurs d'Azure AD. Les utilisateurs et les groupes seront automatiquement mis à jour (envoyés vers WorkflowGen) par Azure (toutes les 20 à 40 minutes) en utilisant le protocole SCIM v2. Les mots de passe des utilisateurs Azure ne seront pas synchronisés. Une licence Azure Premium P1 est requise pour activer la fonctionnalité d'approvisionnement d'utilisateurs. Seulement un annuaire WorkflowGen peut être synchronisé par Azure.
Comme mentionné, c'est Azure AD qui pousse les données vers WorkflowGen. La nature du protocole ne permet pas à WorkflowGen de mettre à jour le répertoire dans Azure. En d'autres termes, c'est Azure qui interroge WorkflowGen pour obtenir des informations, et non l'inverse. Cela signifie que Active Directory est la seule source de vérité pour les utilisateurs et les groupes du système.
Note : Si vous utilisez l'approvisionnement des utilisateurs Azure AD SCIM, vous devez désactiver le service de synchronisation de répertoires de WorkflowGen si le service a déjà été installé et démarré.
Assurez-vous d'avoir une instance de WorkflowGen en fonctionnement dans un réseau accessible par Azure AD avec les ports HTTPS ou HTTP ouverts.
Assurez-vous de connaître l'adresse de l'instance.
Assurez-vous que l'instance de WorkflowGen est opérationnelle.
Une licence Azure Premium P2 doit être activée dans le client Azure Active Directory.
Cette section contient les instructions sur la définition d'un nouveau annuaire qui sera utilisé par Azure AD pour la synchronisation des utilisateurs et des groupes. Si vous avez satisfait les prérequis ci-dessus, vous pouvez procéder à la configuration de WorkflowGen pour recevoir les informations d'Azure AD.
Dans le module d'administration de WorkflowGen (https://<workflowgen url>/admin
), cliquez sur Annuaires, puis cliquez sur Nouvel annuaire dans l'écran Annuaires.
Entrez un nom et une description pour l'annuaire.
Important : Ne cochez pas l'option Mot de passe des utilisateurs, car l'authentification sera gérée par Azure AD.
Choisissez Azure AD SCIM v2 depuis la liste déroulante Connecteur d'annuaire.
Note : Vous pouvez avoir un seul annuaire SCIM par instance de WorkflowGen.
Copiez le jeton généré, parce que vous en aurez besoin pour la configuration de Azure AD.
Cliquez Enregistrer pour créer l'annuaire.
Cette section contient les étapes pour la configuration d'une application d'entreprise typique avec Azure AD pour approvisionner votre instance de WorkflowGen avec des utilisateurs et des groupes.
Si vous avez déjà synchronisé une instance de WorkflowGen avec une application d'entreprise dans Azure AD, ne réutilisez pas cette application d'entreprise avec une autre instance de WorkflowGen. Au lieu, créez une nouvelle application d'entreprise pour chaque instance vous voulez synchroniser.
Pour approvisionner WorkflowGen, vous devez l'inscrire dans le portail Azure AD en ajoutant une nouvelle application d'entreprise. Pour ce faire :
Dans le panneau Azure Active Directory dans votre portail Microsoft Azure, cliquez sur Applications d'entreprise, puis cliquez Nouvelle application.
Dans le panneau Ajouter une application, cliquez sur Application ne figurant pas dans la galerie.
Entrez le nom de l'application. Généralement, il vous faudra un nom comme WorkflowGen SCIM v2
afin de l'identifier facilement.
Cliquez sur Ajouter.
Vous pouvez maintenant passer à la configuration de l'application pour approvisionner WorkflowGen.
Établissez une connexion entre WorkflowGen et Azure AD
Cliquez sur Approvisionnement sur la page de l'application. Toute la configuration restante sera faite ici.
Pour configurer la connexion entre WorkflowGen et Azure AD:
Choisissez le mode d'approvisionnement Automatique.
Pour l'URL de locataire, ajoutez votre adresse WorkflowGen (p.ex. : https://<workflowgen url>/wfgen/scim
).
Note : Si votre domaine de base pointe déjà vers l'instance de WorkflowGen, n'incluez pas wfgen
dans l'adresse.
Dans le champ Jeton secret, collez le jeton que vous avez généré antérieurement lorsque vous avez créé le nouvel annuaire SCIM.
Cliquez sur Tester la connexion et attendez les résultats. Si tout est bien, vous recevrez une notification ainsi que des options supplémentaires.
Cliquez sur Enregistrer en bas de la page.
Configurez l'approvisionnement
Deux nouvelles sections devraient maintenant être disponibles : Mappages et Paramètres. Vous devez changer quelques correspondances (« mappings ») pour égaler les données correspondantes dans WorkflowGen, et pour réduire la possibilité d'erreurs.
Groupes
Cliquez sur l'option qui contient Groupes pour changer la correspondance des groupes. Ensuite, dans la nouvelle page, naviguez à la section Mappages d'attributs et conservez seulement les correspondances externalId
, displayName
et member
réglées sur customappsso
. Vous devez aussi changer la correspondance de externalId
en objectID
d'Azure AD. Ceci empêchera deux groupes différents d'être approvisionnés avec la même correspondance externalId
. Cet attribut doit être unique.
Vous avez également la possibilité de personnaliser les opérations à exécuter dans le répertoire WorkflowGen. Si vous partez de zéro, vous devez laisser Créer, Mettre à jour et Supprimer activés pour vous assurer qu'Azure peut effectuer toutes les opérations dont il a besoin pour garder WorkflowGen synchronisé avec Active Directory.
Les correspondances finales doivent ressembler au tableau suivant. Si vous avez des correspondances supplémentaires qui ne sont pas listées ici, vous devez les supprimer, car elles ne seront pas mappées dans WorkflowGen.
Groupe Azure AD
urn:ietf:params:scim:schemas: core:2.0:Group
Groupe WorkflowGen
objectId
externalId
systemIdentifier
mailNickname
displayName
name
members
members
users
Lorsque toutes les correspondances des groupes sont réglées, cliquez sur Enregistrer.
Utilisateurs
Vous devez aussi modifier les correspondances des utilisateurs. Pour ce faire, retournez aux options d'approvisionnement pour l'application de l'entreprise, puis cliquez sur le bouton pour les correspondances des utilisateurs dans la section Mappages.
Dans la section Mappages d'attributs dans la nouvelle page, vous devez changer seulement la correspondance de externalId
en objectId
d'Azure.
Vous avez également la possibilité de personnaliser les opérations à exécuter dans le répertoire WorkflowGen. Si vous partez de zéro, vous devez laisser Créer, Mettre à jour et Supprimer activés pour vous assurer qu'Azure peut effectuer toutes les opérations dont il a besoin pour garder WorkflowGen synchronisé avec Active Directory.
Les correspondances finales doivent ressembler au tableau suivant. Si vous avez des correspondances supplémentaires qui ne sont pas listées ici, vous devez les supprimer, car elles ne seront pas mappées dans WorkflowGen.
Utilisateur Azure AD
urn:ietf:params:scim:schemas: extension:enterprise:2.0:User
Utilisateur WorkflowGen
IsSoftDeleted
active
isActive
displayName
displayName
commonName
FacsimileTelephoneNumber
phoneNumbers[type eq "fax"].value
fax
givenName
name.givenName
firstName
jobTitle
title
jobTitle
mail
emails[type eq "work"].value
email
objectId
externalId
systemIdentifier
manager
manager
manager
mobile
phoneNumbers[type eq "mobile"].value
mobile
postalCode
addresses[type eq "work"].postalCode
postalCode
physicalDeliveryOfficeName
addresses[type eq "other"].Formatted
office
streetAddress
addresses[type eq "work"].streetAddress
postalAddress
surname
name.familyName
lastName
telephoneNumber
phoneNumbers[type eq "work"].value
phone
userPrincipalName
userName
userName
Lorsque toutes les correspondances des utilisateurs sont réglées, cliquez sur Enregistrer.
Vous êtes maintenant prêt à lancer la synchronisation des utilisateurs et des groupes avec votre instance de WorkflowGen. Pour ce faire, naviguer à la section Paramètres dans la page d'approvisionnement de votre application d'entreprise.
Si vous voulez synchroniser seulement un sous-ensemble de vos utilisateurs et vos groupes Azure AD, sélectionnez l'option pour synchroniser les utilisateurs et les groupes affectés, ensuite affectez-les manuellement à cette application dans l'annuaire. Pour ce faire, naviguez vers la section Utilisateurs et groupes de l'application et ajoutez vos utilisateurs manuellement.
Vous pouvez aussi configurer l'application pour synchroniser tous les utilisateurs et les groupes de votre répertoire. Encore, sélectionnez la portée correcte.
Lorsque vous êtes prêt, réglez le status de l'approvisionnement sur Activé, puis cliquez sur Enregistrer.
Vous avez maintenant complété la configuration de l'approvisionnement des utilisateurs et des groups de Azure AD à WorkflowGen en utilisant le protocole SCIM v2. Vous pouvez vérifier l'approvisionnement dans les logs de synchronisation dans le module d'administration de WorkflowGen, ou bien dans les fichiers de log créés par l'API SCIM de WorkflowGen, qui sont situés dans le répertoire APP_DATA
de WorkflowGen.
Si vous avez déjà une synchronisation avec un Active Directory classique, cette section contient les instructions sur comment migrer vos utilisateurs WorkflowGen vers votre nouvel Azure AD sans devoir les supprimer et récréer.
Tout d'abord, il est important de comprendre comment Azure AD synchronise votre annuaire via le connecteur SCIM avant de procéder à une migration. Dans ce guide, nous avons changé les correspondances par défaut entre les propriétés d'objet Azure AD et les propriétés SCIM. Une de ces propriétés est externalId
, qui représente un identifiant unique depuis un système externe, donc elle doit être opaque pour WorkflowGen. Vous avez changé cette correspondance de displayName
dans Azure AD en objectId
. Dans WorkflowGen, externalId
correspond à la propriété systemIdentifier
d'un utilisateur, donc la valeur objectId
de Azure AD est approvisionnée dans la valeur systemIdentifier
dans WorkflowGen.
Deuxièmement, Azure AD commence la synchronisation en interrogeant le connecteur SCIM pour trouver les utilisateurs existants. D'abord, il envoie des requêtes GET avec ses valeurs objectId
. Puisque WorkflowGen n'a pas de Id
qui correspond à objectId
d'Azure, il retournera toujours une erreur 404 NOT FOUND
. Ensuite, il envoie des requêtes GET mais avec un filtre sur externalId
; cette fois, il trouve les utilisateurs dans WorkflowGen si leurs systemIdentifier
correspondent à un objectId
d'un utilisateur dans Azure AD.
Désactivez le connecteur d'Active Directory classique.
Créez un nouveau connecteur d'annuaire Azure SCIM v2.
Déplacez les utilisateurs et les groupes déjà dans Azure AD depuis d'autres annuaires WorkflowGen existants à l'annuaire SCIM.
Créez un script qui mettra à jour les utilisateurs et les groupes dans l'annuaire SCIM avec leurs propriétés systemIdentifier
définies pour égaler leurs propriétés objectId
Azure AD correspondantes.
L'exemple ci-dessous inclut un algorithme qui associe les utilisateurs et les groupes à Azure AD :
L'exemple ci-dessous inclut un algorithme qui associe seulement les utilisateurs à Azure AD :
Si vous rencontrez ce problème, cela peut être dû au fait que les utilisateurs et les groupes sont hors de portée de la synchronisation. La raison peut être que vous n'avez pas affecté d'utilisateurs à l'application d'entreprise et que vous avez sélectionné une portée d'utilisateurs affectés uniquement. Pour résoudre ce problème, affectez des utilisateurs à l'application d'entreprise en accédant à sa section Utilisateurs et groupes. Vous pouvez également modifier la portée de la synchronisation pour tous les utilisateurs et groupes de l'annuaire en modifiant les paramètres de synchronisation de l'application d'entreprise.
Cette section contient les instructions sur la configuration de l'authentification déléguée de WorkflowGen avec le point de terminaison (« endpoint ») v1 de l'API d'authentification Azure AD. Elle contient également des instructions sur la configuration d'une instance de WorkflowGen en fonctionnement qui utilise Azure pour l'authentification des utilisateurs.
Dans les instructions, remplacez <workflowgen url>
par le domaine et le chemin de votre instance de WorkflowGen; par exemple, localhost/wfgen
ou www.macompagnie.com/wfgen
.
Assurez-vous d'avoir une copie de WorkflowGen sous licence installée et en fonctionnement sur un serveur. Vous devez être un administrateur WorkflowGen.
Assurez-vous d'avoir l'accès d'administrateur Azure AD pour pouvoir configurer Azure AD.
Assurez-vous d'avoir approvisionné un utilisateur Azure AD existant depuis lequel vous pourrez vous authentifier à WorkflowGen et que cet utilisateur a les permissions administratives. Ceci est important car une fois que vous aurez activé la délégation, vous devrez toujours pouvoir gérer l'application.
Le mode de chiffrement AES et sa clé sont requis pour que l'authentification fonctionne.
La configuration d'Azure AD se fait dans deux étapes. D'abord, vous devez inscrire l'application Web WorkflowGen et l'associer à votre instance de WorkflowGen; ensuite, vous devez inscrire l'API GraphQL de WorkflowGen pour pouvoir inscrire des applications personnalisées pour y accéder.
Dans le portail Azure, cliquez sur Inscriptions d'applications dans la section Azure Active Directory.
Cliquez sur Nouvelle inscription d'application et entrez les propriétés :
Nom : WorkflowGen Web app
Types de comptes pris en charge : Comptes dans cet annuaire d'organisation uniquement
URI de redirection :
Type : Web
Valeur : https://<workflowgen url>/auth/callback
Note : En fonction du contexte, vous devez choisir la bonne option pour votre cas d'utilisation pour la valeur Types de comptes pris en charge.
Exemple : https://macompagnie.com/wfgen/auth/callback
Cliquez sur S'inscrire en bas de la page.
Vous devriez maintenant voir la page d'aperçu de l'application WorkflowGen inscrite.
Vous devez maintenant générer une clé secrète client pour utiliser dans le module d'authentification de WorkflowGen.
Cliquez sur Certificats & secrets.
Dans la section Secrets client, ajoutez une nouvelle clé.
DESCRIPTION : secret
, ou quelque chose de semblable pour rappeler que ceci est la clé secrète client.
EXPIRE : Choisissez Jamais.
VALEUR : Une valeur avec une entropie suffisante pour être impossible à deviner.
Cliquez sur Enregistrer. La valeur que vous avez entrée sera maintenant cryptée.
Copiez la valeur générée car vous ne pourrez plus la rechercher par la suite.
Pour que la communication entre WorkflowGen et Azure fonctionne, vous devez ajouter un autre URI de redirection autorisé à l'application Web WorkflowGen Web app
enregistrée.
Cliquez sur Authentification.
Dans la section URI de redirection, entrez les informations suivantes :
Type : Web
URI de redirection : https://<workflowgen url>/auth/logout/return
Exemple : https://macompagnie.com/wfgen/auth/logout/return
Note : Vous devriez également voirhttps://<workflowgen url>/auth/callback
dans cette liste.
Cliquez sur Enregistrer en haut de la section.
Pour exposer l'API GraphQL, vous devez ajouter une nouvelle application qui la représentera. Pour ce faire :
Dans le portail Azure, cliquez sur Inscriptions d'applications dans la section Azure Active Directory.
Cliquez sur Nouvelle inscription d'application et renseignez le formulaire des propriétés :
Nom : WorkflowGen GraphQL
Types de comptes pris en charge : Comptes dans cet annuaire d'organisation uniquement
Cliquez sur S'inscrire en bas de la page.
Vous avez maintenant correctement enregistré l'API GraphQL dans Azure AD.
Cliquez sur Exposer une API.
À droite de URI ID d'application, cliquez sur Définir et entrez l'URI https://<workflowgen url>/graphql
.
Exemple : https://macompagnie.com/wfgen/graphql
Cliquez sur Ajouter une étendue et entrez les informations suivantes :
Nom de l'étendue : defaut
Qui peut accepter ? : Administrateurs et utilisateurs
Nom d'affichage du consentement d'administrateur : Accès par défaut à l'API WorkflowGen GraphQL
Description du consentement d'administrateur : Permet à l'application d'accéder à l'API WorkflowGen GraphQL
Nom d'affichage du consentement de l'utilisateur : Accès par défaut à l'API WorkflowGen GraphQL
Description du consentement de l'utilisateur : Permet à l'application d'accéder à l'API WorkflowGen GraphQL
Cliquez sur Ajouter une étendue.
Cliquez sur Enregistrer.
Dans la page d'inscription de l'application WorkflowGen, cliquez sur Autorisations de l'API.
Cliquez sur Ajouter une autorisation, puis cliquez sur Mes API.
Cliquez sur WorkflowGen GraphQL API
dans la liste.
Cliquez sur Autorisations déléguées et cochez defaut
.
Cliquez sur Ajouter des autorisations.
Vous devriez maintenant avoir toutes les informations dont vous aurez besoin pour configurer WorkflowGen pour déléguer l'authentification à Azure AD. Voici un résumé :
Un ID client. Ceci est l'ID de l'application WorkflowGen inscrite dans Azure. Vous pouvez l'ID sur la page d'aperçu de l'application.
Une clé secrète client. Ceci est la clé secrète générée antérieurement.
Une audience. Ceci est la propriété Application ID URI
dans la section Exposer une API.
Le point de terminaison des métadonnées. Cette URL est liée à votre annuaire Azure. Pour la trouver :
Naviguez à la section des propriétés de l'annuaire.
Copiez la valeur ID de locataire
.
L'URL du point de terminaison des métadonnées est créée en remplaçant <Tenant ID>
par votre ID de locataire comme suit :
Vous devriez maintenant avoir toutes les informations requises pour lier votre instance de WorkflowGen à Azure AD.
Vous devez maintenant configurer WorkflowGen pour déléguer l'authentification à Azure AD.
web.config
de WorkflowGenOuvrez le fichier web.config
de WorkflowGen et ajoutez les propriétés suivantes sous <appSettings>
:
Remplacez <CLIENT ID>
par l'ID de l'application.
Remplacez <CLIENT SECRET>
par la clé secrète de l'application inscrite WorkflowGen générée dans Azure.
Remplacez <METADATA URL>
par l'URL que vous avez formulé antérieurement depuis la valeur Tenant ID
de votre annuaire Azure AD.
Remplacez <CHECK SESSION URL>
par la valeur de la propriété check_session_iframe
de la point de terminaison des métadonnées. (Voir le tableau ci-dessous pour plus d'informations sur cette propriété.)
Exemple de requête Linux / macOS :
curl "<METADATA URL>" | python -m json.tool
Note : Enlevez | python -m json.tool
si vous n'avez pas Python; ceci est pour l'impression automatique (« pretty printing »).
Exemple de requête Windows PowerShell :
Invoke-RestMethod -Uri "<METADATA URL>" -Method GET | ConvertTo-JSON
Tableau des options web.config
Option
Description
ApplicationSecurityAuthProvider
Le nom du fournisseur d'identité supporté par WorkflowGen. À présent, seulement Azure Active Directory, Auth0 et AD FS sont supportés. Valeur : azure-v1
, auth0
ou adfs
ApplicationSecurityAuthClientId
Chaque fournisseur d'identité génère un code qui identifie uniquement votre application. Dans ce cas, cette valeur est le code qui identifie uniquement l'application Web WorkflowGen dans Azure Active Directory, Auth0 ou AD FS
ApplicationSecurityAuthClientSecret
Comme pour l'ID client, cette valeur est aussi générée par le fournisseur d'identité, mais est plutôt comme un mot de passe d'utilisateur. Il est important de le garder secret parce qu'un logiciel malveillant ayant accès pourrait agir au nom de l'application. Cette valeur doit être générée explicitement dans Azure Active Directory.
ApplicationSecurityAuthMetadataUrl
ApplicationSecurityAuthAppIdClaim
ApplicationSecurityAuthUsernameClaim
Le nom de la revendication contenue dans le jeton d'accès qui identifie l'utilisateur dans WorkflowGen. Il est utilisé par WorkflowGen pour générer un jeton de session ainsi que par l'API GraphQL en récupérant un jeton d'accès. Note : Il est recommandé de garder la valeur par défaut.
ApplicationSecurityAuthClockTolerance
Cette valeur est utilisée lors de la vérification d'un jeton dans WorkflowGen. Il est essentiellement pour gérer des différences mineures entre les horloges des serveurs. Note : Il est recommandé de garder la valeur par défaut.
ApplicationSecurityAuthSessionRefreshEnableIFrame
Lorsqu'elle est activée (Y
), cette option active la fonctionnalité d'auto-rafraîchissement de session à l'aide d'un <iframe>
invisible. Cela permet aux utilisateurs d'entrer leurs mots de passe moins souvent en actualisant leur session en arrière-plan pendant qu'ils travaillent.
Note : Cette option est uniquement disponible lorsque WorkflowGen est configuré avec l'authentification OIDC.
WorkflowGen est maintenant lié à Azure AD et réciproquement. La dernière étape est de configurer quelques options pour finaliser le « câblage interne ».
Pour générer un jeton de session, vous devez ajouter quelques configurations au fichier web.config
.
Ouvrez le fichier web.config
de WorkflowGen et ajouter la propriété suivante sous <appSettings>
:
Remplacez <SECRET>
par une valeur qui ne peut pas être devinée, comme un UUID.
Le secret sera seulement accessible dans votre instance de WorkflowGen, donc lors de la génération du jeton de session, WorkflowGen le signera avec ce secret afin de vérifier la validité de tous les jetons qui seront envoyés.
Vous devez maintenant activer la délégation en remplaçant le système d'authentification dans IIS et faire pointer les modules de WorkflowGen au module d'authentification correct.
Dans IIS Manager, cliquez sur l'application WorkflowGen dans l'arborescence.
Cliquez sur le bouton Authentification.
Activez Authentification anonyme et désactivez toutes les autres authentifications.
Répétez ces étapes pour toutes les sous-applications.
web.config
de certains modulesCertains modules doivent faire vérifier leur authentification par le module d'authentification spécial de WorkflowGen Advantys.Security.JWTAuthenticationModule
, tandis que certains autres modules ne le doivent pas parce qu'ils sont soit publics ou ne font pas partie du système d'authentification global.
Ajoutez la propriété suivante au fichier web.config
de WorkflowGen :
Si vous avez développé des formulaires Web personnalisés avec leurs propres dossiers \bin
, vous devez copier les assemblies .NET et les bibliothèques de dépendances suivants de \wfgen\bin
dans le dossier \bin
de chaque formulaire Web personnalisé (\wfgen\wfapps\webforms\bin
) :
Advantys.My.dll
Advantys.Security.dll
Newtonsoft.Json.dll
jose-jwt.dll
Vous devriez maintenant avoir une instance de WorkflowGen en fonctionnement avec l'authentification déléguée à Azure AD via le protocole OpenID Connect. Assurez-vous d'avoir approvisionné vos utilisateurs à WorkflowGen afin qu'ils puissent accéder à WorkflowGen.
Les applications mobiles doivent suivre une approche semblable à celle des applications Web ordinaires appelée « Authorization Code Flow with Proof Key for Code Exchange (PKCE) ». La principale distinction entre PKCE et le « Authorization Code Flow » classique est que l'application mobile ne reçoit pas de clé secrète client; à la place, elle échange une paire de codes pour prouver l'origine de la tentative d'authentification. Le problème est qu'on ne peut pas se fier à une application mobile car elle est distribuée librement aux utilisateurs et donc elle n'est plus sous le contrôle, puis les sources pourraient être décompilées et analysées pour révéler les clés secrètes client.
Cette section contient les instructions sur comment configurer Azure AD pour les applications mobiles afin que vos utilisateurs mobiles puissent aussi bénéficier de l'authentification déléguée.
Assurez-vous d'avoir une copie de WorkflowGen sous licence installée et en fonctionnement sur un serveur.
Assurez-vous d'avoir l'accès d'administrateur Azure AD pour pouvoir configurer Azure AD.
Assurez-vous d'avoir approvisionné un utilisateur Azure AD existant depuis lequel vous pourrez vous authentifier à WorkflowGen pour pouvoir utiliser l'application après.
Cette configuration se fait dans plusieurs étapes. D'abord, vous devez inscrire une nouvelle application native dans Azure AD. Ensuite, vous devez donner les permissions requises à l'application pour accéder à l'API GraphQL de WorkflowGen. Enfin, vous devez inscrire les URLs de rappel qui redirigeront dans l'application native.
Dans le portail Azure, cliquez sur Inscriptions d'applications dans la section Azure Active Directory.
Cliquez sur Nouvelle inscription d'application et entrez les propriétés suivantes :
Nom : WorkflowGen Plus
Type d'application : Natif
URI de redirection : workflowgenplus://login
Cliquez sur S'inscrire en bas de la page.
Vous devriez maintenant voir la page d'aperçu de l'application inscrite WorkflowGen Plus.
Cliquez sur Paramètres.
Dans la section Accès d'API, cliquez sur Autorisations nécessaires, puis cliquez sur Ajouter.
Cliquez sur Selectionner une API.
Recherchez l'application de l'API GraphQL de WorkflowGen que vous avez inscrite et sélectionnez-la.
Cliquez sur Sélectionner des autorisations, puis cochez Accéder à WorkflowGen sous Autorisations déléguées pour accorder l'accès à l'API.
Cliquez sur Sélectionner.
Vous devriez maintenant voir l'API GraphQL de WorkflowGen listée dans la liste de permissions requises à côté de Windows Azure Active Directory.
Cliquez sur Paramètres, puis cliquez sur URI de redirection.
Ajoutez les URI workflowgenplus://callback
et workflowgenplus://logout/return
à la liste.
Cliquez sur Enregistrer.
Vous avez maintenant inscrit l'application mobile WorkflowGen Plus dans votre Azure AD.
Prenez note des informations dont vous aurez besoin plus tard :
L'ID client de l'application, qui se trouve sur la page d'aperçu de l'inscription comme ID d'application.
L'ID de locataire de votre annuaire, qui se trouve dans la sous-section des propriétés dans la section Active Directory comme ID de locataire.
Vous devrez fournir ces informations aux utilisateurs qui utiliseront l'application mobile. L'authentification déléguée fonctionnera seulement s'ils copient les IDs dans l'application.
Dans certains cas, vous voudrez effectuer une tâche spécifique qui peut être automatisée mais qui doit pouvoir accéder à l'API GraphQL de WorkflowGen; ce cas d'usage est souvent sous forme de script côté serveur. Pour ceci, OAuth2 fournit un type d'autorisation appelé Client Credentials qui échange tout simplement un ID client et une clé secrète client pour un jeton d'accès. Il n'y a aucun jeton ID car ceci ne fait pas partie du standard OpenID Connect, et aucun utilisateur n'est impliqué.
Cette section contient les instructions sur comment configurer Azure AD avec un script côté serveur qui a accès à l'API GraphQL. D'abord, vous devez configurer une nouvelle application Web dans le portail Azure; ensuite, vous devez configurer une nouvelle application dans WorkflowGen.
Assurez-vous d'avoir une copie de WorkflowGen sous licence installée et en fonctionnement sur un serveur.
Assurez-vous d'avoir l'accès d'administrateur WorkflowGen.
Assurez-vous d'avoir l'accès d'administrateur Azure AD pour pouvoir configurer Azure AD.
Dans le portail Azure, cliquez sur Inscriptions d'applications dans la section Azure Active Directory.
Cliquez sur Nouvelle inscription d'application, puis entrez les propriétés :
Nom : Le nom de votre script
Application type : Application/API Web
URL de connextion : Ceci n'est pas requis car il n'y aura aucune connexion.
Cliquez sur Créer en bas de la page.
Vous avez maintenant inscrit votre script dans Azure Active Directory.
Cliquez sur Paramètres.
Dans la section Accès d'API, cliquez sur Permissions nécessaires, puis cliquez sur Ajouter.
Cliquez sur Sélectionner une API.
Recherchez l'application de l'API GraphQL de WorkflowGen que vous avez inscrite et sélectionnez-la.
Cliquez sur Sélectionner des autorisations, puis cochez toutes les cases à cocher.
Cliquez sur Sélectionner.
Vous devriez maintenant voir l'API GraphQL de WorkflowGen listée dans la liste de permissions requises.
Retournez à la page d'aperçu de l'application, puis cliquez sur Paramètres.
Dans la section Clés, entrez une nouvelle clé avec les propriétés suivantes :
Description : secret_client
(ou n'importe quel nom qui indique clairement qu'il s'agit d'un secret)
Expire : N'expire jamais
Valeur : Une chaîne qui représente le secret. Assurez-vous que cette chaîne a une entropie suffisante pour être impossible à devenir, comme un UUID.
Cliquez sur Enregistrer.
Copiez et sauvegardez la valeur générée par Azure. Ceci est votre clé secrète client, et vous ne pourrez plus la rechercher par la suite.
Voici un résumé ds informations dont vous aurez besoin :
Un ID client, qui se trouve sur l'onglet de configuration de l'application inscrite.
Une clé secrète client.
L'ID de locataire de votre Azure AD, qui se trouve dans la sous-section des propriétés dans la section Active Directory du portail.
L'ID d'application de l'API GraphQL de WorkflowGen, qui se trouve dans sa page d'aperçu.
Vous êtes maintenant prêt à inscrire votre script dans WorkflowGen.
Comme pour l'approvisionnement des utilisateurs, WorkflowGen doit savoir quelle application accède à l'API GraphQL. Vous devez donc inscrire l'application, qui est constituée de votre script.
Dans la page Applications du module d'administration de WorkflowGen, cliquez sur Nouvelle application.
Renseignez le formulaire :
Name : Mon application serveur
Description : Une description qui indique clairement qui identifie clairement le script
Type : Non-interactive Client
Nom d'utilisateur d'impersonnification : Un nom d'utilisateur qui a les permissions requises pour accéder à l'API GraphQL
ID client : L'ID client que vous avez retrouvée plus tôt
Actif : Cochez cette case
Cliquez sur Enregistrer.
Votre application devrait maintenant paraître dans la liste d'applications.
Vous devriez maintenant mis en place les composants nécessaires à faire des requêtes à l'API GraphQL depuis votre script en passant le jeton d'accès reçu d'Azure AD via le flux Client Credentials Grant.
Les applications JavaScript s'exécutant dans un navigateur sont souvent difficiles à sécuriser à cause de la nature ouverte du Web. Le stockage sécurisé est non-existant, et tout est en texte clair (pour HTTP version 1.1). Voici une citation (en anglais) de l'équipe Azure Active Directory qui synthétise l'état de l'authentification avec les applications monopages (« single-page applications ») :
The OAuth2 implicit grant is notorious for being the grant with the longest list of security concerns in the OAuth2 specification. And yet, that is the approach implemented by ADAL JS and the one we recommend when writing SPA applications. What gives? It’s all a matter of tradeoffs: and as it turns out, the implicit grant is the best approach you can pursue for applications that consume a Web API via JavaScript from a browser.
Il est donc important de faire toutes les vérifications nécessaires pour assurer la validité de vos demandes et les réponses.
Cette section contient les instructions sur comment configurer Azure AD avec une application monopage (« SPA ») avec laquelle les utilisateurs pourront s'authentifier et faire des requêtes à l'API GraphQL. Cette configuration est constituée de trois étapes : l'inscription de la SPA, donner accès à l'API et régler quelques URLs de redirection.
Assurez-vous d'avoir une copie de WorkflowGen sous licence installée et en fonctionnement sur un serveur.
Assurez-vous d'avoir l'accès d'administrateur Azure AD pour pouvoir configurer Azure AD.
Assurez-vous d'avoir approvisionné un utilisateur Azure AD existant depuis lequel vous pourrez vous authentifier à WorkflowGen pour pouvoir utiliser l'application.
Dans le portail Azure, cliquez sur Inscriptions d'applications dans la section Azure Active Directory.
Cliquez sur Nouvelle inscription d'application, puis entrez les propriétés :
Nom : Votre nom SPA
Type d'application : Application/API Web
URL de connexion : https://<votre URL de login SPA>
Cliquez sur Créer en bas de la page.
Vous devriez maintenant voir la page d'aperçu de votre application inscrite.
Maintenant que vous avez inscrit votre SPA, vous devez lui donner accès à l'API de WorkflowGen, qui devrait être déjà inscrite si vous avez satisfait les prérequis.
Cliquez sur Paramètres.
Dans la section Accès d'API, cliquez sur Permissions nécessaires, puis cliquez sur Ajouter.
Cliquez sur Sélectionner une API.
Recherchez l'application de l'API GraphQL de WorkflowGen et sélectionnez-la.
Cliquez sur Sélectionner des autorisations, puis cochez toutes les cases à cocher.
Cliquez sur Sélectionner.
Vous devriez maintenant voir l'API GraphQL de WorkflowGen dans la liste des permissions requises de votre SPA inscrite. Lors d'une requête de jeton d'accès à Azure, selon l'audience vous devriez pouvoir obtenir un jeton valide que vous enverrez vers l'API GraphQL de votre instance de WorkflowGen en plus de la demande.
Cette section fournit les instructions sur comment créer et configurer votre base de données SQL Azure.
Le nom du serveur SQL Azure.
Les informations d'identification du compte administrateur.
Une règle de pare-feu au niveau du serveur pour le serveur de votre adresse IP.
Le nom de votre base de données SQL Azure.
Ouvrez le dossier source DRIVE:\temp\pack\Databases\MsSQLServer
et exécutez les scripts de création de base de données SQL sur la nouvelle instance de la base de données dans l'ordre suivant :
Create_WFG-V7-0_SQL_Tables.sql
Create_WFG-V7-0_SQL_PKeys.sql
Create_WFG-V7-0_SQL_FKeys.sql
Create_WFG-V7-0_SQL_Indexes.sql
Create_WFG-V7-0_SQL_Triggers.sql
Create_WFG-V7-0_SQL_Const.sql
Ouvrez le fichier web.config
de WorkflowGen et ajoutez le nœud suivant sous <connectionStrings>
:
Remplacez <server name>
par le nom du serveur (p.ex. workflowgen.database.windows.net
).
Remplacez <database name>
par le nom de la base de données (p.ex. WFGEN
).
Remplacez <database user>
par l'utilisateur de la base de données (p.ex. wfgen_user
).
Remplacez <password>
par le mot de passe de l'utilisateur de la base de données (p.ex. Admin123!
).
Note : Nous recommandons fortement d'ajouter encrypt=true
et trustServerCertificate=false;
au connectionString
pour établir une connexion sécurisée à la base de données.
Assurez-vous d'avoir un niveau de service Premium ou Business Critical.
Vous devez avoir les permissions requises pour modifier la base de données dans le portail Azure.
Installez ou mettez à jour le module Azure PowerShell dans PowerShell en exécutant les commandes suivantes :
Connectez-vous à votre compte Microsoft Azure dans PowerShell en exécutant la commande suivante :
Si vous rencontrez des problèmes de sécurité lors du processus de connexion à Microsoft Azure, vous devez donc ajouter manuellement https://login.microsoftonline.com/
ainsi que les URIs de tous les sites Web associés dans la zone Sites approuvés dans les options Internet d'Internet Explorer.
Activez la fonctionnalité du Read Scale-Out dans PowerShell en exécutant la commande suivante :
Remplacez <resource group>
par le nom du groupe de ressources.
Remplacez <server name>
par le nom du serveur (p.ex. workflowgen.database.windows.net
).
Remplacez <database name>
par le nom de la base de données (p.ex. WFGEN
).
Vous pouvez aussi activer la fonctionnalité du read Scale-Out avec l'API REST d'Azure SQL Database.
Naviguez vers la section Base de données sur l'onglet Général du panneau de configuration de WorkflowGen.
Dans le champ Chaîne de connexion à la base de données « maître », ajoutez le paramètre ApplicationIntent=ReadWrite
à la chaîne de connexion existante, puis cliquez sur Tester pour tester la disponibilité de la base de données. Voici un exemple d'une chaîne de connexion :
Dans le champ Chaîne de connexion de la base de données en lecture seule, ajoutez (ou modifiez) la chaîne de connexion avec le nouveau paramètre, puis cliquez sur Tester pour tester la disponibilité de la base de données. Voici un exemple d'une chaîne de connexion :
Cochez l'option Multi-base de données.
Azure Load Balancer vous permet de mettre à l’échelle vos applications et de créer une haute disponibilité pour vos services. Load Balancer prend en charge les scénarios entrants et sortants, offre une latence faible et un débit élevé, et peut augmenter l’échelle jusqu’à des millions de flux pour toutes les applications TCP et UDP.
Load Balancer distribue les nouveaux flux entrants qui arrivent sur son frontend vers des instances de pool backend en fonction de règles et de sondes d’intégrité.
De plus, un équilibreur de charge public peut fournir des connexions sortantes pour des machines virtuelles à l’intérieur de votre réseau virtuel en traduisant leurs adresses IP privées en adresses IP publiques.
Un équilibreur de charge avec ses ressources configurés : un pool d'adresses « back-end », une sonde d'intégrité (« health probe ») et une règle d'équilibrage de charge.
Un réseau virtuel
Deux machines virtuelles avec IIS installé sur chacune
Un groupe de sécurité réseau
Une adresse IP publique pour l'équilibreur de charge que vous trouverez dans sa page d'aperçu.
Note : Cette adresse IP publique sera utilisée pour accéder à vos instances de WorkflowGen.
Note : Une fois que WorkflowGen est installé, il est obligatoire de configurer le mode d'authentification anonyme pour le site Web de WorkflowGen. L'application wfgen
et ses sous-applications pourraient avoir de différentes méthodes d'authentification configurées.
Assurez-vous que les deux instances de WorkflowGen pointent vers la même base de données. Votre base de données peut être :
Une instance de base de données MS SQL classique sur un serveur dédié ou sur une des machines virtuelles. Assurez-vous d'ajouter des règles d'entrée et de sortie (selon vos besoins) pour le port SQL dans le group de sécurité réseau.
Note : Assurez-vous de remplacer la valeur du paramétrage ApplicationDataPath
dans le fichier web.config
de WorkflowGen par le nouveau chemin du partage de fichiers.
Ouvrez le fichier web.config
de WorkflowGen et modifiez la valeur du paramétrage suivant :
Pour les deux instances de WorkflowGen, remplacez <adresse IP publique de l'équilibreur de charge>
ci-haut par l'adresse IP publique de l'équilibreur de charge.
Un dossier WebForms partagé.
Les services du moteur et de la synchronisation des annuaires de WorkflowGen en fonctionnement sur une instance unique de WorkflowGen.
Azure Files est un service dans le cloud qui offre un service de sauvegarde de stockage pour les instances de WorkflowGen hébergées dans le cloud Azure ou sur place via un partage de fichiers utilisant le protocole SMB standard. Ce service fournit plusieurs bonnes options pour L'accès au données, le partage, la synchronisation et la redondance pour usage dans des scénarios d'une ou de plusieurs instances de WorkflowGen.
La section suivante contient des instructions et des recommandations sur la configuration d'un partage Azure Files pour utiliser dans WorkflowGen.
Avant de choisir Azure Files comme le service de sauvegarde de stockage principal pour votre WorkflowGen, il faut examiner quelques scénarios de configuration de performance pour votre stockage des données :
Dans une configuration avec une seule instance de WorkflowGen
Hébergée sur une machine virtuelle Azure :
Pour la meilleure performance, utilisez un disque SSD local.
Pour une bonne performance, utilisez un partage d'Azure Files dans votre région géographique.
Hébergée sur place :
Pour la meilleure performance, utilisez un disque SSD local.
Pour une performance de base, utilisez un partage Azure Files dans la région géographique la plus proche de votre serveur pour la plus basse latence.
Dans une configuration « web farm » (batterie de serveurs Web)
Hébergée sur une machine virtuelle Azure :
Pour la meilleure performance, utilisez un partage de fichiers sur un serveur de fichiers assuré par le stockage SSD.
Note : Un des serveurs Web WorkflowGen ou une machine virtuelle dédiée peut agir en tant que serveur de fichiers.
Pour une bonne performance, utilisez un partage Azure Files dans votre région géographique.
Hébergée sur place :
Pour la meilleure performance, utilisez un partage sur un serveur de fichiers assuré par le stockage SSD.
Note : Un des serveurs WorkflowGen ou un serveur dédié peut agir en tant que serveur de fichiers.
Pour une performance de base, utilisez un partage Azure Files dans la région géographique la plus proche de votre serveur pour la plus basse latence.
Assurez-vous d'avoir une instance de WorkflowGen en fonctionnement avec accès Internet.
Assurez-vous de connaître l'adresse de l'instance.
Le port TCP 445
doit être ouvert pour la sortie de l'instance.
La version 5.1 ou supérieure de Windows PowerShell est requise sur l'instance pour effectuer une des étapes de la configuration.
Une inscription Azure active.
Vous devez avoir les permissions requises pour modifier le Windows de l'instance de WorkflowGen, p.ex. le privilège administrateur.
Vous devez avoir les permissions requises pour modifier les comptes du service de stockage dans le portal Azure.
Dans le portail Azure, sélectionnez le service Comptes de stockage.
Ajoutez un nouveau compte de stockage.
Entrez un nom.
Note : Le nom de compte de stockage wfgendatastorage
sera utilisé comme exemple dans cette section.
Type de compte : Choisissez Stockage (v1 à usage général) ou StorageV2 (v2 à usage général).
Emplacement : Choisissez un emplacement dans la même region de votre machine virtuelle Azure, ou celui le plus proche de votre emplacement.
Performance : Choisissez Standard.
Choisissez votre abonnement.
Créez un nouveau groupe de ressources.
Note : Le nom de groupe de ressources wfgenresourcegroup
sera utilisé dans cette section.
Vous pouvez laisser le reste des configurations réglées à leurs valeurs par défaut ou vous pouvez les personnaliser selon vos besoins.
Cliquez sur Vérifier + Créer.
Dans le service Comptes de stockage, choisissez wfgendatastorage
.
Dans la section Vue d'ensemble ou la section SERVICE DE FICHIERS, choisissez Fichiers.
Ajoutez un nouveau Partage de fichier.
Entrez un nom.
Note : Le nom de stockage wfgenshare
sera utilisé comme exemple dans cette section.
Entrez un quota selon vos besoins.
Cliquez sur OK.
Connectez-vous à votre instance de WorkflowGen depuis votre compte d'administration.
Lancez une instance de Windows PowerShell 5.1 en tant qu'administrateur.
Testez le port TCP 445 pour la sortie en exécutant la commande suivantes dans PowerShell :
Note : Assurez-vous de remplacer wfgendatastorage
dans les instructions ci-dessus par votre nom de compte de stockage.
Si le test réussit, continuez à la prochaine étape. Sinon, contactez votre administrateur de réseau pour ouvrir le port TCP 445 pour la sortie.
Installez ou mettez à jour le module d'Azure PowerShell dans PowerShell :
Dans la console de gestion de l'ordinateur de Windows, créez un utilisateur local en tant que compte de service qui sera utilisé pour le pool d'applications IIS de WorkflowGen.
Entrez un nouveau nom d'utilisateur et un nouveau mot de passe.
Note : Le nom d'utilisateur wfgen_service
sera utilisé comme exemple dans cette section.
Cochez L'utilisateur ne peut pas changer le mot de passe.
Cochez Le mot de passe n'expire jamais.
Cliquez sur Créer.
Affectez l'utilisateur wfgen_service
au groupe IIS_IUSRS
.
Affectez l'utilisateur au groupe Remote Desktop Users
si l'instance est hébergée sur un serveur distant.
Connectez-vous à votre instance de WorkflowGen depuis le compte wfgen_service
.
Ouvrez une instance de Windows PowerShell 5.1 en tant qu'administrateur.
Connectez-vous à votre compte Microsoft Azure dans PowerShell :
Si vous rencontrez des problèmes de sécurité lors de la procédure de connexion à Microsoft Azure, vous devez ajouter manuellement https://login.microsoftonline.com/
et tous les URIs des sites Web associés à la zone des sites approuvés dans les options d'Internet Explorer.
Dans la fenêtre Microsoft Azure, connectez-vous au compte Azure que vous avez utilisé pour créer votre compte de stockage.
Si vous vous êtes connecté à votre compte Azure avec succès, PowerShell va afficher les informations suivantes :
Persistez les informations d'identification (« credential ») dans Windows pour le compte wfgen_service
dans PowerShell :
Note : Assurez-vous de remplacer wfgendatastorage
et wfgenresourcegroup
dans les instructions ci-dessus par votre nom de compte de stockage et votre nom de groupe de ressources.
Les informations d'identification doivent être persistées pour le compte wfgen_service
en cas de redémarrage du serveur Windows.
Si les informations d'identification sont enregistrées avec succès, le message suivant devrait être affiché :
Vérifiez si les informations d'identité ont été enregistrées pour la compte de stockage dans PowerShell :
Si l'enregistrement est réussi, vous devriez ensuite voir :
Testez le partage Azure Files dans l'explorateur de fichiers de Windows.
Note : Assurez-vous de remplacer wfgendatastorage
et wfgenshare
dans les instructions ci-dessus par votre nom de compte de stockage et votre nom de partage de fichiers.
Connectez-vous à votre instance de WorkflowGen depuis votre compte d'administration.
Ouvrez la console Gestionnaire IIS.
Modifiez le pool d'applications de WorkflowGen pour utiliser le compte personnalisé wfgen_service
avec les réglages suivants :
Identité : wfgen_service
Charger le profil utilisateur : True
Enregistrez les modifications, puis redémarrez IIS.
Connectez-vous à votre instance de WorkflowGen depuis le compte wfgen_service
.
Copiez tous les fichiers de WorkflowGen au partage Azure Files dans PowerShell :
Note : Assurez-vous de remplacer C:\inetpub\wwwroot\wfgen\App_Data
, wfgendatastorage
et wfgenshare
dans les instructions ci-dessus par le nom du dossier App_Data
, le nom de votre compte de stockage et le nom de votre partage de fichiers de votre instance de WorkflowGen.
Mettez à jour le fichier de configuration Web de WorkflowGen :
Note : Assurez-vous de remplacer wfgendatastorage
et wfgenshare
dans les instructions ci-dessus par le nom de votre compte de stockage et le nom de votre partage de fichiers de votre instance de WorkflowGen.
Ouvrez le module d'administration ou le portail utilisateur de WorkflowGen et lancer un nouveau test de demande.
Utilisez une des méthodes suivantes :
Dans votre compte de stockage dans le portail Azure :
Utilisez l'outil Storage Explorer (preview) (Explorateur du stockage).
ou
Naviguez vers le partage de fichiers wfgenshare
sous la section Files.
OU
Montez le partage de fichiers wfgenshare
dans Windows :
Naviguez vers le partage de fichiers wfgenshare
dans la section Files.
Cliquez sur Connect pour afficher un onglet avec des instructions de connexion.
Par exemple, pour monter le partage de fichiers sur le disque Z
depuis le compte d'administration de l'instance de WorkflowGen, exécutez les instructions suivantes fournies sur l'onglet Connect dans PowerShell :
Note : Assurez-vous de remplacer la chaîne key
assignée à $acctKey
, wfgendatastorage
et wfgenshare
dans les instructions ci-dessus par un de vos noms Access keys
, un de vos noms storage account
et un de vos noms file shares
de votre compte de stockage.
Vous devriez maintenant pouvoir parcourir le contenu du disque Z
dans l'explorateur de fichiers de Windows.
Cette section contient les instructions sur comment configurer un SMTP Azure SendGrid avec WorkflowGen.
Le nom du serveur (p.ex. smtp.sendgrid.net
),
Le nom d'utilisateur (p.ex. apikey
),
Le mot de passe généré, et
Le port 25
ou le port 287
réglé pour les connexions TLS et les connexions SSL explicites.
Pour créer la connexion entre WorkflowGen et Azure SendGrid SMTP :
Naviguez vers l'onglet Général du panneau de configuration.
Dans la section SMTP :
Sélectionnez Serveur comme méthode de livraison.
Entrez le nom de votre serveur dans le champ Nom d'hôte.
Réglez le port 25
ou le port 587
dans le champ Port.
Cochez Utiliser SSL/TLS.
Entrez votre nom d'utilisateur dans le champ Nom d'utilisateur.
Entrez votre mot de passe dans le champ Mot de passe.
Cliquez sur Tester à côté du champ Nom d'hôte.
Entrez une adresse email pour le test dans le champ Adresse destinataire qui s'affichera sous le champ Adresse expéditeur, puis cliquez sur Envoyer.
Note : WorkflowGen supporte les connexions TLS et les connexions SSL explicites seulement.
WorkflowGen supporte seulement les requêtes à l'API SOAP en utilisant les méthodes d'authentification classiques. Si vous devez toujours utiliser cette API, vous devez effectuer quelques étapes additionnelles pour la configurer correctement. Pour ce faire :
Créez un nouvel annuaire WorkflowGen séparé pour les utilisateurs de l'API SOAP.
Approvisionnez-le avec des utilisateurs et des groupes au besoin.
Dans Gestionnaire IIS, cochez la méthode d'authentification De base pour l'application \ws\wfgen
.
Dans le fichier web.config
(situé dans \Inetpub\wwwroot\wfgen
), ajoutez le suivant sous <location path="ws" inheritInChildApplications="false">
:
Si le portail utilisateur ou le module d'administration de WorkflowGen est affiché sans le menu de l'en-tête principale, cette fonctionnalité pourrait ne pas fonctionner. Par exemple, ce scénario pourrait se produire lorsque la page d'accueil du portail ou un formulaire de suivi de demande est affiché dans un iFrame dans une solution externe.
Le module GraphiQL (/wfgen/graphql
) ne supporte pas la gestion de session lorsqu'il est affiché dans un navigateur.
Assurez-vous que l'application SCIM est correctement installée et configurée. Voir dans la section pour savoir comment procéder.
Une autre cause possible peut être liée à d'autres configurations dans votre Azure Active Directory. Pour des instructions sur comment résoudre ce problème, consultez l'article Microsoft .
Depuis octobre 2021, Azure AD nécessite l'utilisation d'un schéma par défaut ou d'un domaine vérifié pour l'URL AppId sur l'application à locataire unique (voir la documentation Microsoft pour plus d'informations).
La documentation Microsoft sur la façon d'ajouter et de vérifier un domaine personnalisé est disponible .
Le point de terminaison fourni par le fournisseur d'identité qui supporte le standard . Il permet à WorkflowGen de récupérer des informations publiques sur votre domaine Azure Active Directory, sans lequel vous devrez effectuer beaucoup plus de configurations dans le fichier web.config
.
Le nom de la revendication contenu dans le jeton d'accès obtenu du fournisseur d'identité qui identifie uniquement un client non-interactif. Il est utilisé seulement si vous avez une application machine-à-machine qui doit accéder à l'API GraphQL. Pour le configurer, voir la section . Note : Il est recommandé de garder la valeur par défaut.
Assurez-vous d'avoir bien configuré l'authentification déléguée à Azure AD sur votre instance de WorkflowGen en suivant les instructions dans la section .
Assurez-vous d'avoir bien configuré l'authentification déléguée à Azure AD sur votre instance de WorkflowGen en suivant les instructions dans la section .
(Source : )
Assurez-vous d'avoir bien configuré l'authentification déléguée à Azure AD sur votre instance de WorkflowGen en suivant les instructions dans la section .
L'instance de la base de données SQL Azure doit être créée dans le . Consultez l'article pour des informations sur comment créer la base de données. Une fois que vous avez complété les instructions, vous aurez :
Connectez-vous à votre instance de base de données SQL Azure depuis le compte d'administrateur que vous avez créé dans ou dans .
Vous devez créer un compte utilisateur SQL Server avec les permissions db_datareader
et db_datawriter
. Voir l'article , ou bien exécutez le script dans l'éditeur de requête de la base de données SQL ou dans SQL Management Studio (la base de données master doit être sélectionnée) :
Récupérez le script de création de base de données en téléchargeant le et le décompressant dans le dossier DISQUE:\temp
.
Cette section contient les instructions sur comment configurer la fonctionnalité facultative de la lecture du Scale-Out, qui permet l'équilibrage des charges de travail en utilisant un réplica en lecture-seule au lieu d'un réplica en lecture écriture. Pour plus d'informations sur cette fonctionnalité, voir l'article Microsoft .
Pour plus d'informations, voir l'article .
Vérifiez les composants et les modules du portail utilisateur qui utiliseront la base de données en lecture seule. Pour plus d'informations, voir dans le .
Cette section contient les instructions sur comment créer et configurer la fonctionnalité Azure Load Balancer (équilibreur de charge). Voici une citation de l'article de Microsoft :
Créez un équilibreur de charge de base en suivant . Lorsque vous aurez complété les étapes, vous devriez avoir :
Note : Lorsque vous créez la règle d'équilibrage de charge, vous pouvez configurer la « sticky-session » dans la liste déroulante Persistance de session. Si l'état de session est activé dans les formulaires Web (voir l'article dans la base de connaissances de WorkflowGen, disponible en Anglais uniquement), la « sticky-session » est obligatoire.
Note : Lorsque vous créez les règles NGS (groupe de sécurité réseau), il est recommandé d'ajouter la règle RDP seulement pour les tests. Pour la production, nous recommandons utiliser un VPN ou une connexion privée. Voir l'article de Microsoft pour les instructions.
Installez WorkflowGen sur les deux machines virtuelles en suivant les instructions dans la section du .
Une , ou
Créez un partage de fichiers Azure en suivant les instructions dans la section du , puis copiez le chemin du partage de fichiers.
Configurez votre WorkflowGen dans une architecture de batterie de serveurs Web (« web farm ») en suivant les instructions dans la section du . Lorsque vous aurez complété les instructions, vous aurez :
Pour plus d'informations sur les avantages ou des cas d'usage d'Azure Files, voir le guide de Microsoft .
Pour plus d'informations sur les comptes de stockage, voir l'article .
Pour plus d'informations sur le partage des fichiers, voir l''article .
Pour plus d'informations, voir l'article .
Pour plus d'informations sur le partage de fichiers dans Windows, voir l'article .
Si vous rencontrez des problèmes, voir l'article .
Le compte SendGrid doit être créé dans le . Voir l'article . Lorsque vous aurez complété la configuration, vous aurez :
Pour plus d'informations sur l'intégration d'un SMTP SendGrid, voir (en Anglais).
Azure Active Directory supporte la , un standard de « extension draft », en plus du standard principal de OpenID Connect. Ce standard définit les règles pour gérer la session SSO du fournisseur depuis le client. Par exemple, si un utilisateur se déconnecte de sa session Azure AD depuis n'importe quel appareil, un client Web régulier recevra un message qui lui permettra d'enlever la session locale de cet utilisateur. WorkflowGen supporte cette fonctionnalité quand l'authentification déléguée est activée avec Azure AD.