Saved-objects authorization more granular than type

[kobelb]

Currently, we authorize users to access saved-objects based on the type and action:

kibana/x-pack/plugins/security/server/lib/saved_objects_client/secure_saved_objects_client_wrapper.js

Line 119 in 1f38026

async _ensureAuthorized(typeOrTypes, action, args) {

This is potentially limiting for Alerting's use-case, and we don't want to have to force Alerting to declare a new saved-object type purely for authorization. There's potential that Alerting, and others, will need to authorize users to access a sub-set of a saved-object type.

Performing authorization using just the type and action allowed us to write a rather simplistic SavedObjectsClient wrapper. Each of the SavedObjectsClient wrapper methods require the user to specify the type, so authorization can be performed prior to executing the actual calls to perform the action. If an additional parameter is added to each of the methods to further specify which saved-objects, for example sub-type, the Security SavedObjectsClient wrapper can continue the current simplistic approach.

However, if the method signatures for the SavedObjectsClient methods are left unchanged and yet the user should only be authorized to access a sub-set of saved-objects, the Security SavedObjectsClient wrapper will have to adopt a different approach. This potentially complicates authorizing access to the find, delete and update actions specifically.

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[kobelb]

/cc @elastic/kibana-stack-services

[kobelb]

The primary motivation for this was Alerting, which we explored in this proof of concept. However, we realized that trying to force Alerting to abide by the saved-objects authorization model was limiting when it comes to preventing specific operations which don't fall within standard CRUD based operations, for example the privileges allowing one to mute an alert of a specific type. At the moment, we've decided to have Alerting authorize it's own operations within its AlertsClient and utilize its own authorization model.