Improving the end-user registration experience with Okta Identity Engine

Self-service registration is an essential and commonly used feature for Okta customers. Okta Classic had this feature as part of the directory section in the admin settings page, and it’s available in Okta organizations (orgs) with a feature flag (SELF_SERVICE_REGISTRATION). An admin can create attributes as part of the profile in Universal Directory and add those attributes to the Self-Service Registration Policy. In the classic flow, when an end user signs up for a new account, they are presented with a registration form with the fields set via the policy.

 

X4it3rAAdWDq9RGjIMhjTTLYRabLhHu6qQ3eqHT9qBKljdI7HHfZmkeFm 3jPZZnloIMdMc60tiuGTcl6OE oQg83 36WjvIP126K9rWT7BsgQB FIRgCDL7LBAJiEn h79YdlwptaqHkWXaNWpqe 8

 

9aiRCXh66mdAC1wEU6DM1Bvn1uLjHpXHQct71aK5D LdjIqSH7iujDIWBIOsMViCFzDJ8 IxtC2TW05aSer9LMfscY8FlKZgQkmnesuWCc5Tx4b2PifgimATKzm3GUWxd2K6GsdEeHjYlUFC74B 8uI
 

Okta Identity Engine’s (OIE) release brought many improvements in modernization and flexibility. Some of the improvements involve the endpoints and policies associated with user registration. On OIE, the registration policy is part of the new Profile Enrollment Policy. These policies live under Security -> Profile Enrollment on the admin console. Progressive profiling is a feature built within the profile enrollment policy, which provides the ability to request input from existing users for different attributes at different stages of the user’s navigation experience within the org or application, thus reducing user sign-up friction with longer enrollment forms.
 

qCMOkNRrzzcHYdscd1FC 2Wmgzf8nH9VmELG3ct u8ysae0GIepU2Od7vCm2IzRfO7ZQwPUN7Ah9OyKhB vMmcfMOMWQxGFGi5H1ZiaxQH5e6K02OAFBNR6eI2V53T0vi JBYwo9UAFzHOCLq6 wp8ky8w4 2JiGSndD1meGGccxH1Jn4BtuBAf4gpA3fASA5dCBUiqPQq1MmAEZP3Ibca2ya12IhhT91Udxr0rB WQFFrdXOkPiUBtMuGSPtZz7WpMEVsPWbN2SopMZ2ZU1AtzVGJWmsD0BysPPTEaZxGx y0

OIE’s Profile Enrollment with Progressive Profiling was incompatible with the classic engine’s self-service registration policy. If there were attributes of type read-only/hidden and required, users would be unable to populate them,  which posed a challenge for customers who were using the classic engine with self-service registration enabled and wished to upgrade to OIE. Since OIE has tighter requirements around policies, it does not allow end users to update read-only or hidden attributes. The classic engine also has a separate feature flag that, when enabled, allows users the flexibility to populate read-only/required attributes during registration.
 

XKvRSscCVKWySp0wVkWf5eiJ 5c00gbUSettOuIKQtOp A5P6ScfWBRk3jF ji7 rFHu4LxmBvYpVjuWX 6ClbbNmVm HghOjMBiG4C7IrP zzBlXBSiKMdOfZOf2Dxt5yrhe2sw09rFwre8oiMG8 4

 

So how did we, the Access Management Team, solve this problem for customers? The solution happened in two phases:

  1. We split up the ability to toggle Self-Service registration separately from Progressive Profiling. This way, if any migrated orgs had unsupported attributes from the classic engine, Progressive Profiling could remain disabled until an admin could fix the problematic attributes in Universal Directory (under Directory -> Profile Editor).
  2. During migration to OIE, we built a validator to check for any unsupported attributes or feature flags in the org and show the admin a “consent to warnings” message, stating that those attributes will be ignored upon upgrade. After the admin consents to the warnings, the admin can upgrade to OIE with a migrated self-service registration experience. 

To conclude — new SSR migration enhancements help unblock many classic Okta orgs so they can seamlessly migrate to OIE and enjoy Okta at its best.

Have questions about this blog post? Reach out to us at [email protected].

Explore more insightful Engineering Blogs from Okta to expand your knowledge.

Ready to join our passionate team of exceptional engineers? Visit our career page.

Unlock the potential of modern and sophisticated identity management for your organization. Contact Sales for more information.