Originally posted at SPHERE design google drive by @mirkovic, reposted here by @jdbarnes for discussion/comment
Overall philosophy
We may regard SPHERE users as falling into two categories:
- Full: Those that use SPHERE for research and are leveraging full functionalities
- Restricted: Those that use SPHERE as part of another activity (class, demo, evaluation of artifacts) as a tool, and need limited functionalities
Differences between full and restricted accounts
Full accounts are expected to use the full suite of our user interfaces, GUI, SSH and Jupyter and should be able to have full control over their account. They should be able to reset passwords, update accounts, and close an account if they do not want to use us anymore. They should be able to select their username if it is not currently taken. They are expected to have one account per email address.
Restricted accounts are expected to use some other UI (class, EAC, demo) and interact with SPHERE in limited ways. They are created programmatically by org owner, they live for a limited time and are then recycled to be used by new users. They get a programmatically generated username and password and the org owner has access to everyone’s passwords. Users cannot change their password, but the org owner can give them a new programmatically generated one if needed. It is useful for users to get their username and password via email. Users may have multiple accounts with a single email address, if they belong to multiple orgs at the same time.
| Activity | Full account | Restricted account |
|---|---|---|
| Creation | Via Web UI or mrg CLI | Bulk by org owner |
| Username | Chosen | Programmatic |
| Password | Chosen | Programmatic |
| Multiple accounts per email | No | Possible |
| Password reset | Via email | By org owner via special UI |
| Reject resets via our form | ||
| Password change notification | No | By email |
| Login to SPHERE | Normal via our UIs | May be through special UI |
| Lifetime | As needed | Until org owner recycles |
| Account open checks | Reject on existing email | Create email alias on existing email |
SUPPORT NEEDED: Highlighted requirements necessitate us to support email aliases. On a restricted account open we’d check if an email is already in use. If so, we’d create an alias and store it in a table that remembers username, original email and alias email. Alias is passed to Kratos. Password change on a restricted account gets emailed to user (we can do this from class or AEC UI, no need for special support on Merge). We set up alias accounts to forward to the original email address.
Thought experiment: what if all accounts had full access?
| Activity | Now | Thought experiment |
|---|---|---|
| Creation | Bulk by org owner | By user via Web UI |
| Username | Programmatic (usc430aa, usc430ab, usc430ac) | Chosen (sunshine, jross, mattw) |
| Password | Programmatic | Chosen |
| Password reset | By org owner via special UI | Via email and our reset form |
| Login to SPHERE | Normal via our UIs | May be through special UI |
| Lifetime | As needed | Until org owner recycles, but special checks needed to see if user belongs to another org or project before recycling |
| Account open checks | Reject on existing email | Reject on existing email |
| Pre-create accounts | Yes | No |
| Chance of idle accounts | Low | Very high |
| Chance of support requests | Low | Very high |
| Statistics | Account creation logs | Org join logs |
| Use mode statistics (research/edu) | Easy | Very hard |
This is possible but messy. Lots of actions that were automated are now user-driven, which opens space for user mistakes and support tickets that require prompt handling due to class, AEC, demo deadlines. Lots of user requests for support will come to us (reset email cannot be found, etc.) Org owner now cannot log in as a given user to debug issues, because they have no access to user password (and neither can we). We would also need special support by ops to create accurate statistics on class vs research users and use times.