Create API for dashboards-plugins to get resource access level

[cwperks]

Summary

This PR adds a new security REST API for resolving the current user’s effective access on a single shareable resource:

GET /_plugins/_security/api/resource/access?resource_type=<type>&resource_id=<id>

The goal is to give Dashboards plugins a simple, security-owned way to understand what the current user can do with a resource without re-implementing resource sharing logic in the UI.

This was motivated by the new collaborative docs plugin work, but the API is generic and intended for any resource-sharing-enabled plugin.

Problem

Today, a Dashboards plugin can fetch:

• registered resource types and access levels
• sharing metadata for a resource
• accessible resource lists

But it does not have a clean API for:

• the current user’s resolved access level on one resource
• the current user’s resolved allowed actions on that resource
• whether the current user can share that resource further

That leaves the UI with two awkward options:

• infer permissions client-side from authinfo + share_with + role matching
• wait for a 403 from a write action and then degrade the UX afterward

Both approaches push authorization reasoning into the client, which is brittle and duplicates logic that already exists in security.

What this PR adds

New endpoint:

GET /_plugins/_security/api/resource/access

Query params:

• resource_type
• resource_id

Response shape:

{
  "access": {
    "resource_id": "abc123",
    "resource_type": "docs-document",
    "is_owner": false,
    "is_admin": false,
    "effective_access_level": "docs_read_only",
    "access_levels": ["docs_read_only"],
    "allowed_actions": ["docs:document/get", "docs:document/list"],
    "can_share": false
  }
}

Behavior

The endpoint resolves access for the current authenticated user by:

• identifying the resource sharing record for the requested resource
• resolving matching access levels for the current user
• resolving those access levels to concrete allowed actions via the registered resource action groups
• returning convenience flags for is_owner, is_admin, and can_share

Behavior notes:

• owners and admins receive fully resolved access for the resource type
• shared users receive only the actions implied by their matched access levels
• users without access receive 403
• invalid resource types return 400
• missing resources return 404

Implementation

Main additions:

• new REST handler for /api/resource/access
• new response model for resolved resource access
• new ResourceAccessHandler method to resolve access levels and allowed actions for the current user on a single resource

This intentionally builds on existing resource-sharing internals rather than introducing a second permission model.

Why this shape

I chose to return both:

• access_levels
• allowed_actions

instead of only a single “effective access level” because:

• a user may match multiple access levels
• allowed_actions are what UIs actually need to enable/disable affordances
• this keeps the API generic across plugins with different action models

effective_access_level is included as a convenience for display and simple UI flows.

Testing

Added integration coverage using sample-resource-plugin for:

• invalid resource type
• owner access
• super-admin access
• read-only shared access
• read-write shared access
• full-access shared access
• forbidden response for non-shared users

Follow-up / motivation

This API is already useful for a Dashboards resource-sharing consumer like the docs plugin, where the UI needs to know up front whether to allow:

• edit
• delete
• share

instead of waiting for a write failure.

Example use cases

Dashboards plugins can use this to:

• open shared resources directly in read-only mode
• hide or disable destructive actions when not allowed
• decide whether to show or enable sharing controls
• avoid duplicating security-side access resolution logic in the browser

Checklist

• API implemented in security
• integration tests added with sample-resource-plugin
• behavior verified for owner/admin/shared/non-shared users

If you want, I can also turn this into a shorter, more “upstream OpenSearch-style” PR description with less context and a tighter changelog tone.