figureone
commented
3 years ago I think this makes sense and can be merged into work on a UI for mapping CAS attributes to roles: https://github.com/uhm-coe/authorizer/issues/75
This is currently possible by using filter hooks (authorizer_custom_role) and update_user_meta(); there are some examples available here:
https://wordpress.org/support/topic/retrieve-extra-information-from-the-cas-server/
In our experience it's very difficult to treat usernames as private, since they are technically directory information. Like you mentioned, WordPress makes this more difficult since they do not consider user details private: https://wordpress.org/support/topic/stop-allowing-user-enumeration/
From FERPA:
Another exception permits a school to non-consensually disclose personally identifiable information from a student's education records when such information has been appropriately designated as directory information. "Directory information" is defined as information contained in the education records of a student that would not generally be considered harmful or an invasion of privacy if disclosed. Directory information could include information such as the student's name, address, e-mail address, telephone listing, photograph, date and place of birth, major field of study, participation in officially recognized activities and sports, weight and height of members of athletic teams, dates of attendance, degrees and awards received, the most recent previous educational agency or institution attended, grade level or year (such as freshman or junior), and enrollment status (undergraduate or graduate; full-time or part-time). https://www2.ed.gov/policy/gen/guid/fpco/ferpa/students.html
Right now Authorizer uses email address as the unique attribute (since that's what WordPress itself does), and if your CAS server returns multiple email addresses for a user, Authorizer will iterate through them all looking for an existing WordPress account with that email. But there is also a configuration option Link CAS accounts to WordPress accounts by their username that will use the username returned by CAS to link WordPress accounts instead of email. The potential downside here is that this might be a unique Student ID at your institution, which may be considered more private than an email address.
A repeater of fields that could allow CAS attributes to be mapped to user_meta would come in handy.
For my need, I work at a university that issues a userID across multiple systems — but we also don't want that userID (because of FERPA) to be the username on WordPress, where it would be casually discoverable. But at the same time, one person might have a half dozen email addresses (students have one set of email domains; faculty and staff have another domain ... but faculty and staff could also be students and have a student email address, too) and names change and blah blah blah. I don't really care if they wind up having multiple accounts as those things change over time, but I do want to be able to sling info from one server to another and have it hitting the right person.
The second-level bigger ask somehow keep that secret user ID unique and simply look for that first before looking for the wordpress username and if it doesn't find it just carry on like it does now. That is, authenticate on the user email or username. Then, if it finds the email or username, add the second secret ID. I'd write that as a plugin extension if I was clever enough.