[Timeline][Search Strategy] - Authorization architecture around search strategy

[yctercero]

An awesome feature of search strategy is that it allows a user to continue interacting with the applciation while long running queries are conducted in the background. Part of that feature includes giving the user the ability to cancel their long running queries as well.

We figured out while implementing RBAC for alerts within our search strategy that in order for RBAC to work, we needed 1) the full Kibana request passed down to us in the dependencies and 2) the ability to query using internal Kibana user since with RBAC users are not assigned ES privileges. Both of these requirements were met and so RBAC is being added to the timeline search strategy.

However, @lukasolson brought to our attention that the authorization should also occur on cancel.
#105333 (comment)

This ticket is meant to discuss and hopefully make a decision on the following:

• Who should be allowed to cancel requests?
  • Current search strategies use asCurrentUser so authorization is baked into the calls via ES privileges
• If we do want to restrict who can cancel, what information is needed to conduct the auth?
  • We'd need at least the full KIbana request and perhaps the rule type ids?

[elasticmachine]

Pinging @elastic/security-threat-hunting (Team:Threat Hunting)

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[vadimkibana]

Thank you for contributing to this topic, however, we are closing this issue due to inactivity as part of a backlog grooming effort. If you believe this discussion thread still should be considered, please reopen with a comment, potentially in the Discussions section.