Rename user.username to user.name for SetSecurityUserProcessor

[ywangd]

The SetSecurityUserProcessor auguments ingested documents by adding an user object, where the username field does not conform to the recommended naming convention (name) described in ECS. The purpose of this issue is to faciliate discussion on whether we should rename this field.

PS: there are a few other fields under the user object. They are either confirm to ECS (email, full_name) or have no definition in ECS, i.e. custom fields (metadata, roles etc). Both situations are valid per ECS spec.

[elasticmachine]

Pinging @elastic/es-security (:Security/Security)

[elasticmachine]

Pinging @elastic/es-core-features (:Core/Features/Ingest)

[ywangd]

Summary from team discussion:

• ECS is applicable in this case
• Renaming is a breaking change, hence it should be in 8.0 instead of minors.
• We wanna provide a upgrade/deprecation path of 7.x. The suggested approach is to make the name configurable in 7.x. The config option maintains the existing behaviour, but issues deprecation warnings if not configured to conform 8.0 behaviour.
  • GeoIp and userAgent processors used the same approach to deal with similar renaming issues.

[ywangd]

@albertzaharovits Could you please review my following analysis and proposed solution? I have some new findings which lead to a slightly different approach. Thanks!

The name of the top level field used to store authentication information is configurable. The example in the doc configures it to be "user". However, in theory, this field can be called anything.

For ESC to be really applicable here, the parent field must be named as "user". If it is not, there is no point to apply ECS to the sub-fields, since ESC's choice of using "name" instead of "username" is to follow the Avoid repetition guideline. In addition, we could even argue that when the parent field is not user, say it is auth, it is more desirable for the sub-field to be called username instead of name for clarity.

Therefore my plan is as follows:

• Keep it possible for this field to be username even in 8.0
• Add a new boolean option to the processor configuration. If it is true and the parent field is user, the username field will be saved as name. Otherwise, it is saved as username. (see changed behaviour below)
• The boolean option defaults to true in 8.0 and false in 7.x (for backwards compatibility and will issue warnings when applicable)

[ywangd]

Per Tim's comment, I am tightening the behaviour so that:
If the new compliance option is set, it will also require the field be named as name. Otherwise it is a validation error.

[albertzaharovits]

The name of the top level field used to store authentication information is configurable. The example in the doc configures it to be "user". However, in theory, this field can be called anything.
For ESC to be really applicable here, the parent field must be named as "user". If it is not, there is no point to apply ECS to the sub-fields, since ESC's choice of using "name" instead of "username" is to follow the Avoid repetition guideline.

In the light of this, maybe we should nest all the user properties under a user object field, so the administrator gets to configure <target_field>.user.name

Maybe it's better to continue this discussion under #54051 (review)

[elasticsearchmachine]

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

[elasticsearchmachine]

Pinging @elastic/es-data-management (Team:Data Management)