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.

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.
 

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.
 

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 eng_blogs@okta.com.

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.