[BUG] Security: wrong schemes for PUT requests

[Jakob3xD]

What is the bug?

The OpenSearch.openapi.json currently contains some issues related to /_plugins/_security/api and the component schemes they reference.
Most of the GET requests like for roles, internalusers, actiongroups and tenants return the keys hidden, reserved and static which is represented in the schemes. The same schemes are used for the PUT request but those keys are not valid for PUT requests.
In addition the internalusers PUT component scheme misses the password field.

How can one reproduce the bug?

 curl -XPUT -u 'admin:myStrongPassword123!' -k https://localhost:9200/_plugins/_security/api/roles/test -H 'Content-Type: application/json' -d '{"reserved":true,"hidden":false,"cluster_permissions":[],"index_permissions":[],"tenant_permissions":[],"static":false}}'

Returns:

"status":"error","reason":"Invalid configuration","invalid_keys":{"keys":"static,hidden,reserved"}}

What is the expected behavior?

I would expect an extra component scheme for the Put Requests.

Do you have any screenshots?

PUT Role references the scheme Role:
https://github.com/opensearch-project/opensearch-api-specification/blob/23fa274e6b8609db587623d6f1f05346b023bd11/OpenSearch.openapi.json#L14226

Scheme Role:
https://github.com/opensearch-project/opensearch-api-specification/blob/23fa274e6b8609db587623d6f1f05346b023bd11/OpenSearch.openapi.json#L33784-L33818

GET role references RolesMap
https://github.com/opensearch-project/opensearch-api-specification/blob/23fa274e6b8609db587623d6f1f05346b023bd11/OpenSearch.openapi.json#L14164

Scheme RolesMap references Role:
https://github.com/opensearch-project/opensearch-api-specification/blob/23fa274e6b8609db587623d6f1f05346b023bd11/OpenSearch.openapi.json#L33863-L33868

[dblock]

@DarshitChanpura do you have some time to check this one?

[DarshitChanpura]

Yes, I can take a look. From what I understand, static,hidden,reserved are reserved for admin (and super-admin) users only. I will take a detailed look and update here.

[dblock]

@DarshitChanpura Was this resolved with #439?