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

[rusackas]

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), 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, 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.