Changes to `signin_enabled` broke customer workflow
Merge request: gitlab-org/gitlab-ce!12491
Customer is using SAML authentication with GitLab. They want all web auth to go through SAML guaranteed. However, they also want to allow users to set a password so they can use Git over HTTPS. This used to be the behavior when an instance had 'signin_enabled' set to false - the sign in form was removed but setting a password and using it with Git over HTTPS continued to work.
Since the linked merge request, the option was changed to 'password_authentication_enabled' and it now prevents setting a password or using a password to authenticate Git over HTTPS. This change seems like it had the right idea in mind. However, it broke the customer's workflow.
Now we're faced with, revert it or add an additional option (or both - revert now and add additional option later).
@smcgivern noted that we can't really revert the whole thing because the API was changed, and there's also database changes. I wonder if we could revert the portions that prevent setting a password and using the password with Git over HTTPS but leave the rest? Then we can follow up in 10.0 with the additional option.
cc/ @DouweM