Finish migrating from email to sub for auth

[petertgiles]

This branch finishes migrating from email to sub for authentication.

• Updates to schema
• Updates to admin site
• Updates to profile site

Use cases for testing

• A user can be created with no email or sub in the admin interface
• An admin should be able to fill these values
• An admin should be able to edit these values
• An admin should be able to clear these values
• An autocreated user should have the sub but no email
• An autocreated user should be able to log in but have no roles and not be able access protected pages
• An admin should be able to fill in the fields of an autocreated user to promote them to admin
• Login should work with SiC
• Login should work with Laravel Auth
• Regular (non-admin) user can update their email in profiles

Closes #2722

[petertgiles]

Chromatic failures are addressed in #2876

[patcon]

Just a gut-check, but will our seeded admit still be able to have an email as a sub?

(Just in case, would love to merge #2813 before this, as that PR is prone to merge conflicts due to removing all of auth, and it's holding up the cypress PR)

[petertgiles]

would love to merge #2813 before this

No worries. We've got a week left in the sprint and this isn't blocking anything.

[petertgiles]

will our seeded admit still be able to have an email as a sub?

Yeah, there are no restrictions on sub other than it must be unique. We can seed test or 000 or whatever. I left our "dummy admin" with the sub [email protected] since that's what people are used to.

[patcon]

Running through QA test (thanks for the list)!

• A user can be created with no email or sub in the admin interface
• An admin should be able to fill these values
• An admin should be able to edit these values
• An admin should be able to clear these values
• An autocreated user should have the sub but no email
• An autocreated user should be able to log in but have no roles and not be able access protected pages
• An admin should be able to fill in the fields of an autocreated user to promote them to admin
• Login should work with SiC
• Login should work with Laravel Auth
• Regular (non-admin) user can update their email in profiles

[patcon]

I understand that this is technically a valid email, but do we want this to work without dots? (seems a bit more relevant since we don't validate). Maybe beyond scope, so happy to reticket or bury :)

[patcon]

Is making sub editable something we've been asked for, or something we added in anticipation of it helping for future process?

I'm trying to foresee where things could go bad with allowing sub to be changed so easily? E.g., someone's cat walks on the keyboard an removes a letter from a uuid. Without an email, and without database change history, i don't think there's an easy way to re-attach, right? Would require going to a database dump or getting on the phone with GCKey folks, right? Maybe I'm lacking imagination, but seems more risky than necessary to put it right there with other fields that are really safe to change

Also, if we do keep it "Subject" seems like it's a term leaking through the auth protocol abstraction. Maybe something more like "External ID"

[patcon]

Also, maybe this is over-thinking, but it also breaks a piece of any ad-hoc audit trail we might have. If any admin could swap their ID to someone else's, then it breaks one of the more authoritative assurances we have (that a GCKey account using a gov email is logging in and making some change)

[patcon]

minor questions above, but address at your discretion. LGTM as-is!

[petertgiles]

Thanks for the review! Good questions about sub - I've started #2887 to capture your ideas. Feel free to add more over there. Regarding emails - we do have validation in the input field and in the graphql layer. If you feel like you want to tighten it up further you could start an issue for that, too.

[tristan-orourke]

@patcon those are some valid questions about sub, @petertgiles thanks for making a new issue. I think this one's good for now!