Me/dpc 5372 portal db changes

[MEspositoE14s]

🎫 Ticket

https://jira.cms.gov/browse/DPC-5372

🛠 Changes

• Adds three new tables, csps, csp_users and user_emails and populates them on invitation and login.
• Removes IdpUid table.
• Removes Devise in favor of directly calling OmniAuth.
• Configured auth around for Login.gov.

ℹ️ Context

We're preparing to support multiple CSPs, and this is the first step. This was created and modified from #2896.

Note:

• Before deploying to test, the user.provider field in the DB needs to be updated to "login_dot_gov" for all users. This can be done afterwards, but it's easier if you do it before.
• This has already been done in dev, but make sure your callbacks are registered with Login.gov or the login process will fail.

🧪 Validation

• Deployed to dev and was able to login. (Deploy: here)
• Ran locally and could create a new user and login as an existing one. (If you want to test with an existing user on your machine, make sure to update user.provider in the DB as described above.)
• Verified that new tables are populated both locally and in dev:
  • csps: Populated on migration.
  • csp_users: Populated on migration with values from the user table and whenever a new user is created.
  • user_emails: Populated and updated whenever a user logs in.

[ashley-weaver]

do we have these strings yet?

[MEspositoE14s]

Not that I know of. I'm not sure if there's a content/design ticket out there somewhere for it, or if this was just a quickie place holder to get us through the PoC.

[ashley-weaver]

should the provider come from a parameter or user attribute instead of hardcoded?

[MEspositoE14s]

In this case, because it's in the login_dot_gov controller it should never change. Once we start adding other CSPs they should each get their own controller each tied to their own CSP entry.

We'll need to get a little clever in the invitations controller, though. Right now that's hardcoded do login_dot_gov, too, and that will have to change once we start implementing the other CSPs.

[Jose-verdance]

Hey @MEspositoE14s should we have a migration script ready and a rollback one for updating user.provider field in the DB to "login_dot_gov"?

[MEspositoE14s]

Hey @MEspositoE14s should we have a migration script ready and a rollback one for updating user.provider field in the DB to "login_dot_gov"?

We can add it to the existing migration, but Jeff pointed out in the PoC that it's easier just to do it manually, especially if there's a problem and we just want to drop the new tables and start over. It's only a one line command: UPDATE users SET provider = 'login_dot_gov';, or "openid_connect" to undo.

[Jose-verdance]

Hey @MEspositoE14s should we have a migration script ready and a rollback one for updating user.provider field in the DB to "login_dot_gov"?

We can add it to the existing migration, but Jeff pointed out in the PoC that it's easier just to do it manually, especially if there's a problem and we just want to drop the new tables and start over. It's only a one line command: UPDATE users SET provider = 'login_dot_gov';, or "openid_connect" to undo.

Even if its a one line change, we should aim to have changes to be DB be go through the migration. This way we have a clear migration audit trail and can reduce the manual steps required.

[ashley-weaver]

+1 on the migration script, I think we should preserve the history

[MEspositoE14s]

Even if its a one line change, we should aim to have changes to be DB be go through the migration. This way we have a clear migration audit trail and can reduce the manual steps required.

+1 on the migration script, I think we should preserve the history

The people have spoken! This update should make rolling back work a little easier, too.

[ashley-weaver]

🙌

[Jose-verdance]

Hey @MEspositoE14s thanks again for syncing with me. This looks good. This seems outside the PR scope, but we may want to document how to update the LOGIN_GOV_PRIVATE_KEY for future use cases and scenarios. Looks good otherwise!