Enforce Single Sign-On - Enterprise exclusive?

[MDXDave]

I do not understand why such a simple switch is made to be exclusive for the Enterprise/Business edition?
The only thing the switch does is to provide a cleaner login interface for end users and it avoids that the user tries to enter ther credentials by mistake in this form instead of the SSO-service login form.

[shogunpurple]

It also totally locks out password users, and enforces the use of SSO logins for the whole org so you don't have several different ways of logging in. More information here:
https://docs.budibase.com/docs/enforced-sso

[MDXDave]

Yes, I understand that, but not why the "feature" is exclusive.

Many small companies or individuals who are using a single-sign-on-flow, do not need a password authentication on every single service. IMHO if the service provides the SSO function for free, it should be also possible to disable the password authentication too, because the login form only causes confusion on the end user.

For example, Mattermost provides the SSO authentication with Gitlab for free and let disable the username or email authentication: https://docs.mattermost.com/configure/authentication-configuration-settings.html#email

I totally understand that you need to make money from selling enterprise licenses and i really appreciate it that most parts of the software are available for free, but maybe you can think about, if this switch is a real selling point for the enterprise license :)

[shogunpurple]

It's not just confusion though if you have email users - who can still log in as normal with their email. In your case you don't have email users, so it's a little different.

Yes, mattermost do provide that for free, but as you mentioned it's only for gitlab.

Would you prefer we put all the SSO providers apart from gitlab (and OIDC in general) on our enterprise plan and provided email configuration for free? Or are you suggesting we have fully free OIDC with any provider as we do today, along with free enforceable SSO also?

[MDXDave]

I would suggest to have full free OIDC with any provider along with free enforceable SSO. :)

And, by the way, I am very thankful that you provide OIDC in general for free, because IMHO SSO is a core security requirement.

[J4NS-R]

FWIW if you have control over the ingress you can effectively disable email & password sign-in by blocking the following URL path:

/api/global/auth/default/login

In my case I just configured my reverse proxy to always return a 403 for that path. OIDC logins are unaffected since they use a different URL.