Utilisateurs externes
Vous pouvez utiliser le provisionnement just-in-time (JIT) pour créer des utilisateurs externes et les associer à une identité externe. Un utilisateur externe est associé à une méthode d’authentification (OpenID Connect, SAML 2.0, External Login ou Environment Link) et ne peut être authentifié qu’en utilisant cette méthode d’authentification. L’utilisation d’utilisateurs externes est optionnelle ; ils ne sont pas créés par défaut.
Tous les utilisateurs externes regroupés sous une méthode d’authentification sont liés au même type de claim (par exemple le type de claim sub) et les utilisateurs sont séparés par des valeurs de claim uniques.
Avec les utilisateurs externes, vous pouvez stocker des claims sur chaque utilisateur. Par exemple, stocker votre claim d’ID utilisateur représentant l’utilisateur dans votre système et ainsi mapper l’ID utilisateur externe à votre ID utilisateur.
Un ID unique généré automatiquement est ajouté par défaut à chaque utilisateur externe.
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.
Les utilisateurs externes peuvent également recevoir des appartenances à la structure d’accès pour modéliser un accès hiérarchique et résoudre les claims d’accès lors de la connexion.
Créer un utilisateur externe
Selon la configuration de la méthode d’authentification sélectionnée, les nouveaux utilisateurs sont éventuellement invités à remplir un formulaire pour créer un utilisateur.
La page est composée d’éléments dynamiques qui peuvent être personnalisés par méthode d’authentification. Dans cet exemple, la page de création d’utilisateur est composée de trois éléments : Email, Given name et Family name, avec l’élément Email en haut.
Voici la configuration dans une méthode d’authentification OpenID Connect.
Des transformations de claims peuvent être ajoutées et sont exécutées juste avant la création de l’utilisateur externe.
Si la séquence de connexion est lancée sur la base d’une méthode d’authentification login, elle fournit la base de l’apparence UI (customise). Sinon, la méthode d’authentification login par défaut est sélectionnée comme base.
Provisionner et lier
Les utilisateurs externes peuvent être créés, mis à jour et supprimés via le Control Client ou provisionnés via la Control API.
Vous ne connaissez probablement pas la valeur du claim de liaison à l’avance, car il s’agit d’un ID utilisateur externe. Mais si vous la connaissez, il est possible de créer des utilisateurs et de les associer à la valeur du claim de liaison. Le plus souvent, vous connaîtrez à l’avance un claim de rachat (redemption) à la place.
Les utilisateurs externes peuvent être rachetés par un type de claim de rachat (par exemple email) et ils sont ensuite automatiquement liés avec le type de claim de liaison.
Il est une mauvaise pratique de lier les utilisateurs sur la base de leur email sur une longue période, car les emails peuvent changer. Mais il est peu probable que l’email change dans la courte période de rachat.
Une fois l’utilisateur racheté, l’utilisateur externe se connecte ensuite sur la base de la valeur du claim de liaison.
Cette méthode d’authentification est configurée avec la rédemption du claim email et le type de claim de liaison sub.
Et les utilisateurs sont ajoutés avec leur email connu comme valeur de claim de rachat.
Dans cet exemple, l’utilisateur est connecté à Google Workspace avec une méthode d’authentification OpenID Connect et un claim app_user_id est ajouté avec un ID utilisateur interne.
Vous pouvez réinitialiser un utilisateur racheté en supprimant la valeur du claim de liaison et, si nécessaire, en changeant aussi la valeur du claim de rachat. L’utilisateur externe est alors racheté à nouveau lors de la prochaine connexion.
Migrer des utilisateurs externes entre méthodes d’authentification
Vous pouvez migrer des utilisateurs externes entre méthodes d’authentification et fournisseurs d’identité tout en conservant l’ID utilisateur externe unique généré qui est émis dans le claim local_sub. Cela signifie qu’une application ou un backend n’a pas besoin de changer sa référence utilisateur, tant qu’elle est liée à l’ID utilisateur FoxIDs plutôt qu’à l’ID externe spécifique au fournisseur d’identité.
Lorsqu’un utilisateur est migré et que l’ID utilisateur externe change, supprimez la valeur du claim de liaison pour réinitialiser l’utilisateur externe. L’utilisateur est alors racheté auprès de la méthode d’authentification configurée lors de sa prochaine connexion. Si l’adresse e-mail change, mettez également à jour la valeur du claim de rachat.
Migrer d’un fournisseur d’identité vers un autre lorsque l’ancien fournisseur d’identité est supprimé progressivement. Renommez la méthode d’authentification existante. Les utilisateurs externes associés deviennent alors des utilisateurs flottants, qui ne sont actuellement pas liés à une méthode d’authentification active portant ce nom. Vous pouvez ensuite créer la nouvelle méthode d’authentification avec le nom d’origine, et les utilisateurs externes existants y sont ainsi automatiquement connectés. Si l’ID utilisateur externe change entre l’ancien et le nouveau fournisseur d’identité externe, supprimez la valeur du claim de liaison. L’utilisateur est alors racheté auprès du nouveau fournisseur d’identité lors de sa prochaine connexion. Si l’adresse e-mail change, la valeur du claim de rachat doit également être mise à jour.
Migrer d’un fournisseur d’identité vers un autre lorsque l’ancien fournisseur d’identité reste actif. Mettez à jour les utilisateurs externes afin qu’ils pointent vers la nouvelle méthode d’authentification et supprimez la valeur du claim de liaison. Cela peut être fait via la Control API en changeant la méthode d’authentification connectée avec
UpdateUpPartyName, en supprimant la valeur du claim de liaison avecUpdateLinkClaimValue = ""et, si l’adresse e-mail change, en mettant à jour la valeur du claim de rachat avecUpdateRedemptionClaimValue.Migrer d’un tenant Entra ID vers un autre tenant Entra ID avec une méthode d’authentification Entra ID commune. Ce scénario est pertinent si des tenants partagent une méthode d’authentification Entra ID commune, et non si chaque client dispose d’une méthode d’authentification séparée. Un utilisateur ne peut pas être déplacé d’un tenant Entra ID vers un autre tout en conservant le même ID utilisateur externe. L’utilisateur est plutôt représenté comme une nouvelle identité externe dans le nouveau tenant, même si l’adresse e-mail est la même. Supprimez la valeur du claim de liaison afin que l’utilisateur externe puisse être racheté à nouveau auprès du nouveau tenant Entra ID. Si l’adresse e-mail change, la valeur du claim de rachat doit également être mise à jour.