[Question] How to determine when a REST request is destined for an extension

[stephen-crawford]

Problem Statement

The Security Plugin needs to be able to tell when a REST request is destined for an extension.

$\textcolor{orange}{\textsf{Orange text is a header for a decision that is not made }}$
$\textcolor{teal}{\textsf{Teal text is a header for a decision that is made }}$
$\textcolor{violet}{\textsf{Violet text is the recommended option }}$
$\textcolor{lime}{\textsf{Lime text is the chosen option }}$

What type of REST requests are intended for extensions?
How does the Security Plugin interact with REST requests?
What is the current method of signifying things?

Action items decided on this issue:

• How do we signal a request is destined for an extension?

$\textcolor{orange}{\textsf{How do we signal a request is destined for an extension?}}$

When a request is made by a user, it needs to be possible to determine whether the request is destined to an extension or simply intended for OpenSearch itself. If the request is meant for an extension the authorization steps are more complex since the Security plugin needs to grant an on-behalf-of token (if it is a user request). The RestRequest logic in core does not a have a built-in way of determining when a request is meant for an extension so one will have to be added.

In the current version of the opensearch-sdk-java, extensions routes look like /_extensions/_opensearch-sdk-java-1/hello.

For example:

curl -X GET localhost:9200/_extensions/_opensearch-sdk-java-1/hello

This leaves two main options for signifying a request is destined for an extension:

1. The first option is simply to parse the request and check that the route has both the _extensions flag as well as a registered extension name i.e. _opensearch-sdk-java-1. This option is easy to implement and only requires the addition of a hook to parse the request before a token is created.

Pros	Cons
Easy to implement	Requires parsing the request
Connects to REST Handler	Could be issues if there are requests with the same route elements not intended for an extension, i.e. an API to change settings for the extension

What do code changes look like?
For this option, changes will take place in the Security Plugin by parsing the REST request during the REST layer authorization. Putting a check at the start of the REST layer authorization process will allow the Security plugin to determine whether a request is destined for an extension before it needs to parse the authorization credentials. This will let the Security plugin handle the request appropriately from the start.

2. The second option is to make use of the RestSendToExtensionAction.

It may be possible to do this by seeing if the original RestHandler is a RestSendToExtensionAction. This option would lookup the registration in core to determine whether a request is in fact destined to an extension based on the previous registration of the actions request. By parsing information on registration and then storing it somewhere, it would be possible to later check whether a request is destined for an extension. This lookup would decrease any unnecessary work done in the Security Plugin since you could direct the request immediately to the appropriate authorization channel based on where it was destined.

Relevant lines read:

public TransportResponse handleRegisterRestActionsRequest(RegisterRestActionsRequest restActionsRequest) throws Exception {
    DiscoveryExtensionNode discoveryExtensionNode = extensionIdMap.get(restActionsRequest.getUniqueId());
    RestHandler handler = new RestSendToExtensionAction(restActionsRequest, discoveryExtensionNode, transportService);
    restController.registerHandler(handler);
    return new AcknowledgedResponse(true);
}

What do code changes look like?
For this option, changes would be required in OpenSearch core since the introduction of a new handler during the REST action registration would be required. It would also require adding code to direct the request to a different area of the Security REST authorization logic. It would not make sense to make the changes in core if the request were just going to be handled the same in the Security Plugin. So determining how to shortcut the authorization based on the destination would be required and need to be added into the authorization logic in the Security Plugin.

[cwperks]

@scrawfor99 Can this be closed? If a request is destined for an extension the RestHandler will be an instance of RestSendToExtensionAction

[stephen-crawford]

@cwperks sounds good.

[Closure] As mentioned by Craig, if a request is destined for an extension the RestHandler will be an instance of RestSendToExtensionAction.