Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fetch OrganizationRoleClaims from DB when feature flag enabled #8030

Merged
merged 4 commits into from
Aug 27, 2024

Conversation

emyl3
Copy link
Collaborator

@emyl3 emyl3 commented Aug 13, 2024

BACKEND PULL REQUEST

Related Issue

Changes Proposed

  • When the feature flag is enabled, fetch role and facility information for users from DB
  • Creation of DbOrgRoleClaimsService
    • handles transforming a ApiUsers role and facility information to OrganizationRoleClaims and returning those claims
    • method introduced to check for equality between the OrganizationRoleClaims from Okta and the DB and log if there is an error
    • Refactoring of consolidateUser method in ApiUserService

Additional Information

  • Remaining work (will be introduced in separate PRs)
    1. behind the feature flag, leverage our DB instead of okta's group api endpoint to fetch group information for orgs
    2. utilize the method for checking equality of roles from Okta and DB and create an alert when this they are different

Testing

Envs

  • oktaMigrationEnabled FALSE on dev2

    • dev2 metabase link to see roles and facilities at a glance
    • roles and facilities should be added whenever we read role/facility info from Okta
  • oktaMigrationEnabled TRUE on dev3

    • dev3 metabase link to see roles and facilities at a glance
    • roles and facilities should be not be updated when we read role/facility info from Okta
    • when we update role and facilities, we should still be updating Okta and DB
    • list of users in the org will be incorrect and still fetched from Okta until bullet point number 1 from "Remaining work" is completed

Some scenarios to try in both environments:

  • Site Admin role
    • ghost into different orgs (no role/facility saved in DB)
    • can manage users
      • send account setup email
      • edit name
      • edit email
      • reset password
      • reset MFA
      • delete user
      • update organization/facility/role access
    • add organization admin
  • Org Admin role
    • can manage users
      • send account setup email
      • edit name
      • edit email
      • reset password
      • reset MFA
      • delete user
      • update facility/role access
    • add user

⚠️ On dev3, when fetching a user that is not in the DB (e.g. [email protected]), it will show the following due to a MisconfiguredUserException being thrown:
Screenshot 2024-08-16 at 07 27 09
I think this makes sense if we are only enabling this flag after all users have been migrated over. Once the other work goes in, this user wouldn't be appear in the "Manage users" page so this error wouldn't be visible to end-users.

@emyl3 emyl3 force-pushed the elisa/7598-read-roles-from-db branch 8 times, most recently from 3938acf to 7bea9fb Compare August 15, 2024 16:59
OrganizationRoleClaims claims = optClaims.orElseThrow(UnidentifiedUserException::new);

// use the target user's org so response is built correctly even if site admin is the requester
Organization org = _orgService.getOrganization(claims.getOrganizationExternalId());
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Let me know if I am missing something but I found the logic from what was previously lines 732-743 unnecessary because we can get OrganizationRoles from the OrganizationRoleClaims using this OrganizationService method.

* @param dbClaims - List<OrganizationRoleClaims> from DB
* @return boolean
*/
public boolean checkOrgRoleClaimsEquality(
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Currently only using this in the tests but will use it later to introduce logging and alerting based on differing org roles from Okta vs DB

Copy link
Collaborator

@fzhao99 fzhao99 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great to see this started elisa! left some initial questions for you

Copy link
Collaborator

@mpbrown mpbrown left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested in dev2 and dev3 and things look good overall! Great job with all this migration work!

Copy link

sonarcloud bot commented Aug 21, 2024

@emyl3
Copy link
Collaborator Author

emyl3 commented Aug 21, 2024

@mpbrown @fzhao99 ready for re-review! (redeployed changes to dev2 and dev3)

Copy link
Collaborator

@fzhao99 fzhao99 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks so much for your hard work on this elisa!

Copy link
Collaborator

@mehansen mehansen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you for all your hard work on this! it's so cool to see this coming together 🤩

do you think we need to use the db roles for this permission check too?
https://github.com/CDCgov/prime-simplereport/blob/refs/heads/elisa/7598-read-roles-from-db/backend/src/main/java/gov/cdc/usds/simplereport/config/authorization/UserAuthorizationVerifier.java#L100

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is just a thought, not feedback - I haven't looked at all the usages of OrganizationRoleClaims but do you think we'll be able to clean that up as a concept entirely once the migration is complete? it seems like we mostly use it to hold the values of org, facilities, roles that we've pulled from the Okta groups before we can convert them into their objects.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think you are right! Once fully migrated, we will be able to clean it up!! 😮‍💨 🧹 🤩

@mehansen
Copy link
Collaborator

forgive me if these are included in the remaining work you called out, but I noticed a couple unexpected places where we're using Okta groups as source of truth:

@emyl3
Copy link
Collaborator Author

emyl3 commented Aug 23, 2024

forgive me if these are included in the remaining work you called out, but I noticed a couple unexpected places where we're using Okta groups as source of truth:

I didn't explicitly call these out but I was going to search the entire repo for where we were calling the GroupApi and bundle all that work together. This is a very helpful starting point to make sure I have all the different usages covered 🙌 Thank you, Merethe! 🗒️

@emyl3
Copy link
Collaborator Author

emyl3 commented Aug 23, 2024

thank you for all your hard work on this! it's so cool to see this coming together 🤩

do you think we need to use the db roles for this permission check too? https://github.com/CDCgov/prime-simplereport/blob/refs/heads/elisa/7598-read-roles-from-db/backend/src/main/java/gov/cdc/usds/simplereport/config/authorization/UserAuthorizationVerifier.java#L100

ohhhh nice catch! I will update this 😅 Thank you!!! 🙌 🐛 🔍

@mehansen
Copy link
Collaborator

I didn't explicitly call these out but I was going to search the entire repo for where we were calling the GroupApi and bundle all that work together. This is a very helpful starting point to make sure I have all the different usages covered 🙌 Thank you, Merethe! 🗒️

oh nice that should definitely do it. everything looks good! the permission check update could totally go in a follow-up PR too if you want to just merge this

@emyl3
Copy link
Collaborator Author

emyl3 commented Aug 27, 2024

I didn't explicitly call these out but I was going to search the entire repo for where we were calling the GroupApi and bundle all that work together. This is a very helpful starting point to make sure I have all the different usages covered 🙌 Thank you, Merethe! 🗒️

oh nice that should definitely do it. everything looks good! the permission check update could totally go in a follow-up PR too if you want to just merge this

I'll fix the permission check in a separate PR 🙏 Thank you for your flexibility.

@emyl3
Copy link
Collaborator Author

emyl3 commented Aug 27, 2024

Going to merge this in after demo 💪

@emyl3 emyl3 added this pull request to the merge queue Aug 27, 2024
Merged via the queue into main with commit 453dc84 Aug 27, 2024
38 checks passed
@emyl3 emyl3 deleted the elisa/7598-read-roles-from-db branch August 27, 2024 21:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants