Utilisateurs internes
Les utilisateurs internes peuvent être authentifiés dans une ou plusieurs méthodes d’authentification login dans un environnement, ce qui permet de personnaliser l’expérience de connexion, par exemple selon différentes exigences d’application.
Importez vos utilisateurs depuis un fichier CSV, avec ou sans mot de passe.
Pour une vue d’ensemble des concepts d’utilisateurs (utilisateurs internes, utilisateurs externes et magasins d’utilisateurs externes), voir la vue d’ensemble des utilisateurs.
Identifiants utilisateur
Les utilisateurs internes prennent en charge trois identifiants utilisateur : email, numéro de téléphone et nom d’utilisateur. Ces identifiants forment l’identifiant (partie username) lorsqu’un utilisateur se connecte avec un nom d’utilisateur et un mot de passe.
Vous pouvez choisir d’en activer un, deux ou les trois.
Numéro de téléphone comme identifiant utilisateur uniquement.

Email, numéro de téléphone et nom d’utilisateur comme identifiants utilisateur.

Vérification du mot de passe
Les utilisateurs internes peuvent être authentifiés avec un mot de passe. Le mot de passe est vérifié par rapport à la politique de mot de passe intégrée (par défaut ou groupe de politiques) et éventuellement une API de mot de passe externe.
Politique de mot de passe intégrée et expiration
La politique de mot de passe par défaut est configurée dans les paramètres de l’environnement dans le FoxIDs Control Client et s’applique lorsqu’aucun groupe de politique de mot de passe n’est assigné à l’utilisateur.
- Sélectionnez l’onglet Settings
- Puis sélectionnez l’onglet Environment
- Trouvez la section Password settings
- Configurez la zone Default password policy :
- Password min length et Password max length pour définir la plage autorisée.
- Check password complexity pour imposer la variété des classes de caractères et s’assurer que le mot de passe ne contient pas des parties de l’URL ou des identifiants utilisateur (email, téléphone, nom d’utilisateur).
- Check password risk based on global password breaches pour rejeter les mots de passe trouvés dans des listes à risque (auto-hébergé voir risk Passwords).
- Banned characters (case-insensitive) pour bloquer des caractères spécifiques.
- Password history (number of previous passwords, 0 to disable) pour empêcher la réutilisation des mots de passe récents.
- Password max age in seconds (0 to disable) pour forcer un changement lorsque le mot de passe est trop ancien.
- Soft password change in seconds (0 to disable) pour autoriser une période de grâce : lors de la connexion, un mot de passe non conforme ou expiré invite l’utilisateur à le changer mais permet toujours la connexion jusqu’à la fin de la période.
- Cliquez sur Update

Groupes de politiques de mot de passe
Vous pouvez définir jusqu’à 10 groupes de politiques de mot de passe par environnement. Un groupe remplace la politique de mot de passe par défaut pour les utilisateurs qui y sont assignés.
- Sélectionnez l’onglet Settings
- Puis sélectionnez l’onglet Environment
- Trouvez la section Password settings
- Configurez la zone Password policy groups :
- Cliquez sur Add policy group et définissez les valeurs de la politique (mêmes champs que la politique par défaut) ainsi qu’un nom et un nom d’affichage optionnel.
- Cliquez sur Update
- Appliquez un groupe à un utilisateur dans Internal Users → modifier l’utilisateur → Advanced → Password policy, ou définissez le nom de la politique lors du provisionnement via l’API Control. Si aucun groupe n’est sélectionné, la politique par défaut de l’environnement est utilisée.
API de mot de passe externe
Vous pouvez éventuellement configurer une API de mot de passe externe pour valider les mots de passe et/ou notifier les changements de mot de passe.
Si la politique de mot de passe intégrée rejette le mot de passe, l’API de mot de passe externe n’est pas appelée. La méthode de notification de l’API de mot de passe externe n’est appelée que si le mot de passe a passé toutes les vérifications de politique configurées.
Mot de passe ou mot de passe à usage unique (passwordless)
La méthode d’authentification login est configurée par défaut pour nom d’utilisateur (identifiant utilisateur) + mot de passe.
Vous pouvez également activer le mot de passe à usage unique (OTP) via email et/ou SMS pour la connexion sans mot de passe, et vous pouvez créer plusieurs méthodes d’authentification login avec différentes combinaisons.
Si le mot de passe et l’OTP sont tous deux activés, toutes les méthodes activées sont proposées. L’UI permet également l’auto-création de compte.

Si seul l’OTP via email est activé :

Créer un utilisateur
Selon la configuration du login sélectionné, les utilisateurs peuvent créer un compte en ligne.
L’utilisateur choisit de créer un nouveau compte sur la page de connexion.

Formulaire pour créer un utilisateur.

La page est composée d’éléments dynamiques qui peuvent être personnalisés par méthode login.
Dans cet exemple, le formulaire contient les champs Given name, Family name, Email et Password.
Le champ Email est un identifiant utilisateur utilisé pour la connexion.
Voici la configuration dans la méthode login. En plus, le claim some_custom_claim est ajouté à chaque utilisateur comme constante via une transformation de claim.

Provisionnement
Les utilisateurs internes peuvent être créés, mis à jour et supprimés dans le Control Client ou provisionnés via la Control API. Et importer de nombreux utilisateurs à partir d’un fichier CSV.

Authentification multi facteurs (MFA)
L’authentification à deux facteurs / multi facteurs peut être requise par utilisateur. L’utilisateur doit alors s’authentifier avec un facteur supplémentaire (SMS, email ou application d’authentification) et peut enregistrer une application d’authentification si elle n’est pas déjà enregistrée.
Les seconds facteurs disponibles peuvent être configurés par utilisateur et par méthode login. Voir two-factor authentication.
Vous pouvez voir si une application d’authentification est enregistrée et un administrateur peut la désactiver.

Hachage du mot de passe
Seul un hachage de mot de passe est stocké.
Le sous-système de hachage prend en charge l’évolution : les métadonnées de hachage (algorithme + paramètres) sont stockées avec chaque hachage, ce qui permet de valider les anciens hachages tandis que les nouveaux hachages utilisent des algorithmes / paramètres plus récents.
Algorithme de hachage actuellement pris en charge P2HS512:10 (définition) :
- HMAC (
RFC 2104) avec SHA-512 (FIPS 180-4) - 10 itérations stockées dans les métadonnées de hachage, multipliées par 10,000 tours PBKDF2 (100,000 itérations au total)
- Longueur du sel : 64 octets
- Longueur de clé dérivée : 80 octets
- Le hachage et le sel sont stockés sous forme de chaînes encodées Base64 URL (Base64 sans padding)
Les bibliothèques .NET standard sont utilisées pour calculer le hachage.