HLRC: Add get users action

[nknize]

This commit adds get users action to the high level rest client.

Relates #29827

[elasticmachine]

Pinging @elastic/es-core-features

[nknize]

Labeling this as WIP as its not entire complete but I wanted to get some immediate feedback to keep this task moving toward completion. I have one key question:

• The example in the docs have "enabled" : true in the response. But the user class didn't have an enabled field, only the AuthenticateResponse class did. I added boolean enabled to Users but I don't know if this is the right way to go. Furthermore, its causing a test failure now in SecurityIT#testAuthenticate

Other than that I'd like someone to have a quick look to verify I'm not missing anything. Once the above question is answered I think I just need to add an explicit test for calls to the user endpoint without any usernames explicitly provided.

[nknize]

ping: @elastic/es-security

[jaymode]

But the user class didn't have an enabled field, only the AuthenticateResponse class did. I added boolean enabled to Users but I don't know if this is the right way to go.

@albertzaharovits had originally put the enabled field on the user and then removed it from the object, see #33552 (comment) for the reasoning.

[jaymode]

I did not see anything jump out as missing to me

[albertzaharovits]

@nknize I would much prefer not to reintroduce enabled on the User on the client side. I don't believe this a view of a user that the client should be concerned about. It doesn't sound good to have two users that are otherwise equal but they have the enabled flag different. Are the users actually the same one or not? I would say they are, but something has changed on the server that makes the same user to behave differently at different time points; like changing his roles does not really alter the identity.

I think GetUsers should be returning two sets of users, the set of all users and the set of enabled users.

[nknize]

@albertzaharovits awesome.. thx for the feedback. I'll remove the enabled flag from user.

Can you clarify one thing for me? If we don't want the client to be concerned about enabled, then why would we return all users and enabled users? Wouldn't we just want to return either all users (if a username is not specified) or the requested user?

[tvernum]

I think GetUsers should be returning two sets of users, the set of all users and the set of enabled users.

I think that creates a strange API for clients that just want to iterate across all users (they'd have to loop twice, or we'd have to do some fancy merging of Iterables).

I feel it would be a nicer API to just add a isEnabled(User user) (or (String principal)) method to the response object, and have a Map or Set backing that.

[albertzaharovits]

If we don't want the client to be concerned about enabled, then why would we return all users and enabled users? Wouldn't we just want to return either all users (if a username is not specified) or the requested user?

What I meant was that the current enabled status is not part of the user's identity. We still want the client to be able to check it, preferably without another round trip to the server so it should be exposed in the GetUsersResponse.

I think that creates a strange API for clients that just want to iterate across all users (they'd have to loop twice, or we'd have to do some fancy merging of Iterables).

I was thinking of the following client experience:

for (User user : response.getUsers()) {
  if (response.getEnabledUsers().contains(user)) {
    // do smth with enabled user
  } else {
    // do smth with disabled user
  }
}

The enabled check might as well be response.isEnabled(User user), as Tim suggested, IMO both are about the same.

[nknize]

I guess the main question I have here is: how do I know if a user is enabled or disabled if I do not add the enabled variable to the User class? It looks like only AuthenticateResponse and PutUserRequest have the enabled variable.

[nknize]

@albertzaharovits @tvernum I removed the enabled flag from the User. I also moved the User parser to the GetUserResponse class and added an enabledUsers set. Is this closer to what y'all were thinking?

[albertzaharovits]

I removed the enabled flag from the User. I also moved the User parser to the GetUserResponse class and added an enabledUsers set. Is this closer to what y'all were thinking?

Looks good, thank you!
I will take another look when you're ready for merge.

[nknize]

retest this please

[nknize]

This is probably okay to merge. The failures look unrelated to this change. Will keep trying to reach a passing CI result.

[jkakavas]

00:08:42 Tests with failures:
00:08:42   - org.elasticsearch.client.SecurityRequestConvertersTests.testGetUsers

I left a suggestion inline for

00:08:40 FAILURE 0.02s J7 | SecurityRequestConvertersTests.testGetUsers <<< FAILURES!
00:08:40    > Throwable #1: org.junit.ComparisonFailure: expected:</[]_security/user/test> but was:</[/]_security/user/test>

The org.elasticsearch.xpack.security.transport.netty4.SimpleSecurityNetty4ServerTransportTests.testHandshakeWithIncompatVersion seems unrelated.

[albertzaharovits]

If you'd be so kind I would like a test in SecurityIT as well, but it's up to you.
LGTM besides the lack of documentation

[javanna]

This is labelled 6.6.0 but it has not been backported to 6.x. Just a reminder to backport #36622 once this is backported.