Decouple users

[artur-intech]

• Extract superusers, api users and registrant area users from users table.
• Define admin user's attributes
• Consider using email as a login

Check #708, #919 as well.

[artur-intech]

For 2. it might be:

• email (unique)
• password

I would drop the rest we currently have as excessive.

Not sure if the following are needed (from audit perspective):

• current_sign_in_at
• last_sign_in_at
• current_sign_in_ip
• last_sign_in_ip

[artur-intech]

@vohmar Does № 3 make any sense?

[teadur]

I would say it doesnot, all users dont have email like api users.

[vohmar]

there are only six parameters to admin users - username, password, email. identity code, country, role. I would not call identity code together with country excessive as it enables using electronic id for user authentication. This should be preferred way of identification. So not excessive. Then again most countries and people in the world do not have e-id so alternate option is required. The email address is mandatory for admin users so one could consider using this instead of separate username. API users on the other hand may not have emails. One could use the same user info for both admin and api user to make life easier and more manageable - nice insecure feature. Also I would not call role excessive as we plan to introduce different user levels for admin access (GDPR). To be clear admin users in this context mean users with access to the admin interface not same as administrator nor superuser. I do not see the advantages on dropping username for admin users - I do see making username as an optional parameter enabling users to decide whether to use email or username for accessing the ui as a viable improvement of user experience.

[artur-intech]

Current problems:

• username column in fact acts as a display name for RegistrantUser, and as a login name for ApiUser and AdminUser. This in turn prevents putting unique constraint, since it is unique for API and admin users, but is not for registrant users.
• identity_code and registrant_ident represent the same data, whereas the latter also has country code incorporated in case of RegistrantUser.

---

Proposed DB structure (not yet final):

Superuser

• email
• encrypted_password

RegistrarUser

• login_name (required for EPP)
• encrypted_password (required for EPP)

RegistrantUser

• login_name (for cases when a user does not have an ID-card, primarily for foreigners)
• encrypted_password
• display_name
• identity_code (required for searching for managed contacts)
• country (required for searching for managed contacts)

[teadur]

AdminUsers should have the option for identity_code for strong auth in admin portal.
But it should not be requirement for all AdminUsers.

Registrars have two kinds of users, they have systems using our system and they have real people using our system. We should require different data from them depending on their role.

For example EPP users don't have identity_code.
EPP is only consumer of plain_text_password.
All other Registrar roles should require identity_code because they are real persons.
But it should support other identity_codes besides Estonian.

Atleast for now we don't allow Registrants to login with user/password only strong auth.
We could extract country code from registrant_ident.