Guide d’utilisation des modes de connexion avec Account

Modes

La plateforme DAZZM supporte 3 modes de connexion :

1. Lien de connexion unique obtenu par email

2. Nom d’utilisateur et mot de passe

3. Connection avec un compte Microsoft

Multiples modes

La plateforme supporte l’activation de multiples modes à la fois. On peut même, comme dans l’exemple ici-bas, avoir les 3 modes disponible simultanément :

Configuration via Account

C’est dans l’application Account que vous pouvez configurer les modes d’authentification de votre application. Chaque environnement devra être configuré de manière individuelle. Par exemple, l’environnement de production pourrait utiliser « Nom d’utilisateur et mot de passe » alors que l’environnement de dev pourrait utiliser « Lien de connexion unique obtenu par email ».

Voici comment cela est présenté dans Account. Ici, on voit que deux modes sont actifs, et qu’un mode ne l’est pas.

Pour activer un mode, il suffit de configurer ses options, ce qui peut être fait en cliquant sur sa tuile.

Mode : Lien de connexion unique obtenu par email

Il s’agit d’un mode unique à la plateforme, aussi connu comme « Magic Link ».

Options disponible

En plus de son fonctionnement de base, il existe ces options :

- Expiration de la session, forçant l’utilisateur à se reconnecter après un certain nombre de minutes. Bien qu’exprimé en minutes, il est plus probable d’y mettre un nombre plus élevé, comme 4 heures.

- Second facteur de connexion par SMS (MFA). Après avoir utilisé le lien reçu par email, un SMS est envoyé et l’utilisateur doit inscrire le code.

Notes

- Bien qu’on le qualifie de « lien » de connexion, l’expérience sur mobile envoie un « code » plutôt qu’un hyperlien car dans le contexte d’une app mobile, cliquer un lien dans l’email ouvrirait le navigateur sur le téléphone plutôt que de réactiver l’onglet d’où l’utilisateur a lancé sa session.

- Sur mobile, si le second facteur de connexion par SMS est actif, alors l’utilisateur recevra d’abord un code par email, puis un second code par SMS.

Voici les options de configuration de ce mode :

Prérequis

- Ce mode nécessite uniquement le champ « email », qui existe par défaut sous l’Agrégat « User ».

- Pour activer le second facteur de connexion par SMS, Il faudra créer un champ sous l’agrégat « User » qui contiendra les numéros de mobile. Le nom du champ n’est pas fixe. Une fois créé, vous pourrez activer ce second facteur en sélectionnant le champ dans Account.

Mode : Nom d’utilisateur et mot de passe

Mode traditionnel où un nom d’utilisateur et un mot de passe sont attribués à l’utilisateur.

Options disponibles

En plus de son fonctionnement de base, il existe ces options :

- Contrôle de la complexité du mot de passe.

- Expiration de la session, forçant l’utilisateur à se reconnecter après un certain nombre de minutes. Bien qu’exprimé en minutes, il est plus probable d’y mettre un nombre plus élevé, comme 4 heures.

- Second facteur de connexion par SMS (MFA). Après avoir utilisé son mot de passe pour se connecter, un SMS est envoyé et l’utilisateur doit inscrire le code.

Voici les options de configuration :

Prérequis

- Ce mode nécessite quelques prérequis. Pour vous simplifier la tâche, nous avons créé une fonctionnalité qui les génèrera automatiquement. Il suffit de cliquer sur « Install requirement ».

Cette action a pour effet de :

• Ajouter les champ « username » et « password » à votre Agrégat « User »

• Créer une commande « changeCredentials »¹

• Créer un workflow « Password changed notification »

- Pour activer le second facteur de connexion par SMS, Il faudra créer un champ sous l’agrégat « User » qui contiendra les numéros de mobile. Le nom du champ n’est pas fixe. Une fois créé, vous pourrez activer ce second facteur en sélectionnant le champ dans Account.

¹Cette commande peut être supprimée si le client n’a pas besoin de ce cas. Ce cas est seulement nécessaire si des utilisateurs finaux n’ont aucun accès email, ce qui est un scénario possible, entre autres, dans le domaine de la santé.

Configuration

Ce mode d’authentification supporte plusieurs « user stories » :

1. En tant qu'utilisateur, je veux me connecter avec mon nom d'utilisateur et mon mot de passe.

2. En tant qu'utilisateur, je veux réinitialiser mon mot de passe.

3. En tant qu'administrateur, je veux définir le nom d'utilisateur pour un nouvel utilisateur et lui envoyer une invitation par courriel pour qu'il crée son mot de passe.

4. En tant qu'utilisateur, je veux créer mon mot de passe après avoir reçu une invitation.

5. En tant qu'administrateur, je veux définir le nom d’utilisateur et mot de passe temporaire d'un utilisateur, car l'utilisateur n'a pas accès à un compte de courriel pour recevoir un courriel.

Après avoir installé les requis minimums, le créateur de solutions doit modifier son application.

Voici les étapes à suivre pour la « user storie » #3:

- Lors de la création du profil d’un nouvel utilisateur, l’administrateur devra lui assigner un Username. Voici les 2 options de configuration:

Option 1 : ajouter le champ « username » comme requis à la commande « create ».

Option 2 : Si vous préférez que son courriel soit utilisé comme « username », plutôt que d’avoir un champ séparé, alors il faut supprimer le champ « username » qui a été créé pour vous, et le recréer comme un « computed field » retournant « data.email ».

- Ensuite, il faut ajouter un bouton et l’associer au behavior « Send Password Invite ». Celui-ci permettra d’envoyer un courriel avec un « Magic Link » à l’utilisateur afin qu’il configure son mot de passe. Ce « Magic Link » sera fonctionnel qu’une seule et unique fois.

Afin d’éviter qu’un autre employé ne modifie « username » et/ou courriel et puisse ensuite modifier le mot de passe par un « magik link », il sera important de rendre ces champs (ou la page) uniquement disponibles aux administrateurs et potentiellement au « curent user » par l’utilisation de CanAccess.

Voici les étapes à suivre pour la « user storie » #5:

- Il faut d’abord ajouter un bouton et l’associer au behavior « Execute a Command » avec la commande « changeCredentials ». Celui-ci permettra à un admin d’assigner le nom d’utilisateur et premier mot de passe à un nouvel utilisateur.

Il lui transmettra les détails de son identifiant de connexion en main propre ou de vive voix, puisque ce dernier n’a pas de courriel.

Il sera important de rendre ce bouton ou la page de détail d’un employé uniquement disponible aux administrateurs et au « curent user » par l’utilisation de CanAccess, afin d’éviter qu’un employé ne modifie l’identifiant de connexion de quelqu’un d’autre.

Démo  

Une fois ces configurations en place, la fonctionnalité est prête à utiliser. Voici quelques captures d’écrans démontrant la fonctionnalité :

Mode : Connection avec un compte Microsoft

Ce mode délègue à Microsoft tout le processus d’authentification. Il est avantageux car il donne beaucoup d’option au client au niveau des politiques. Par exemple, c’est du côté de la configuration « Azure Active Directory » que le client contrôle les options de MFA, incluant SMS, Microsoft Authenticator et autres. Il contrôle aussi les durées d’expiration des sessions qui peuvent même varier selon les groupes de l’utilisateur ou selon le fait qu’il est sur une connexion interne ou externe.

Options

En plus des options configurables du côté d’Azure Active Directory, ce mode offre deux options

• Forcer l'utilisateur à se reconnecter est configuré dans Azure Active Directory. Si cette option est désactivée, les sessions ne prendront pas fin, même si la configuration dans Active Directory indique qu'elles devraient expirer. Il est fortement recommandé de ne pas désactiver l'expiration des sessions à moins que cela ne soit expressément demandé par le client.

• Créer un utilisateur Microsoft inconnu : avec cette option, il n'est pas nécessaire de créer des utilisateurs à l'avance. Lorsqu'un utilisateur se connecte pour la première fois, Azure Active Directory renvoie les informations minimales de cet utilisateur, et l'application crée automatiquement un enregistrement pour lui.

Voici les deux options, telles qu'elles apparaissent dans le dialogue Microsoft :

Prérequis

- Ce mode nécessite qu’un champ « email » et qu’une commande « createFromOpenID » existe sous l’Aggregate « User ». En utilisant « install requirements » ces prérequis seront automatiquement mis en place pour vous.

Configuration

Lien entre votre application et l’environnement Azure AD du client

Pour pouvoir activer ce mode de connexion, il faut d’abord que le client autorise l’application à utiliser son « Azure Active Directory » en ajustant la configuration de son côté. Pour ce faire, vous devez fournir au client l’URL de votre application. L’administrateur chez le client l’utilisera dans sa configuration. (Voir section « Configuration de Azure Active Directory par le client » plus bas dans ce document pour plus de détails.)

En retour, l’administrateur chez le client devra vous donnera deux « ID » que vous configurerez dans cet écran :

Personnalisation de la commande « createFromOpenID »

Si vous avez activé l’option “Create unknown Microsoft user when they connect” alors, lorsqu’un nouvel utilisateur se connectera, le système appellera la commande « createFromOpenID ».

Cette commande ne doit pas être placée dans les écrans, elle appartient au mécanisme de connexion avec un compte Microsoft, toutefois vous pourriez avoir à la modifier.

Dans votre application, vos « user » on potentiellement des champs que vous jugez obligatoires, par exemple le champ « rôle ». Normalement, les champs nécessaires à la création d’un nouvel utilisateur seront à la fois dans la page de son profil, que dans la commande « create » et/ou vous avez attribué des valeurs par défaut.

Dans le cas de la création automatique, vous devez personnaliser la commande « createFromOpenID » pour qu’elle aussi initialise les champs essentiels. Par exemple, si vous avez un champs « rôle », vous devez déterminer avec le client quel rôle attribuer lorsqu’un utilisateur est créé automatiquement. Pour ce faire, vous devez ajouter un « mutation field » approprié.

Attention, il ne faut pas modifier les « parameters » de cette commande, seulement les « mutation fields ». La modification des parameters causera un bris de la fonctionnalité.

Démo  

Une fois ces configurations en place, la fonctionnalité est prête à utiliser. Voici la fonctionnalité :

Comment déployer un nouveau mode

Étape 1 : Dans un environnement de dev

1. Créer un environnement de dev

2. Activer le mode dans Account, pour votre environnement de dev

3. Modifier l’application s’il y a lieu (l’écran et/ou l’agrégat User)

4. Pousser les changements

Étape 2 : Dans l’environnement de prod (ou de QA)

1. Déployer l’application

2. Refaire les mêmes configurations du mode d’authentification dans Account

Attention : Le période entre l’étape 1 et l’étape 2 met l’application dans un état potentiellement incohérent. Par exemple, votre écran User pourrait présenter une action « Envoyer invitation » alors que vous n’avez pas encore activer le mode « Nom d’utilisateur et mot de passe ». Rien de grave ne se produira, mais c’est préférable de faire les deux actions rapidement.

Étape 3 : Ajuster la configuration en dev pour un mode plus simple

Une fois que vous aurez déployé vos changements en production, vous pourriez décider de modifier la configuration dans Account. Par exemple, si en production l’application ne supporte que « Nom d’utilisateur et mot de passe », vous pouvez désactiver ce mode dans votre environnement de dev et activer uniquement « Lien de connexion unique obtenu par email ». Vos prochains « push » n’affecterons pas l’environnement de production.

Si vous faites cela, il pourrait y avoir une incohérence dans votre environnement. Par exemple, votre écran User pourrait présenter une action « Envoyer invitation » alors que vous avez désactivé le mode « Nom d’utilisateur et mot de passe ». Cela n’est rien de grave. L’important à retenir est que la configuration de votre environnement est « locale » et que vous ne risquez pas d’affecter les autres environnements en modifiant les options du vôtre.

Configuration de Azure Active Directory par le client

Cette section décrit à très haut niveau les actions à prendre par l’Admin « Azure Active Directory » chez le client. Ça ne se veut pas un guide à donner au client, la configuration Azure Active Directory est beaucoup trop variable pour que nous puissions offrir un support sur la configuration. Cela se veut plutôt comme un aperçu, permettant aux créateurs de solutions d’avoir une idée générale de la nature des modifications qui doivent être faites et pour expliquer comment l’URL de l’application, le « Application ID » et le « Tenant ID » sont utilisé.

Dans ces écrans on voit Octopus-ITSM.com comme compagnie. Cela représente le propriétaire de l’environnement « Azure Active Directory ». Quand le client fera sa propre configuration, il y verra le nom de son organisation. Donc, ici, on voit comment l’admin du domaine « Azure Active Directory » de Octopus-ITSM.com autorise une application DAZZM à utiliser ses services d’authentification.

1 – Enregistrer l’application en lui donnant un nom, en indiquant qui peut s’y connecter et en y mettant l’URL de l’application.

2 – Dans la section Authentication, activer “ID tokens (used for implicit and hybrid flows)”

3 – Envoyer les Application ID et Directory ID au créateur de solution