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 [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
