Update how we save and log org claims on whoami calls

[emyl3]

BACKEND PULL REQUEST

Related Issue

• Fix bug introduced in Log error if Okta and DB role claims unequal #8182
  • Before this fix, users that were not migrated over before the logging was introduced would log the user as having mismatched Okta and DB org roles

Changes Proposed

• Move the check to the level of the getCurrentUserInfoForWhoAmI method
• Remove check happening at the LoggedInAuthorizationService level

Additional Information

Testing

• deployed on dev3

  • find a user that you can log in as that is not a site admin
  • use this mutation to clear that user's roles and facilities

  mutation ($username: String!) {
    clearUserRolesAndFacilities (
        username: $username
    ) {
        id
        nameInfo {
            firstName
            lastName
        }
        email
    }
  }
  

  • log in as that user (check what time you logged in at)
  • check that their roles and facilities have populated
  • do a transaction search in Azure app insights for dev3 with the string (below) and make sure your user's ID does not appear as a log message during that timeframe

Okta OrganizationRoleClaims do not match database OrganizationRoleClaims for User ID:

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[emyl3]

⚠️ Making use of the consolidateUser method that also handles the comparison check, logging (regardless of the status of the feature flag) and setting the user's role and facilities (if the feature flag is off)

[emyl3]

⚠️ Before I was doing the comparison check way lower in the stack for whoami calls.

Moved the check to the level of the getCurrentUserInfoForWhoAmI method to avoid instances where users who were not migrated were being checked (thus, logging an error).

[mpbrown]

Tested on dev3 with clearing roles for Oktavius Migratius, successfully populated the cleared roles, and found no log describing a mismatch in app insights. LGTM!

[bobbywells52]

LGTM -- thanks for you work on this!