Surfaced by QA run #10663 (integration-system.external-schema-introspection) at 79ebb37. Filed existence + mechanism only; full reproduction withheld pending maintainer review per the auth/authz disclosure carve-out — available in the QA session on request.
What
The external-datasource federation route spelling (/api/v1/datasources/:name/external/tables[...]) authorizes on 401-only — it serves the remote schema (table + column inventory) and a full generated object draft to any authenticated principal, with no capability check. Its admin twin (/remote-tables, /object-draft) correctly requires manage_platform_settings (401 + 403). The asymmetry itself is deliberate and pinned as #9593; the open question is whether it is intended on a deployment with open self-service registration (POST /api/v1/auth/sign-up/email), where the distance from anonymous to "reads the external warehouse's schema inventory" is a single self-signup.
Why this needs a ruling, not just a fix
This is a posture decision, not a clear-cut bug: #9593 ruled the two-spelling divergence intentional, but that ruling may not have been weighed against a stock boot with registration enabled. Decide one of: (a) the federation spelling should also require a capability; (b) the divergence is intended and open registration is expected to be disabled/gated in real deployments (document it); (c) schema-introspection is not considered sensitive.
Mechanism (fix-oriented)
The federation routes carry the authentication guard but not the manage_platform_settings capability gate the admin routes apply. Aligning the two spellings (or documenting the intended deployment posture) resolves it.
QA-source: #10663 · integration-system.external-schema-introspection · clause 4 (auth floor, #9593 divergence)
Surfaced by QA run #10663 (
integration-system.external-schema-introspection) at79ebb37. Filed existence + mechanism only; full reproduction withheld pending maintainer review per the auth/authz disclosure carve-out — available in the QA session on request.What
The external-datasource federation route spelling (
/api/v1/datasources/:name/external/tables[...]) authorizes on 401-only — it serves the remote schema (table + column inventory) and a full generated object draft to any authenticated principal, with no capability check. Its admin twin (/remote-tables,/object-draft) correctly requiresmanage_platform_settings(401 + 403). The asymmetry itself is deliberate and pinned as #9593; the open question is whether it is intended on a deployment with open self-service registration (POST /api/v1/auth/sign-up/email), where the distance from anonymous to "reads the external warehouse's schema inventory" is a single self-signup.Why this needs a ruling, not just a fix
This is a posture decision, not a clear-cut bug: #9593 ruled the two-spelling divergence intentional, but that ruling may not have been weighed against a stock boot with registration enabled. Decide one of: (a) the federation spelling should also require a capability; (b) the divergence is intended and open registration is expected to be disabled/gated in real deployments (document it); (c) schema-introspection is not considered sensitive.
Mechanism (fix-oriented)
The federation routes carry the authentication guard but not the
manage_platform_settingscapability gate the admin routes apply. Aligning the two spellings (or documenting the intended deployment posture) resolves it.QA-source: #10663 · integration-system.external-schema-introspection · clause 4 (auth floor, #9593 divergence)