OAuth2 DOP to DOT migration in Juniper

Site Operators
1

This might be of interest to operators and other Open edX instances that will migrate from Ironwood to Juniper.

As stated in https://openedx.atlassian.net/wiki/spaces/COMM/pages/940048716/Juniper:

Any OAuth Applications/Clients registered in the LMS that are using the old Django-OAuth-Provider will need to be migrated to Django-OAuth-Toolkit. These applications include your Open edX Mobile Apps (iOS, Android) as well as your Open edX services (e-commerce, Insights, Credentials, etc.) TBD . Need to include step-by-step information for this migration.

Does edX have instructions on how to do it? Thus far I can do it manually by looking at the database or tables in Django Admin for Ironwood and recreate the entries in the appropriate tables in Django Admin, but I’m afraid some people will not be able to do so.

Luckily for us the migrations did not remove the table oauth2_client where the previous information is stored. On the other hand, this table is no longer displayed in Django Admin in Juniper.

We need to find a way to automated the DOP to DOT upgrade because some Open edX instances or operators will not have the technical expertise to do it manually. It might also cause some downtime for instances relying on these services like ecommerce, discovery or insights to give a few examples.

Since edX must have gone through this process internally for edx.org, is there any documentation available that can be shared with the community?

Thanks for any information or instructions you can provide.

2

@sambapete: Let me know if the provided doc gets you further. I added it to the Juniper page. Thanks.

3

Thanks @robrap I will look at it and let you know.

Looking at it quickly, it looks like what I had to do manually following the instructions in https://github.com/edx/devstack/pull/394 and adapting for production and the applications I was already using.

4

One of the problems I’ve encountered while trying to do this manually was with some applications like ecommerce where I also had to “manually update” the values of some fields in the ecommerce site_configuration table. Since there were no migrations, it still had entries for OIDC and DOP.

Some applications like edx-notes-api for example did not necessarily have a worker user in the past. Can the same worker user be used for multiple applications?

5

You’ll need to confirm this, but I don’t think notes uses DOT. I’d interpret this as notes continuing to do whatever it did, and I’m not sure exactly what that is.

I don’t think DOT admin will complain about worker reuse, but I don’t know what the implications would be (e.g logs, etc.). We generally don’t seem to be reusing workers across services.

And yes - we did a lot of manual removal of configs and settings with OIDC. I’m not sure which other IDAs, if any, might have the site_configuration clean-up required as well. I think a lot of this clean-up may have been done manually via admin.

Here are some settings that were removed that I dug up:

OAUTH_OIDC_ISSUER
ENABLE_DOP_ADAPTER
SOCIAL_AUTH_EDX_OIDC_ID_TOKEN_DECRYPTION_KEY
SOCIAL_AUTH_EDX_OIDC_ISSUER
SOCIAL_AUTH_EDX_OIDC_KEY
SOCIAL_AUTH_EDX_OIDC_LOGOUT_URL
SOCIAL_AUTH_EDX_OIDC_PUBLIC_URL_ROOT
SOCIAL_AUTH_EDX_OIDC_SECRET
SOCIAL_AUTH_EDX_OIDC_URL_ROOT
oauth_dop

Hope this helps. Feel free to update the Juniper page with anything here you think would be useful to others.

6

Also, I got confirmation that we did all DOT application creation manually, including non-service DOP applications. So there are no data migration scripts to share.

1 Like
7

Thanks again for the instructions. This will definitely help a few people out there when migrating to Juniper.