Intégration Okta

Aperçu Authentification Okta Approvisionnement des utilisateurs dans Okta Configuration d'Okta pour les applications mobiles Configuration d'Okta pour les scripts côté serveur Configuration d'Okta pour les applications monopages Génération d'un lien universel pour WorkflowGen Plus Informations supplémentaires sur l'intégration Okta

Aperçu

Cette section fournit des instructions sur :

Elle fournit également des informations supplémentaires sur le support des services SOAP.

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.

Authentification Okta

Cette section fournit les instructions sur comment configurer l'authentification déléguée WorkflowGen avec Okta. À la fin de la section, vous aurez une instance de WorkflowGen en fonctionnement qui utilise Okta pour authentifier vos utilisateurs.

Prérequis

  • 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 à Okta.

  • Assurez-vous d'avoir approvisionné un utilisateur Okta existant depuis lequel vous pourrez vous authentifier à WorkflowGen et que cet utilisateur a les permissions d'accès d'administrateur. Ceci est important car une fois que vous aurez activé la délégation, vous devrez toujours pouvoir gérer l'application. L'utilisateur Okta est en fait un utilisateur d'un fournisseur d'identité qui est lié à Okta, comme GitHub ou Google. Vous devez avoir approvisionné au moins un utilisateur.

Notes

  • Pour tester la configuration après avoir suivi les étapes suivantes, vous pouvez ajouter un utilisateur Okta dans la section Users du portail Okta.

  • Lorsque vous importez des utilisateurs dans WorkflowGen depuis la base de données d'Okta, assurez-vous de régler le nom d'utilisateur comme son adresse email (p.ex. jean.tremblay@exemple.com).

Configuration d'Okta

La configuration d'Okta se fait dans plusieurs étapes. D'abord, vous devez configurer un serveur d'autorisation dans l'interface Web; ensuite, vous devez y ajouter une application Web régulière.

Étape 1 : Créez un serveur d'authentification

Un serveur d'autorisation Okta est un élément logique qui définit les limites de sécurité de votre système lorsqu'une application tente d'accéder à vos ressources depuis une API.

An authorization server defines your security boundary, and is used to mint access and identity tokens for use with OIDC clients and OAuth 2.0 service accounts when accessing your resources via API. Within each authorization server you can define your own OAuth scopes, claims, and access policies. Source : Encadré d'informations dans le panneau d'administration d'Okta

Pour plus d'informations sur les serveurs d'autorisation, voir le site Web des développeurs d'Okta (disponible en Anglais seulement).

Pour créer un serveur d'autorisation :

  1. Naviguez au portail développeur d'Okta et connectez-vous à votre compte.

  2. Dans la liste déroulante API du bandeau, sélectionnez Authorization Servers.

  3. Cliquez sur Add Authorization Server.

  4. Saisissez les informations suivantes :

    • Name : WorkflowGen GraphQL API

    • Audience : <workflowgen url>/graphql

    • Description : WorkflowGen GraphQL API (or n'importe quelle description)

  5. Cliquez sur Save.

Vous devriez maintenant être dans la section Settings de votre serveur d'autorisation de l'API GraphQL de WorkflowGen. Dans cette section, vous verrez la propriété Issuer (émetteur). Ajoutez-y /.well-known/openid-configuration et enregistrez-la car vous en aurez besoin pour la configuration de WorkflowGen plus tard.

Étape 2 : Ajoutez une revendication

  1. Naviguez à la section Claims, puis cliquez sur Add Claim.

  2. Saisissez les informations suivantes :

    • Name : com.workflowgen.api.username

    • Include in token type : Choisissez Access Token

    • Value Type : Choisissez Expression

    • Mapping : Saisissez le code Okta suivant :

      appuser.username != null ? appuser.username : appuser.email != null ? appuser.email : appuser.nickame != null ? appuser.nickname : null
    • Include in : Choisissez Any scope

    Note : Cette étape assurera que WorkflowGen et l'API GraphQL recevront toujours un nom d'utilisateur depuis la même revendication plutôt que de faire beaucoup d'instructions conditionnelles.

  3. Cliquez sur Save.

  4. Ajoutez une autre revendication contenant les mêmes informations, mais cette fois-ci réglez la propriété Include in token type à Id Token.

  5. Cliquez sur Save.

Vous devez maintenant configurer la stratégie d'accès du serveur d'autorisation.

Étape 3 : Configurez la stratégie d'accès

  1. Naviguez à l'onglet Access Policies du serveur d'autorisation de l'API GraphQL de WorkflowGen.

  2. Cliquez sur le bouton Add Policy.

  3. Saisissez les informations suivantes :

    • Name : All Clients Policy

    • Description : Enables all clients to have access to this application server.

  4. Cliquez sur le bouton Create Policy.

  5. Cliquez sur le bouton Add Rule.

  6. Saisissez les informations suivantes :

    • Rule Name : All Grant Types; Any Scopes; Any User assigned

    • Laissez les autres paramétrages réglés à leurs valeurs par défaut.

  7. Cliquez sur le bouton Create Rule.

Vous avez maintenant configuré la stratégie d'accès du serveur d'autorisation. Il ne vous reste qu'une étape nécessaire pour le fonctionnement du flux des informations d'identification du client, qui vous permettra d'utiliser l'authentification machine-à-machine avec Okta et l'API GraphQL de WorkflowGen.

Étape 4 : Ajoutez la portée

  1. Naviguez à l'onglet Scopes du serveur d'autorisation de l'API GraphQL de WorkflowGen.

  2. Cliquez sur le bouton Add Scope.

  3. Saisissez les informations suivantes :

    • Name : default

    • Description : Utilisez la portée par défaut si aucune autre portée est spécifiée

    • Default scope : Cochez cette option

  4. Cliquez sur le bouton Create.

Vous avez maintenant configuré votre serveur d'autorisation Okta pour l'API GraphQL de WorkflowGen.

Étape 5 : Créez une nouvelle application Web

  1. Naviguez au portail développeur d'Okta.

  2. Dans la section Applications, cliquez sur le bouton Add Application.

  3. Cliquez sur le bouton Web qui correspond au type de l'application, puis cliquez sur Next.

  4. Saisissez les informations suivantes :

    • Name : WorkflowGen

    • Base URIs : <workflowgen url> sans aucun chemin (seulement l'URL de base); par exemple, https://localhost, si <workflowgen url> est https://localhost/wfgen

    • Login redirect URIs : <workflowgen url>/auth/callback

    • Laissez les propriétés restantes réglées à leurs valeurs par défaut.

  5. Dans l'onglet General dans la page de votre application Web WorkflowGen, cliquez sur le bouton Edit dans la section General Settings.

  6. Cliquez sur le bouton Add URI sous la propriété Logout Redirect URIs.

  7. Saisissez <workflowgen url>/auth/logout/return dans le champ qui s'affiche.

  8. Cliquez sur Save.

Vous avez maintenant configuré Okta pour votre instance de WorkflowGen.

Vérifiez l'inscription

Vous devriez maintenant avoir toutes les informations dont vous aurez besoin pour configurer WorkflowGen pour déléguer l'authentification à Okta. Voici un résumé 

  • Un ID client, qui se trouve dans l'onglet Settings de la page de l'application.

  • Une clé secrète client, qui se trouve dans l'onglet des paramètres de l'application inscrite.

  • Une audience, qui se trouve sur dans la page du serveur d'autorisation de l'API GraphQL de WorkflowGen.

  • Un point de terminaison des métadonnées, qui correspond à la valeur que vous avez enregistré précédemment lors de la création du serveur d'autorisation.

Configuration de WorkflowGen

Maintenant, vous devez configurer WorkflowGen pour déléguer son authentification à Okta.

Étape 1 : Ajoutez les valeurs d'Okta au web.config de WorkflowGen

Ouvrez le fichier web.config de WorkflowGen et ajoutez-y les propriétés suivantes :

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<appSettings>
<!-- Okta auth -->
<add key="ApplicationSecurityAuthProvider" value="okta"/>
<add key="ApplicationSecurityAuthClientId" value="<CLIENT ID>" />
<add key="ApplicationSecurityAuthClientSecret" value="<CLIENT SECRET>" />
<add key="ApplicationSecurityAuthMetadataUrl" value="<METADATA URL>" />
<add key="ApplicationSecurityAuthUsernameClaim" value="com.workflowgen.api.username" />
<add key="ApplicationSecurityAuthAppIdClaim" value="sub" />
<add key="ApplicationSecurityAuthClockTolerance" value="60" />
<add key="ApplicationSecurityAuthSessionRefreshEnableIFrame" value="Y"/>
</appSettings>
</configuration>
  • Remplacez <CLIENT_ID> par l'ID client de l'application Web régulière de WorkflowGen dans Okta.

  • Remplacez <CLIENT SECRET> par la clé secrète client de l'application Web régulière de WorkflowGen dans Okta.

  • Remplacez <METADATA_URL> par l'URL que vous avez construit antérieurement depuis votre nom de domaine dans Okta.

Notez que la clé ApplicationSecurityAuthUsernameClaim est réglée à la valeur saisie dans la règle antérieurement, donc vous pouvez utiliser n'importe quelle valeur ici à condition que vous modifiez aussi la règle.

Tableau des options web.config

Option

Description

ApplicationSecurityAuthProvider

Le nom du fournisseur d'identité supporté par WorkflowGen. À présent, seulement Okta, Auth0, Azure Active Directory et AD FS sont supportés. Valeur : okta, auth0, azure-v1 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 Okta, Auth0, Azure Active Directory 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 est générée automatiquement par Okta.

ApplicationSecurityAuthMetadataUrl

Le point de terminaison fourni par le fournisseur d'identité qui supporte le standard OpenID Connect Discovery. Il permet à WorkflowGen de récupérer des informations publiques sur votre fournisseur d'authentification, sans lesquelles vous devrez effectuer beaucoup plus de configurations dans le fichier web.config.

ApplicationSecurityAuthAppIdClaim

Le nom de la revendication contenue dans le jeton d'accès obtenu du fournisseur d'identité qui identifie uniquement un client non-interactif. Elle est utilisée seulement si vous avez une application machine-à-machine qui doit accéder à l'API GraphQL. Pour le configurer, voir la section Configuration d'Okta pour les applications monopages. Note : Il est recommandé de garder la valeur par défaut.

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 de saisir 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é à Okta et réciproquement. La dernière étape est de configurer quelques options pour finaliser le « câblage interne ».

Étape 2 : Ajoutez des valeurs de sécurité pour la génération de session

Pour générer un jeton de session, vous devez ajouter quelques configurations au fichier web.config.

  1. Ouvrez le fichier web.config de WorkflowGen et ajouter la propriété suivante sous <appSettings> :

    <!-- Auth -->
    <add key="ApplicationSecurityAuthSessionTokenSigningSecret" value="<SECRET>" />
  2. 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.

Étape 2 : Activez la délégation d'authentification

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.

Configurez IIS

  1. Dans IIS Manager, cliquez sur l'application WorkflowGen dans l'arborescence.

  2. Cliquez sur le bouton Authentication.

  3. Activez Anonymous Authentication et désactivez toutes les autres authentification.

  4. Répétez ces étapes pour toutes les sous-applications.

Ajoutez des propriétés aux fichiers web.config de certains modules

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

  1. Ajoutez la propriété suivante au fichier web.config de WorkflowGen :

    <?xml version="1.0" encoding="UTF-8"?>
    <configuration>
    <system.webServer>
    <modules>
    <add name="ApplicationSecurityAuthenticationModule" type="Advantys.Security.Http.JWTAuthenticationModule" />
    </modules>
    </system.webServer>
    </configuration>
  2. Ajoutez la propriété suivante au fichier web.config du module auth :

    <?xml version="1.0" encoding="UTF-8"?>
    <configuration>
    <system.webServer>
    <modules>
    <remove name="ApplicationSecurityAuthenticationModule"/>
    </modules>
    </system.webServer>
    </configuration>

    Cette ligne enlève le module d'authentification Node.js du système d'authentification global, car cette application Node.js encapsule les mécanismes d'authentification de OpenID connect.

  3. Répétez les deux étapes précédentes pour les modules hooks et scim.

  4. Copiez les assemblies et bibliothèques de dépendances .NET suivants de \wfgen\bin dans les dossiers \bin de tous les formulaires Web personnalisés (\wfgen\wfapps\webforms\<custom webform>\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 à Okta via le protocole OpenID Connect. Assurez-vous d'avoir approvisionné vos utilisateurs à WorkflowGen afin qu'ils puissent accéder à WorkflowGen.

Options configurables

Ce tableau liste toutes les options configurables dans WorkflowGen que vous pouvez utiliser pour personnaliser votre expérience d'authentification; elles se trouvent dans le fichier web.config de WorkflowGen.

Option

Description

ApplicationSecurityAuthSessionTokenCookie

Le nom du cookie de session généré par le module d'authentification. Valeur par défaut : wfgen_token Note : Ceci est utile quand vous avez de multiples instances de WorkflowGen en fonctionnement auxquelles vous voulez accéder lorsque vous êtes authentifié sur les deux instances en même temps.

ApplicationSecurityAuthSessionTimeOut

La durée de la session en secondes. Sa valeur par défaut est le temps d'expiration du jeton d'ID reçu du fournisseur. Valeur par défaut : la valeur d'expiration (« exp value ») du jeton d'ID

ApplicationSecurityAuthMobileSessionTimeOut

La durée de la section en secondes lorsqu'elle est demandée par des appareils mobiles sur le point de terminaison de jeton. Valeur par défaut : 7200 secondes

Approvisionnement des utilisateurs dans Okta

Le connecteur d'approvisionnement automatique est un connecteur d'annuaire qui crée et synchronise un utilisateur automatiquement selon ses revendications des jetons de session qui contiennent les revendications du jeton d'ID du fournisseur OpenID Connect. Cette fonctionnalité est uniquement compatible avec l'authentification OpenID Connect.

Prérequis

  • Assurez-vous d'avoir une instance de WorkflowGen en fonctionnement.

  • Assurez-vous de connaître l'adresse IP de l'instance ou son nom complet.

  • Assurez-vous de connaître l'adresse de l'instance.

  • Assurez-vous d'avoir configuré Okta ou une des trois autres méthodes conformes OIDC (Azure Active Directory, AD FS ou Auth0.

Configuration de WorkflowGen

Cette section vous guidera à travers les configurations de WorkflowGen nécessaires pour créer la fonctionnalité d'approvisionnement automatique avec un annuaire.

Étape 1 : Créez un annuaire d'approvisionnement automatique

Ce répertoire contiendra tous les utilisateurs qui ne sont pas approvisionnés ailleurs. Pour créer un annuaire d'approvisionnement automatique :

  1. Dans la page Annuaires du module d'administration de WorkflowGen, cliquez sur Nouvel annuaire.

  2. Renseignez le formulaire :

    • Nom : AUTO_APPROVISIONNEMENT (ou n'importe quoi)

    • Description : Une bonne description de l'annuaire

    • Connecteur d'annuaire : Approvisionnement automatique

  3. Cliquez sur Enregistrer.

Étape 2 : Configurez les correspondances entre les champs d'utilisateurs et les revendications

Maintenant que vous avez créé un nouvel annuaire avec le connecteur d'approvisionnement automatique, vous devez définir les correspondances entre les revendications et les champs d'utilisateurs de WorkflowGen. Pour ce faire :

  1. Dans la page du nouvel annuaire, cliquez sur Correspondances.

  2. À droite du nom du champs de l'utilisateur WorkflowGen, saisissez le nom de la revendication dans le jeton de session pour lequel vous voulez créer la correspondance.

    Voici un exemple un jeton de session généré par l'application node auth depuis un jeton d'ID Okta connecté avec Google Apps :

    {
    "sub": "some.user@advantys.com",
    "iss": "https://<workflowgen_url>/auth",
    "aud": "https://<workflowgen_url>",
    "exp": 1535627127,
    "https://api.workflowgen.com/username": "some.user@advantys.com",
    "given_name": "Some",
    "family_name": "User",
    "nickname": "some-user",
    "name": "Some User",
    "picture": "https://lh4.googleusercontent.com/path/to/photo.jpg",
    "gender": "male",
    "locale": "en",
    "updated_at": "1970-01-01T00:00:00Z",
    "email": "some.user@advantys.com",
    "email_verified": true,
    "nonce": "ffdd6d95-31e6-4466-84c4-43f8c0fbaae7",
    "iat": 1535591128
    }

    Note : Les champs Nom d'utilisateur et Nom sont obligatoires.

  3. Cliquez sur Enregistrer.

Configuration d'Okta pour les applications mobiles

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 Okta pour les applications mobiles afin que vos utilisateurs mobiles puissent aussi bénéficier de l'authentification déléguée.

Prérequis

  • 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 Okta pour pouvoir le configurer.

  • Assurez-vous d'avoir approvisionné un utilisateur Okta existant depuis lequel vous pourrez vous authentifier à WorkflowGen pour pouvoir utiliser l'application après.

  • Assurez-vous d'avoir installé la plus récente version de WorkflowGen Plus sur votre appareil et que l'appareil est supporté.

  • Assurez-vous d'avoir bien configuré l'authentification déléguée à Okta sur votre instance de WorkflowGen en suivant les instructions dans la section Authentification Okta.

Configuration d'Okta

Étape 1 : Créez une application native

  1. Cliquez sur le bouton Add Application dans l'onglet Applications de votre portail développeur Okta.

  2. Choisissez l'option Native, puis cliquez sur Next.

  3. Saisissez les informations suivantes :

    • Name : Mon application native (ou le nom de votre application)

    • Login Redirect URIs : Ajoutez vos URIs de redirection personnalisés ici

    Note : Assurez-vous d'avoir coché l'option Authorization Code.

  4. Cliquez sur le bouton Done.

Étape 2 : Ajoutez un URI de redirection de déconnexion

  1. Cliquez sur le bouton Edit dans l'onglet General dans la page de votre application native Okta.

  2. Cliquez sur le bouton Add URI à côté de la propriété Title de Logout redirect URIs.

  3. Saisissez votre URI de redirection de déconnexion personnalisé dans le champ de texte qui s'affiche.

  4. Cliquez sur Save.

Étape 3 : Ajoutez un URL de rappel

Dans l'onglet Settings, défilez vers le bas jusqu'à la section Allowed Callback URLs et ajoutez-y l'URL workflowgenplus://auth.authorize/okta.

Vérifiez l'inscription

Si vous avez configuré l'authentification déléguée à Okta sur votre serveur WorkflowGen, vous devriez avoir une stratégie d'accès sur votre serveur d'autorisation Okta de l'API GraphQL de WorkflowGen qui permettra à tous les utilisateurs configurés d'y accéder; il ne reste rien à faire du côté d'Okta. Voici un résumé des informations dont il vous faut :

  • Un ID client, qui se trouve dans l'onglet Settings dans la page de l'application native.

  • Un nom de domaine Okta, qui se trouve directement à gauche de votre photo de profil en haut à droite de la page.

Toutes ces informations doivent être données aux utilisateurs qui utiliseront l'application mobile; ils devront les copier-coller directement dans l'application.

Configuration d'Okta pour les scripts côté serveur

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 Okta 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 Okta, et ensuite vous devez configurer une nouvelle applications dans WorkflowGen.

Prérequis

  • 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 Okta pour pouvoir le configurer.

  • Assurez-vous d'avoir bien configuré l'authentification déléguée à Okta sur votre instance de WorkflowGen en suivant les instructions dans la section Authentification Okta.

Configuration d'Okta

Ajoutez une nouvelle application

  1. Dans la section Applications de votre portail développeur, cliquez sur le bouton Add Application.

  2. Sélectionnez le type Service, puis cliquez sur Next.

  3. Saisissez le nom de votre application, puis cliquez sur Done.

Vérifiez l'inscription

Voici un résumé des informations dont il vous faut :

  • Un ID client, qui se trouve dans l'onglet des paramètres de l'application inscrite.

  • Une clé secrète client, qui se trouve dans l'onglet des paramètres de l'application inscrite.

  • L'identifiant de l'API GraphQL de WorkflowGen, qui se trouve dans sa page des paramètres.

Configuration de 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.

Inscrivez une nouvelle application

  1. Dans la page Applications du module d'administration de WorkflowGen, cliquez sur Nouvelle application.

  2. Renseignez le formulaire :

    • Name : Mon application serveur

    • Description : Une description qui indique clairement qui identifie clairement le script

    • Type : Non-interactive Client

    • Impersonate username : Un nom d'utilisateur qui a les permissions requises pour accéder à l'API GraphQL

    • Client ID : L'ID client que vous avez retrouvée plus tôt

    • Active : Cochez cette case à cocher

  3. Cliquez sur Save.

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'Okta via le flux Client Credentials Grant.

Configuration d'Okta pour les applications monopages

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.

(Source : https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-dev-understanding-oauth2-implicit-grant)

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 Okta 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 : inscrire l'application monopage, lui donner accès à l'API et régler quelques URLs de redirection.

Prérequis

  • 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 Okta pour pouvoir le configurer.

  • Assurez-vous d'avoir approvisionné un utilisateur Okta existant depuis lequel vous pourrez vous authentifier à WorkflowGen pour pouvoir utiliser l'application après.

  • Assurez-vous d'avoir bien configuré l'authentification déléguée à Okta sur votre instance de WorkflowGen en suivant les instructions dans la section Authentification Okta.

Étape 1 : Inscrivez une nouvelle application monopage

  1. Dans l'onglet Applications de votre portail développeur Okta, cliquez sur le bouton Add Application.

  2. Choisissez le type Single-Page App, puis cliquez sur Next.

  3. Saisissez les informations suivantes :

    • Name : Mon SPA, ou le nom de votre application monopage

    • Base URIs : L'URL de base de votre application

    • Login redirect URIs : L'URI de redirection pour votre application monopage

  4. Cliquez sur Done.

Étape 2 : Ajoutez un URI de redirection de déconnexion

  1. Cliquez sur le bouton Edit dans l'onglet General dans la page de votre application native Okta.

  2. Cliquez sur le bouton Add URI à côté de la propriété Title de Logout redirect URIs.

  3. Saisissez votre URI de redirection de déconnexion personnalisé dans le champ de texte qui s'affiche.

  4. Cliquez sur Save.

Vérifiez l'inscription

  • Vous devez avoir un ID client, qui se trouve dans l'onglet General dans la page de l'application.

Votre application devrait maintenant être liée à l'infrastructure Okta et les utilisateurs pourront se connecter par elle. Si vous avez satisfait aux prérequis, votre application recevra un jeton d'accès qu'elle pourra envoyer à l'API GraphQL de WorkflowGen pour faire des requêtes autorisées en tant que jeton du porteur via l'en-tête Authorization.

Génération d'un lien universel pour WorkflowGen Plus

Depuis la version 1.4.0 de WorkflowGen Plus et la version 7.14.0 de WorkflowGen serveur, vous pouvez générer un lien universel pour simplifier le processus de connexion Okta de vos utilisateurs de l'application mobile WorkflowGen Plus.

URL de base

  • protocol: workflowgenplus://

  • hostname: auth.init

Paramètres

Vous devez régler les paramètres suivants :

  • provider : okta

  • client_id : Utilisez l'ID client que vous avez créé antérieurement dans la configuration (p.ex. : 0o7gdj4hs92yh7).

  • domain : Le nom du domaine Auth0 sans le protocole URL (p.ex. : https://dev-958754.oktapreview.com/oauth2/{AUTH_SERVER_ID}/.well-known/openid-configuration%60).

    Note : La valeur doit être encodée URL.

  • audience : Votre URL WorkflowGen (p.ex. : `http://workflow.mycompany.com/wfgen``).

    Note : La valeur doit être encodée URL.

Le lien universal devrait suivre cette structure :

workflowgenplus://auth.init?provider=okta&client_id=0o7gdj4hs92yh7&domain=https%3A%2F%2Fdev-958754.oktapreview.com%2Foauth2%2F{AUTH_SERVER_ID}%2F.well-known%2Fopenid-configuration&audience=http%3A%2F%2Fworkflow.mycompany.com%2Fwfgen

Une fois que vous aurez généré le lien universel, donnez-le à vos utilisateurs, qui pourront l'utiliser pour se connecter à WorkflowGen Plus par la méthode préconfigurée.

Informations supplémentaires sur l'intégration Okta

Support des services SOAP

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 :

  1. Créez un nouvel annuaire WorkflowGen séparé pour les utilisateurs de l'API SOAP.

  2. Approvisionnez-le avec des utilisateurs et des groupes au besoin.

  3. Dans IIS Manager, cochez la méthode d'authentification Basic pour l'application ws.