Don't allow SSO users to override their email and password
Being on our SSO implementation, we see a major problem with the
ability for users to change their passwords and email addresses while in UserVoice. This gives
the user the impression that they have changed their emails and password in our system as
well, which of course means they can't login to the site.
Andrew Moyer
shared this idea
We just rolled out this functionality! If you are using Single Sign On (SSO) as your only option for authentication, your users will no longer see the option to update their email address and password in UserVoice.
If you using SSO in conjunction with UserVoice’s default authentication, then users will be able to edit their username and email since you allow both sign in options.
Have questions or more feedback, let us know!
-
Aaron Hixson
commented
Allowing users to change the password when they are an SSO customer seems more like a bug than a feature request. It is presented functionality that can never work => hence bug.
-
AdminJoey P
(Admin, UserVoice)
commented
1) Make it so that changing your UV email/password is reflected on your SSO profile, OR doesn't affect logging in with SSO.
2) Not allow SSO users to edit password/email. you can do this with custom CSS, but it isn't elegant or obvious. Also, accounts on Enhanced which are using SSO, don't have access to custom CSS.
Alternatively, I guess we could give a warning that you will lose access with your new email/password if an SSO user tries to change this in UV
-
Doug Laundry
commented
It would break my user experience if users were suddenly unable to change their settings such as Display Name and Email Address. I want for it to be at the user's discretion how their name appears to other users of my UserVoice site, and which email address they use to receive notifications.
I agree with Daniele regarding Password being different. Password should be governed by the Identity Provider in an SSO relationship (i.e., my token service), not by the Relying Party (i.e., UserVoice). Muddying this separation of concerns can only lead to confusion.
-
Daniele Muscetta commented
I have a slight twist of this. I think this feedback should be broken down in discreet parts...
I have the following issues with this:1) yes allowing a SSO user to 'change password' confuses them - they think they are changing it on the 'main' site. Since they'll always come in thru SSO only, that option ideally should go altogether for SSO users.
2) in our setup, we do NOT pass email - often we do not even KNOW the user's email in the first place. But I would like them to be more engaged.... therefore I would like the user to customize and provide his/her email to UserVoice.... so that they can subscribe to comments, status updates, etc. Right now, the 'settings' option is too hidden, and 99% of my users have not even SEEN it and therefore they are NOT providing their emails... greatly reducing 'stickyness' and engagement...
-
Catherine Fitzgerald
commented
We need the ability for the Settings link to be disabled/not shown desperately.
-
Kevin
commented
I also have this problem. All of the settings have this problem if we are sending the data over via SSO, such as display name. I can change it in uservoice, but the next time I login via SSO it will be overwritten with what I send in the SSO token. If I don't send it with the token it is not overwritten, but then it will be blank unless the user explicitly sets it on UV, even though they have already set it on our site.
I think the best solution would be as suggested - allow each of the settings to be optionally disabled so that we can match with the data that we are sending with the SSO token.