We have a module-wide setting "Allow SAML users to log in directly", which is off by default - and basically divides users into two groups:
Group 1 is not affected by the setting; group 2(a+b) is.
This division has proven to not be very intuitive, it doesn't fit other Drupal concepts and complicates some other things that need to be tidied up.
1)
Being able to change your own e-mail / password on the Drupal site. TL/DR: we should not do this for group 1; we should make it clearer that group 2a cannot do this; we don't know about group 2b.
Group 2a already cannot do this in practice, because they don't know their existing password. And this is fine because (in most configurations) it should be done at the IdP and synchronized to the Drupal site instead. We want to make that clearer in the edit screen which is ugly/non-intuitive now.
We should not prohibit group 1 from changing their e-mail. It doesn't matter that this group of users is likely small. They definitely know their password and have no other way of changing their e-mail, because they don't exist at the IdP. (If a specific site wants to do generally prohibit all users from changing their e-mail: ...such a site would likely not have 'group 1' users in the first place.)
For this reason, I'm hesitant to introduce a 'site-wide' module setting that will prevent all users from changing their e-mail.
But what about group 2b? We don't know this. They do not clearly fit the division introduced by our "Allow SAML users to log in directly" setting.
2)
I regularly forget that group 2b is/could be separate from group 2a.
We don't have a way of distinguishing 2a from 2b. But even if we did, it wouldn't matter much for the previous point - because we just don't know whether those users know their passwords. It depends on how their accounts were created. Some organisations mass-pre-create accounts in order to be able to keep the "create users" setting turned off... in which case users probably don't know their Drupal passwords.
In cases where a user used to be part of 'group 1' but now moves to 'group 2b'... it's hard for the module to know what to do. It really depends on the specific site.
3)
We're soon going to tighten some access control related situation (details withheld) - which might lock out a small subset of users from getting into the site.
Turn the binary "Allow SAML users to log in directly" configuration into a user permission. Then site administrators are better equipped to handle these different groups of users. (I've said "group X of users" so many times now, that it's becoming evident this fits the role system better than configuration settings.)
That "log in locally" permission can also govern whether or not the user sees their "new password" field in their edit screen if they have ever logged in through SAML - because the only use for (being able to change) your password is login.
That same permission can govern whether the user is able to change their e-mail Then we don't need a configuration setting for this. Notes:
Comments
Comment #2
roderikComment #4
roderikComment #5
hexblot commentedI personally find all of the above quite reasonable.
A couple of questions to verify:
- admins can still create accounts, give them roles etc and once user tries to login, they will get matched with SAML, right?
o Use case: a specific user, belonging to eg "Marketing" group will be the local (limited) admin and needs the extra role granting him some superpowers. We typically pre-create the account, to avoid the "please login first so we can promote you" scenario.
- if a SAML user email is changed on the IdP side, the admin needs to be able to change the email address of that (different than their own) account
o Use case: emails are autogenerated based on first/last name. Sometimes (more often that I believed) these are either outright offensive or have offensive connotations. In those cases, IT can change the primary email of the user to something different. We need to avoid having two accounts (one with each email) on the system.
o Proposed solution: users with the core "administer users" permission should be able to see the email field of accounts being edited.
I understand if the above might be too specific to our use-case, but wanted to raise them as possible edge cases.
Comment #6
roderikCorrect. And these are generally supportable use cases.
1. Yes that's possible. Users can get linked (after you enable the corresponding checkbox in the global settings), and their existing roles / other properties will not be altered unless you do so through a custom event handler / the samlauth_user_roles module.
2. Yes.
#3185846: Hide password change for SAML-authed users broke this, but I spotted that yesterday, so this issue fixed it by adding aOh wait, that was for the password, not the e-mail. Anyway: yes.if ($account->id() == \Drupal::currentUser()->id()in the form_alter.