Initiate rolling migration, phase 2

[mehansen]

Background

We would like to migrate user roles, org membership, and facility membership to be stored within the SimpleReport app, as opposed to managing it in Okta. This will increase stability of the app and improve code readability and extensibility, among other benefits. The goal of this ticket is to continue moving authorization data we access in Okta to our tables and also compare the data we've collected with our source of truth (Okta) to check for discrepancies.

Change requested

Change the code that accesses user role and facility/org membership from Okta to instead get this data from our tables if the feature flag is on.

If the feature flag is off, we continue to retrieve from Okta but we also update our data. Create entries in the ApiUserFacility and ApiUserRole tables or update existing entries.
When retrieving the data from Okta, compare to what we have in our tables and alert if they are not in sync.

Acceptance criteria

• When the feature flag is off:
  • the behavior of the app re: authorization and showing role/facility info should reflect what's stored in Okta
  • any time the app performs an action that retrieves role or facility or org membership from Okta, the tables should also reflect this information
• When the feature flag is on:
  • the behavior of the app re: authorization and showing role/facility info should reflect what's stored in our tables
  • any time the app performs an action that retrieves role or facility or org membership, we do not update our tables
• (???) When the feature flag is off OR always until cleaned up
  • any time the app performs an action that retrieves role or facility or org membership, we compare what we get from Okta to what's stored in our tables. if the data doesn't match (inc is absent?), trigger an alert

Dependencies

• Create feature flag for finalizing Okta migration #7596
• Initiate rolling migration, phase 1 #7597

Open questions

Do we want an alert if the data was absent or just if it was already in our table and doesn't match?
Question from earlier discussion: Do we want to do the comparison and alert when the flag is on?
Question from earlier discussion: For testing, any prod-specific corner cases we want to talk about that require special testing outside of testing in lowers?

Notes

Test auth in lowers with non-superadmin (since superadmin still managed within Okta)

Additional context

Main design doc
Design doc - backend
Design doc - data migration plan
Okta migration tickets plan
Okta tech talk
Okta tech talk part 2

[emyl3]

Remaining work:

• update userIsInSameOrg to use DB when feature flag is enabled (Update userIsInSameOrg to use DB when feature flag enabled #8078)
• update where we call GroupApi to use DB when feature flag is enabled (Fetch group info for users from DB when oktaMigrationEnabled is true #8105)
• log when roles are different from Okta and DB (Log error if Okta and DB role claims unequal #8182)

[emyl3]

Update from eng sync: continue to update roles + groups in Okta even when the feature flag is enabled