Removing Application Privileges

[kobelb]

When executing the following two POSTs to /_xpack/security/privilege, the second POST isn't removing the no longer specified privilege:

POST /_xpack/security/privilege

{
    "kibana":{
        "all":{"application":"kibana","name":"all","actions":["action:*"],"metadata":{}},
        "read":{"application":"kibana","name":"read","actions":["action:saved_objects/config/get"],"metadata":{}}
    }
}

POST /_xpack/security/privilege

{
    "kibana":{
        "read":{"application":"kibana","name":"read","actions":["action:saved_objects/config/get"],"metadata":{}}
    }
}

Is this how we want this to behave? Is there some way to have the operation overwrite all of the privileges for the specified application?

[elasticmachine]

Pinging @elastic/es-security

[albertzaharovits]

I think this is unexpected, although, because of using POST instead of PUT, it should convey that the API stores subsequent resources (app privs) instead of updating existing ones. Hence no delete can happen as a result of a POST call.

In my mind the unexpected-ness stems from the app privs being grouped by app and priv names. I understand that there can't be a top level list.
I also realize parsing ApplicationPrivilegeDescriptor from requests that are broken down by app and priv names would become a hotch-potch. But I don't see the current approach surviving too much, and then it will be more difficult to remove.

[tvernum]

This is definitely the intended behaviour. I understand why it seems weird, given the body structure, but it is intended.

As @albertzaharovits has said, the main purpose of the grouping by application name is so that the body is an object not a list, because posting lists has problems in ES, and this seemed like the right solution, but I didn't consider the potential confusion here.

I think it would be worse to have the behaviour you're asking for because it is a POST.

Options from here:

• Add a PUT version that does delete missing privileges. I don't like that because having such a subtle difference between PUT and POST is likely to confuse even more.
• Add an option for a null privilege which would be translated to delete, like:

  POST /_xpack/security/privilege
  {
    "kibana":{
      "all" : null,
      "read":{"application":"kibana","name":"read","actions":["action:saved_objects/config/get"],"metadata":{}}
      }
  }
  

  To do a full replace, you would GET all the privilege names, then build an object that contains null for all the old names, add all the desired privileges into it and POST that object.
• Accept the behaviour, and just use DELETE to get rid of stuff you don't need.

I prefer the latter since it requires no work from me :)
Is there a reason to avoid it? The very-temporary existence of privileges you no longer want shouldn't cause significant problems for you.

[kobelb]

In most situations, Kibana doesn't need to delete missing privileges because we're using a static list of privileges and only updating the actions during minor releases. If we're required to execute a DELETE when we wish to remove the privileges, we can definitely do so.

Introducing a PUT would definitely make Kibana's usage easier. However, I've noticed that the X-Pack Security APIs generally do the same behavior for PUT/POST and don't seem to embrace the "more traditional" RESTful differentiation between PUT and POST, which I assume was to make the APIs easier for users since this is a common source of confusion.

[bizybot]

I agree about making the RESTful differentiation between PUT and POST and should not confuse API users as this seems to follow the purpose of PUT and POST if something that we follow and it's allowed in our API design.

[kobelb]

Closing this issue, as the POST is behaving as intended and Kibana is performing an explicitly DELETE when required.