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.