Réinitialisation du mot de passe

Vue d'ensemble

Les utilisateurs peuvent réinitialiser leurs mots de passe oubliés grâce au flux de travail décrit en détail ci-dessous. En bref, un lien de réinitialisation du mot de passe est envoyé à un utilisateur qui clique sur un lien menant à un formulaire qui permet à la personne de définir son nouveau mot de passe.

Processus

Discussion

• Le processus commence lorsqu'un utilisateur se rend compte qu'il a oublié le mot de passe d'une application frontale particulière et qu'il visite la page "Password reset" de l'application frontale. et visite une page "Réinitialisation du mot de passe" dans l'application frontale.

• L'application demande à l'utilisateur un nom d'utilisateur, un email ou l'un des deux, selon la valeur l'entrée password_reset.user_search_by dans sso.conf a été définie comme suit

• L'identifiant est transmis à Zato SSO qui répond toujours par un message OK à l'application frontale. C'est-à-dire qu'il n'indique jamais à l'application frontale qu'un nom d'utilisateur ou une adresse électronique n'est pas valide. Ceci afin d'empêcher les attaquants de découvrir les noms d'utilisateur ou les emails disponibles dans le système.

• Si l'identifiant est valide, Zato envoie un courriel à l'utilisateur avec un lien vers le mot de passe sur lequel il doit cliquer pour le réinitialiser. Le nom de la connexion SMTP à utiliser est configuré via main.smtp_conn dans sso.conf. Le lien contient un token qui est un secret à usage unique qui peut être utilisé pour réinitialiser la connexion SMTP.

• Le token est considéré comme expiré après les minutes password_reset.valid_for de sso.conf. Par défaut, c'est 1440 minutes = 24 heures.

• Le modèle d'email est lu à partir d'un fichier sous le chemin /path/to/server/config/repo/static/sso/email//password-rest-link.txt. Si aucune langue préférée n'est sélectionnée pour l'utilisateur, en_GB est utilisé.

• L'utilisateur clique sur le lien reçu qui mène à l'application frontale. L'application frontale envoie le token du lien à Zato SSO qui vérifie si le token et l'utilisateur sont valides.

• Si le token n'est pas valide, par exemple s'il n'existe pas ou s'il a déjà été visité, une erreur est renvoyée à l'application frontale.

• Si le token est valide mais que l'utilisateur n'est pas autorisé à accéder au SSO, par exemple si le compte a été verrouillé entre-temps, une erreur est également renvoyée.

• Si le token et l'utilisateur sont tous deux valides, le token est marqué dans la base de données comme ayant été utilisé et un statut OK est renvoyé au front-end avec une clé de réinitialisation.

• La clé de réinitialisation est une chaîne aléatoire qui ne peut être utilisée qu'une seule fois, lors de cette tentative très particulière de réinitialisation du mot de passe.

• Le frontend demande à l'utilisateur un nouveau mot de passe et envoie au SSO les trois éléments : token, clé de réinitialisation et nouveau mot de passe.

• Le SSO valide le token, la clé de réinitialisation et vérifie si l'utilisateur est toujours autorisé à accéder au système. S'ils sont valides, le mot de passe est également validé selon les règles de complexité du mot de passe du sso.conf.

• Si l'étape de validation échoue parce que le token ou la clé de réinitialisation ne sont pas valides, le frontend reçoit le code d'erreur E010001.

• Si l'étape de validation échoue parce que l'utilisateur est rejeté, le frontend reçoit le code d'erreur E005001.

• Si l'étape de validation échoue parce que le mot de passe ne correspond pas aux attentes de complexité, le frontend reçoit un code d'erreur différent des deux ci-dessus.

• Si l'étape de validation réussit, le mot de passe est changé et le token et la clé de réinitialisation sont marqués dans la base de données comme déjà utilisés.

Notes

• Le modèle password-rest-link.txt peut être modifié directement dans le système de fichiers, sans redémarrage du serveur.

• Les tokens et les clés de réinitialisation ne sont jamais supprimés de la base de données.

• Pour les tokens et les clés de réinitialisation, des informations supplémentaires sont conservées dans la base de données - à partir de quelle adresse distante ils ont été accédés et quel était l'agent utilisateur. Ces informations ne sont pas disponibles par le biais d'un appel API.

• Un token ne peut être consulté qu'une seule fois, c'est-à-dire qu'il n'est pas possible de cliquer plusieurs fois sur le même lien de réinitialisation du mot de passe.

• Comme le token n'est accessible qu'une seule fois, la clé de réinitialisation renvoyée lors de l'accès au token est garantie de ne pas être renvoyée à un autre appelant utilisant le même token.

• La clé de réinitialisation peut être envoyée au SSO autant de fois que nécessaire pour changer le mot de passe, tant que la clé de réinitialisation n'a pas expiré avec le token. Par exemple, lorsqu'un utilisateur saisit un mot de passe trop simple, le SSO renvoie un message d'erreur et l'utilisateur peut avoir une autre chance de saisir un mot de passe plus fort, ce qui implique d'envoyer le token, la clé de réinitialisation et le nouveau mot de passe une fois de plus, jusqu'à ce que le mot de passe soit attendu (ou que le token et la clé de réinitialisation expirent).

Résumé des appels API

• L'application frontale fait appel à trois endpoints ou services :

• Tout d'abord, pour générer un token et envoyer un email avec un lien - le lien contient le token.

• Ensuite, pour valider le token du lien cliqué et générer une clé de réinitialisation.
• Enfin, le mot de passe est basé sur le token, la clé de réinitialisation et le nouveau mot de passe fourni par l'utilisateur.

Autres moyens de changer le mot de passe d'un utilisateur

• Les mots de passe peuvent être changés par REST, Python et en ligne de commande.
• En outre, il est possible de réinitialiser son mot de passe à partir de la ligne de commande - un nouveau mot de passe fort (192 bits) sera généré et imprimé sur stdout.