Onboard Dashboards saved objects and scope reads to a workspace

[DarshitChanpura]

Description

Groundwork for bringing OpenSearch Dashboards workspaces under resource sharing. Two related pieces:

1. Register Dashboards saved objects. Dashboards is a Node.js application, so nothing on the OpenSearch side can implement ResourceSharingExtension for its saved objects — which is why the SPI seams added earlier have no implementer. A built-in extension registers them from inside the security plugin instead. A separate plugin would also work, but a core module depending on the security SPI would not: the SPI itself builds against core, so that is a build cycle.

Declares the workspace container type (which is what lets the write-path container fan-out resolve a workspace's own sharing record) plus the shareable saved-object types (dashboard, visualization, search, index-pattern). They all live in one index and carry their type in a type field, so each is registered as its own resource type over that shared index. Member types declare workspacesField("workspaces"); workspace declares none, since it is a container rather than a member.

Access levels are registered programmatically rather than via a resource-access-levels.yml: that file is resolved per extension by a fixed filename from the classloader, so a copy inside this plugin would be ambiguous with a plugin's own copy wherever both are visible on one classpath.

2. Optional request-scoped narrowing. Workspaces are membership-scoped, not request-scoped: DLS filters a resource's workspaces field against the user's entire accessible-workspace set, and that is the security floor. On top of that, when Dashboards forwards the workspace the UI is currently in as a currentworkspace header, visibility narrows to that one workspace. The requested workspace is intersected with the user's trusted membership, so it can only narrow, never grant — a foreign or spoofed workspace narrows to empty.

BackendRegistry reads the header next to the existing tenant handling and re-emits it server-side. It uses putPersistent rather than putHeader, because the plugin's own searches run under a stashed system-subject context where only persistent entries survive — the same mechanism that carries the authenticated User to the DLS valve.

Safety

The saved-object registration is gated twice, so it is inert unless explicitly opted into:

1. The extension is only registered when plugins.security.resource_sharing.dashboards_onboarding.enabled is set (default false).
2. A registered type is only enforced once it also appears in plugins.security.resource_sharing.protected_types.

Testing

• DashboardsResourceSharingExtensionTests — declared types and index; workspace opting out of the workspaces field while members opt in; resolution through ResourcePluginInfo once protected; non-protected types not resolving; an empty protected_types leaving the resource-index set empty (so the index listener is not attached and no sharing index is created); mixed null/non-null workspacesField declarations not tripping the per-index conflict check; and programmatic access-level registration including the derived level names and default.
• testCurrentWorkspaceHeaderNarrowsReadVisibility (live integration) — no header gives full membership and the resource is visible; the user's own workspace keeps it visible; a workspace the user is not a member of narrows to empty and hides it.

What this does not do yet

• Reads only. Registering the types brings read visibility via DLS. Raw saved-object writes are not governed: ResourceAccessEvaluator.shouldEvaluate explicitly excludes DocWriteRequest, and core's DocRequest.type() returns "indices" rather than the saved-object type. There is a real design question here, since the resource-access path is deliberately async while the multi-tenancy handler that already authorizes raw saved-object writes is synchronous — happy to take direction before building it.
• Membership resolution is still empty. resolveWorkspacesForUser is not overridden, so workspace-based visibility stays off until membership is derived from the workspace:{id} sharing records.
• Migration. hasPermission denies when no sharing record exists, so existing saved objects need backfilling before any type is added to protected_types in a live cluster.
• The Dashboards-side change that actually sends currentworkspace is a companion PR in security-dashboards-plugin, and the header must be listed in opensearch.requestHeadersWhitelist.

Open question

Carry the current workspace on User like requestedTenant (survives to all nodes, cleaner downstream), or keep the persistent thread-context entry used here?

Check List

• New functionality includes testing
• Commits are signed per the DCO using --signoff