handling users and authentication

[pstaabp]

I've been thinking a bit about how to handle users in webwork3. As discussed, we'll have a global users table with a many-to-many relationship to courses.

My latest thought is that the global users table will have 3 columns:

• user_id (PK, integer, auto-increment)
• login or email (string, unique and indexed). Either way, we need some restrictions on it (like no spaces).
• params (JSON string containing some information on how to authenticate), this could include
  • password (to use a local version of authentication).
  • LDAP information to authenticate.
  • other access to authenticate. @tani had suggested https://edugain.org/ or https://www.geant.org/Services/Trust_identity_and_security/Pages/eduGAIN.aspx

There is also the question of additional information associated with a student, like student id or other personal information. We have discussed putting that in a different table (perhaps separated by institution) or perhaps a mechanism for instructors to upload a file to their course.

I know some of you have much better sense of legal requirements for the separation of personal data and I think a flexible but secure way to handle this may be the best.

[taniwallach]

@mgage posted in Slack:

Are there any use cases where a student would want a different name in different classes? How about different emails for different classes? If the site is used by more than one University perhaps the studentID would be different for different courses taken from different universities. If the site is used by more than one university securing a unique username for the student might be problematic. It would be worth referencing moodle, d2l, canvas to see how they handle these conflicts.

Here are my thought about supporting courses from multiple institutions on a single server when there is global user data and not just course level user data.

We would like to find a balance between the desired outcome of a user having access to all their courses via a single login process and the desire to allow multiple institutions to operate courses on a single server.

One of the factors in this is that a multi-institution site will certainly need to worry about conflicts in usernames from different institutions. That problem is more critical if the username is provided by a remote system (LTI, LDAP, etc.).

In one of the recent developer meetings we discussed possibly adding "institution" to the global level user data, so that each user account would really belong to a specific institution. Then the the pair (institution,username) would be what we needed to keep as unique rather than just the username.

Over long periods of time, institutions may reuse a given username for a new student. If global user data accumulated on a WW3 server for a long enough time - we may need some mechanism to "retire" an old account of a given (institution,username) so that a new one could be created to reuse the username.

Users with courses from multiple institutions would need multiple accounts and the login process would also depend on providing the institution. The institution on the login page could be auto-filled when possible based on parameters provided by in the URL.

@dlglin pointed out that in some cases, a single university might actually be multiple institutions for this, such as if multiple LMS systems are used by different departments/units with different user account systems. He also pointed out that different institutions could have different policies about what sort of changes to user data are allowed. Potentially that could also be modified at the course level.

The "site administrators":

• Would need to be able to create new institutions, and have the ability to create/add/delete "institution administrator" accounts.
• For course creation, it would be necessary to to assign each new course to an existing institution.
• Ideally, the "site admin" would be able to select from a predetermined set/list of authorized accounts belonging to the relevant institution to set the "initial accounts" to be created in the new course (and assign each one a role). The intention is not to allow the site admin to access the data about all the existing users from the institution here, but only ones authorized to be seen and used as initial course instructors.
• This creates the somewhat inconvenient need for a new instructor account to first be created at the institution level before a course for that instructor can be created with that instructor as the "initial" account.
• Unlike in webwork2, it might be nice for the site admin UI to allow adding an additional instructor account to an existing course, rather than requiring that be done via a shell script.

Institution administrative accounts would also be restricted to viewing/modifying data on users from their institution, but should be able to add instructor and student accounts to courses in their institution. Maybe a "disable access" (rather than a "delete account") feature would also be helpful.

"Course level" access to data:

• Course instructor accounts should probably only be able to access data about "global" users from the correct institution, and certainly not data about accounts from different institutions. The level of access for users not in the given course should probably be managed at the institution level, including whether a course instructor can modify global user for such a user.
• Exception to allow cross-institution read-only access for special suitable cases can be considered for legitimate needs.
  1. If a user from a different institution had an account in a given course then read-only access to that specific user's "personal information" should be available.
  2. A mechanism to request access to a course in a different institution / to approve access to the personal data might be needed.
• It could be that it might be better to force the creation of an account in the correct institution rather than allowing cross-institution data access.

The "site managers" might need to belong to a "super" institution with access to global user data from multiple institutions, but it might be better to just force them to log in as an institution administrator account to view/modify data related to a given institution's users. (Maybe an "act as institution administrator" conditional on being listed as one of that institutions authorized administrators would work.)

The use case where users from multiple institutions might want access to a single course could be problematic. Supporting that would require suitable care to distinguish users with potentially the same username but from different institutions, or special mechanisms of some sort. If each course had a "primary institution" making cross-institution accounts show as username#institution or something might help to emphasize which accounts might be "confusing".

[taniwallach]

@mgage posted in Slack:

Are there any use cases where a student would want a different name in different classes?

I don't think we want to allow users to change their own names/usernames. Maybe we could allow a "nickname" which a user could set and which could be displayed in some places instead of or in addition to the official username/name. This is not something I would give any priority to at present.

@mgage posted in Slack:

How about different emails for different classes?
As @dlglin pointed out - some institutions may not want to allow a user to change to using a non-institution email.
Instead we could consider allowing a "secondary email" field either at the global level or the course level. When set, that could be used as a cc address or in other manners. Use of this field and who can edit it could be handled by site/institution/course permission settings.