L'auto-inscription est une fonctionnalité essentielle et couramment utilisée par les clients d'Okta. Okta Classic avait cette fonctionnalité dans la section du répertoire de la page des paramètres d'administration, et elle est disponible dans les organisations Okta (orgs) avec un indicateur de fonctionnalité (SELF_SERVICE_REGISTRATION). Un administrateur peut créer des attributs dans le cadre du profil dans Universal Directory et ajouter ces attributs à la Self-Service Registration Policy. Dans le flux classique, lorsqu'un utilisateur final s'inscrit pour un nouveau compte, il se voit présenter un formulaire d'inscription avec les champs définis via la politique.
La sortie d'Okta Identity Engine(OIE) a apporté de nombreuses améliorations en termes de modernisation et de flexibilité. Certaines de ces améliorations concernent les points de terminaison et les politiques associées à l'enregistrement des utilisateurs. Sur OIE, la politique d'enregistrement fait partie de la nouvelle Politique d'enrôlement de profil. Ces politiques se trouvent sous Sécurité -> Enrôlement de profil sur la console d'administration. Le profilage progressif est une fonctionnalité intégrée à la politique d'enrôlement de profil, qui permet de demander aux utilisateurs existants des informations sur différents attributs à différentes étapes de l'expérience de navigation de l'utilisateur au sein de l'organisation ou de l'application, réduisant ainsi les frictions liées à l'inscription des utilisateurs avec des formulaires d'inscription plus longs.
L'inscription de profil OIE avec profilage progressif était incompatible avec la politique d'enregistrement en libre-service du moteur classique. S'il y avait des attributs de type lecture seule/caché et requis, les utilisateurs ne pourraient pas les remplir, ce qui posait un défi aux clients qui utilisaient le moteur classique avec l'enregistrement en libre-service activé et souhaitaient passer à OIE. Étant donné qu'OIE a des exigences plus strictes concernant les politiques, il ne permet pas aux utilisateurs finaux de mettre à jour les attributs en lecture seule ou cachés. Le moteur classique dispose également d'un indicateur de fonctionnalité distinct qui, lorsqu'il est activé, permet aux utilisateurs de remplir les attributs en lecture seule/obligatoires lors de l'enregistrement.
Alors, comment nous, l'équipe de gestion des accès, avons-nous résolu ce problème pour les clients bsp? La solution s'est déroulée en deux phases bsp:
- Nous avons séparé la possibilité d'activer l'enregistrement en libre-service du profilage progressif. Ainsi, si des organisations migrées avaient des attributs non pris en charge par le moteur classique, le profilage progressif pouvait rester désactivé jusqu'à ce qu'un administrateur puisse corriger les attributs problématiques dans Universal Directory (sous Directory -> Profile Editor).
- Lors de la migration vers OIE, nous avons créé un validateur pour rechercher les attributs ou les indicateurs de fonctionnalité non pris en charge dans l'organisation et afficher à l'administrateur un message de « consentement aux avertissements », indiquant que ces attributs seront ignorés lors de la mise à niveau. Une fois que l'administrateur a accepté les avertissements, il peut effectuer une mise à niveau vers OIE avec une expérience d'enregistrement en libre-service migrée.
En conclusion, les nouvelles améliorations de la migration SSR aident à débloquer de nombreuses organisations Okta classiques afin qu'elles puissent migrer de manière transparente vers OIE et profiter d'Okta à son meilleur.
Vous avez des questions sur cet article de blog ? Contactez-nous à l'adresse suivante :eng_blogs@okta.com.
Consultez d’autres Blogs sur l’ingénierie d’Okta pour approfondir vos connaissances.
Prêt à rejoindre notre équipe d’ingénieurs aussi passionnés qu’exceptionnels ? Consultez notre page Carrières.
Libérez le potentiel d’une gestion des identités moderne et sophistiquée pour votre entreprise. Contactez notre équipe commerciale pour plus d’informations.
