Okta Migration

[robertjd]

This issue contains information about our Okta migration plan for this library. Please ask questions below! I will update the FAQ as needed. If you want to have a longer conversation, please contact support@stormpath.com and we can setup some time to chat.

FAQ

What do I need to know?

• Please read the master Migration FAQ, which is the high-level overview of feature mappings.
• We are patching this library to work with the Okta API. This will come in the form of a major release, 4.x. We're trying hard to minimize the number of breaking changes. This version will assume that you're migrating your data with our data migration tool, which should be available by the end of April.
• Follow the changelog in the 4.x branch to see the progress with changes. This will be changing daily as we work on the migration tooling, so please try it, but don't depend on it yet :)

How will Custom Data be migrated?

Custom data for accounts will be migrated, but not for other resources. If you have custom data on groups, directories, or applications, that cannot be carried over. Please reach out if you’d like help finding a workaround.

The Okta User Object can have custom properties on its profile object, and we will migrate your custom data properties there. However there is a limitation: the profile properties cannot have object values, so complex objects don’t map cleanly. As such, we’re going to provide two options in the migration tool:

• Serialize your custom data as a JSON string, and store it on profile.customData. Reading and writing the data will require JSON serialization/deserialization. We’ll add code to express-stormpath which does this automatically if we see this known property.

• Flatten your custom data into dot-notation keys, e.g. user.customData.address.street will become user.profile.address_street.

How To Demo The Changes

You can start demoing the 4.x branch now by installing the latest 4.x release candidate in your application:

npm i --save express-stormpath@next

You should then walk through the changelog to make the necessary changes in your application. We also suggest trying the sample project as a sanity check, it has been updated to work with the latest RC:

https://github.com/stormpath/express-stormpath

[lillereven]

What is the status regarding nested customData in Okta?

Stormpath's nested customData is/was an excellent way to directly associate structured data with the user object itself. In my application I am using such a nested object within customData, which would I would like to see migrated to Okta.

[robertjd]

Hi @lillereven , great question! I've added an FAQ item above, please let me know if this helps.

[tanzim]

Hi @robertjd,

I have a couple of questions. Appreciate your feedback on these knowing that you guys must be rather busy right now...

1. What's the best practice for modelling dev/production environments on Okta?
   On Stormpath, we did this by having two applications (since the express-stormpath SDK didn't support multi-tenancy via directories. See #470), one for dev and production. Both apps had one directory each, dev and production and users mapped to them respectively. Because directories provided user uniqueness, we could use this to have separate dev and production users. On Okta, user uniqueness is across the whole of the org. This indicates that it's no longer possible to have separate users (with the same email) on both dev and production applications. Given this, would the preferred approach to having a dev and production environments be in Okta? One way I can think of doing this is to have two applications (obviously) with two groups (more on groups in 3 below) that map dev and production users. Either way, how would you propose we migrate our dev and production users (some who share the same email) to Okta? Also, introducing groups in the mix would means having to add the newly registered user to the correct group which would introduce another point of failure. The other is creating two Okta orgs, in which case we may need additional help migrating dev/production users separately to the different orgs...

2. I see in the release notes that account registration/verification/password reset emails are now controlled via the SDK config (makes sense since directories are dead). Is it the case that emails for registration verification needs to be sent only by us or does it apply for all emails, e.g. password reset too?

3. Group names in Okta are unique, not just the id (as opposed to Stormpath). Previously we created groups with generic names like admins, editors etc. because Stormpath allowed mapping of groups to directories to applications (see one directory per app mechanism we used in 1). It appears that there's no option but to namespace groups for dev/production environments, e.g. admin-dev, admin-production and map them to the dev/production groups?

Thanks.

[robertjd]

Hi @tanzim, thanks for the questions! I’ll answer each:

1.) Creating multiple orgs for different environments will be the simplest. If you need to share/migrate data between a dev environment and a production environment you will have to manage that with your own scripts. Stormpath did provide a convenience in this area, via account store mapping flexibility, but it wasn’t specifically designed to addresses a data migration concern (it was for authorization flexibility).

2.) You will have to send the email verification message, however Okta can handle sending the password reset email. The former isn’t available as a feature in the Okta platform yet, which is why you will have to handle it. Full details are in the breaking changes of the RC1 changelog: https://github.com/stormpath/express-stormpath/blob/4.0.0/docs/changelog.rst#version-400-rc1

3.) Correct, group names are globally unique. Coming back to (1) you’ll have to manage this migration issue with your own scripts. Namespacing groups could be one approach, or you could create a custom schema attribute such as env and set this value to dev or prod on a per-user basis.

I hope these answers help!