Saved-objects authorization more granular than type #47503
Labels
enhancement
New value added to drive a business result
Feature:Security/Authorization
Platform Security - Authorization
Team:Security
Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Projects
Currently, we authorize users to access saved-objects based on the
type
andaction
:kibana/x-pack/plugins/security/server/lib/saved_objects_client/secure_saved_objects_client_wrapper.js
Line 119 in 1f38026
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
andaction
allowed us to write a rather simplistic SavedObjectsClient wrapper. Each of the SavedObjectsClient wrapper methods require the user to specify thetype
, 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
andupdate
actions specifically.The text was updated successfully, but these errors were encountered: