Description

When views are accessed data shall be provided to downstream systems to reason if a request is authorized or not. While identity work has started in OpenSearch plugins such as the Security plugin are the current standard for access control - modification to the existing identity interfaces is out of scope for this effort.

Create a mechanism to allow for requests to convey the resource that is being accessed and the identifier of this resource, in this case a view and the view_id, but this could be a machine learning model and its id or a credential and its identifier. This issue contains an initial proposal built in a proof of concept, but is not hard requirements for the feature.

[Proposal 1] Resource Request

In order to permissions views OpenSearch needs a way to consistently refer to them, this is a generic problem and views will be a first use case. Resource requests require a map of types to identifiers for the request, multiple resources could be part of a single request, but only one of each type.

Considering the request to search a view, POST /view/{view_id}/_search, the path parameter 'view_id' is the type and the value from the request would be the identifier.

public interface ResourceRequest {
   /** Returns the resource types and ids associated with this request */
    Map<String, String> getResourceTypeAndIds();

    /** Validates the resource type and id pairs are in an allowed format */
    public static ActionRequestValidationException validResourceIds(
        final ResourceRequest resourceRequest,
        final ActionRequestValidationException validationException
    ) {;}
}

It would be ideal if this information could be accessed at the RestLayer - less resources spent on rejected requests - but at the TransportLayer will also be needed.

Exit Criteria

• Resource interfaces
• Resource validation patterns
• Expose resource type & id mappings to downstream system