How to support extensions parity for user information

This issue is meant to decide how information user should be provided to extensions based on exiting behavior for plugins

Background

Many existing plugins reference common-utils User object. For plugins that implement security checks on resources these are the limits of the existing security information that is exposed.

sequenceDiagram
    title How Plugin access to User Context
    actor User
    box white OpenSearch Process
       participant RestController
       participant SecurityPlugin
       participant Plugin as Plugin
    end

    User->>+RestController: Send search request
    RestController->>+SecurityPlugin: Authenticate user
    SecurityPlugin-->>-RestController: Store user object in thread context
    RestController->>+Plugin: Invoke plugin method
    Plugin->>+RestController: Read user from thread context
    RestController-->>-Plugin: Return user object
    Plugin-->>User: Return search results

Example user object represented as JSON

{
    "name": "UserNameOrUserEmailAddress"
    "backend_roles": ["BackendRoleFromLDAP", "BackendRoleFromSAML"]
    "roles": ["security_rest_api_access", "alerting_full_access"]
    "custom_attribute_names": ["attr1", "attr2"]
    "user_requested_tenant": "private"
}

Problem

User context information is stored within the thread context. Extensions should never have access to the thread context and there must be a way to reason decisions about user with existing data.

NOTE: Exposing backend_roles / roles directly to an extension should not be done to prevent tight coupling and information disclosure, instead extensions should use make request to a checkPermissions API with an action name & resources. This path is being built for parity to let plugins have a clear migration path to extensions.

Option 0: Don't provide user information

In this option extensions do not have support for existing scenarios where reasoning is done about the user identity or resource checks.

For each plugin -> extension migration the plugin would need to find any dependencies on User data and remove them. This might require modification or deprecation of features

Pros:

• Prevents exposing user information to extensions

Cons

• Feature deprecation or modification might be substantial effort
• Regression in functionality for plugin users

Option 1: Include user information on all requests to extensions

In this option, changes would be made to the RestSendToExtensionAction, the user information is collected from the existing thread context and provided to the extension as part of the payload of the ExtensionRestRequest. Extension would be able to retrieve this information as an object and use it for new / existing scenarios.

sequenceDiagram
    actor User
    box white OpenSearch Process
       participant RestController
       participant SecurityPlugin
       participant RestSendToExtensionAction
    end
    box white Separate Host
       participant Extension
    end

    User->>+RestController: Send search request
    RestController->>+SecurityPlugin: Authenticate user
    SecurityPlugin-->>-RestController: Return user context
    RestController->>+RestSendToExtensionAction: Invoke method with user context
    RestSendToExtensionAction->>+Extension: REST API Forward user object to extension
    Extension->>+RestSendToExtensionAction: Process request with user object
    RestSendToExtensionAction-->>-RestController: Return search results
    RestController-->>User: Return search results

Pros:

• Feature parity for existing plugins scenarios

Cons:

• Perpetuates information disclosure
• Perpetuates coupling of extensions with existing permissions constructs

Option 2: Build new security features to support exist plugin scenarios

In this option for all scenarios different scenarios that user information is used new features / API would be build to support individual requirements. For Anomaly Detection detector ownership check, an object that represented the identity of the caller, but encrypted would be provided. This object would be comparable as before if a user making a request != the representative identity but would not expose the username/email etc. There would need to be many additional scenarios supported.

Pros:

• Opportunity for deploying security best practices
• Scenarios supported would cover a variety of future extensions needs
• Slow time to market

Cons:

• Considerable investment for each plugin and each scenario associated with them
• Requires changes in security plugin for new APIs
• Requires changes in all plugin to extension migration efforts

Option 3: Include user information on requests to extensions restricted with 'LEGACY' scope [Recommended]

In this option we would use the approach from Option 1, but the information would not be included by default, the field would be annotated with a deprecation message. Only if the extension was permitted to a legacy_user_context scope would the information be included and it would be removed from the extensions SDK in a future release.

Pros:

• Supports existing scenarios
• Clearly marks extensions that do not follow best practices

Cons:

• Introduces functionality with intention of deprecation