How to remove custom metadata fields from users and roles

Elastic Stack Elasticsearch
#1

Hi,

I am running a 7.10 Stack with Security enabled and I am currently playing around with the ElasticSearch REST API for creating users, roles and so on. The usecase here is to add advanced information to the security objects(like description, the team it belongs to, last change date, ...).

For this, I use the metadata fields which works fine for adding information but I cannot find a way to remove the fields. Add a custom field to an existing user:

PUT _security/user/testusr
{
  "roles": [
    "reporting_user"
  ],
  "metadata": {
    "description": "abcdef"
  }
}

=> the field metadata.description now contains the value abcdef.

Here is what I tried so far to remove the field:

  1. remove the custom field from the request
PUT _security/user/testusr
{
  "roles": [
    "reporting_user"
  ],
  "metadata": {
  }
}

=> the field metadata.description still contains the value abcdef.
2. set custom field to null

PUT _security/user/testusr
{
  "roles": [
    "reporting_user"
  ],
  "metadata": {
     "description": null
  }
}

=> the field metadata.description still exists - now with a nullvalue.
3. remove metadata element in request

PUT _security/user/testusr
{
  "roles": [
    "reporting_user"
  ]
}

=> the field metadata.description is gone but all other metadata fields too.

How can I remove a metadata field without removing the others?

Is it a feature that not supplying the metadata in the request removes all stored metadata or is it a bug? I would expect it to behave the same as providing an empty metadata element.

Best regards
Wolfram

#2

Hi @Wolfram_Haussig ,

The PUT APIs are designed to overwrite the complete entity, which includes the metadata field (unlike the PATCH HTTP verb). There's only a single exception for user entities, and that's the password field.

This means that the complete metadata must be specified on each API, no merges happen server-side.

#3

Hello @Albert_Zaharovits ,

Thank you for your response! I am a bit confused though as I already tried providing the metadata field(see my first post with an empty metadata) and the fields still exist after that!

If it would work as you described it would be fine for me though..

Best regards
Wolfram

#4

I think this is a bug specifically for users.

Because we need to preserve a user's password when they are updated, internally PUT /_security/user/{name} will perform an update on the underlying document unless the request body includes a password (or password hash).

The semantics of that update means that metadata fields are not removed, even though they are supposed to be (and are for other object types like roles).

Until we work out how to fix this (with minimal impact to anyone who relies on the existing behaviour) the only workaround I know of is to update the user's password as part of the PUT request.

#5

Hello @TimV ,

Thank you for your confirmation! Unfortunately, the workaround of including the password will not always work for us because I might want to annotate a user where I do not know the password so I think I will go with setting it to null for now.

Shall I create a github issue for it?

Best regards
Wolfram

#6

No need, I already have.

1 Like
#7

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.