[D] Decouple public UI self-registration from LDAP/OAuth auto-provisioning (new AUTH_USER_SELF_REGISTRATION flag?) [superset]

["rusackas (via GitHub)" <gi...@apache.org>]

GitHub user rusackas created a discussion: Decouple public UI self-registration from LDAP/OAuth auto-provisioning (new AUTH_USER_SELF_REGISTRATION flag?)

## Summary

I'd like to propose decoupling **public UI self-registration** from **federated (LDAP/OAuth/SAML) user auto-provisioning**, which Flask-AppBuilder currently controls with a single flag: `AUTH_USER_REGISTRATION`.

This surfaced while reviewing a community-contributed patch ([devin-ai-integration on a fork](https://github.com/victorlga/superset/pull/16)), and I think the underlying idea is worth discussing upstream before anyone opens a PR — it changes auth semantics and a default, so it deserves more eyes.

## The problem

To let LDAP/OAuth/SAML create a user record on first successful login, operators must set `AUTH_USER_REGISTRATION = True`. But in FAB that same flag **also** exposes the public-facing DB registration path — the Register button on the login page, `/register/`, `/register/activation/<hash>`, and the "User Registrations" admin menu.

So an operator who only wants provider-based user sync is effectively forced to also enable a public self-registration form. There's no way to say "auto-provision authenticated SSO users, but don't expose a public signup form."

## Proposed direction

Introduce a dedicated flag, e.g. `AUTH_USER_SELF_REGISTRATION` (default `False`), that **exclusively** gates the public UI registration path, while `AUTH_USER_REGISTRATION` continues to govern federated auto-sync:

| Desired behavior | `AUTH_USER_REGISTRATION` | `AUTH_USER_SELF_REGISTRATION` |
| --- | --- | --- |
| LDAP/OAuth sync only (no public signup) | `True` | `False` |
| LDAP/OAuth sync + public signup | `True` | `True` |
| No registration at all | `False` | `False` |

## Things to settle before any PR

- **Threat-model framing.** Under our [`SECURITY.md`](https://github.com/apache/superset/blob/master/SECURITY.md), `AUTH_USER_REGISTRATION` is operator-controlled deployment config and the coupling is documented FAB behavior — so this is **hardening / footgun reduction, not an in-scope vulnerability**. I want to be explicit about that so it's reviewed as a feature, not rushed as a security fix.
- **Default + backwards-compat.** A new flag defaulting to `False` changes behavior for anyone who set `AUTH_USER_REGISTRATION=True` today and *relies* on the public form appearing. Needs an `UPDATING.md` entry and a clear migration note.
- **Is FAB the right layer?** Worth asking whether this belongs upstream in Flask-AppBuilder rather than as Superset-specific view/menu overrides.
- **Scope.** The fork patch touches config, `views/base.py` bootstrap, `views/auth.py` route guards, the security manager's view registration, the admin menu, Helm, and docs. If we proceed, what's the minimal coherent surface?

## Question

Does this seem worth pursuing, and if so — new Superset flag, or push it upstream to FAB? Any objections to the proposed default?

cc @michael-s-molina @dpgaspar @sha174n for thoughts on the auth-config semantics and the right layer for this.

GitHub link: https://github.com/apache/superset/discussions/41219

----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org