App permissions with action patterns do not retrieve privileges

[albertzaharovits]

In order for file realm users, with application privileges, to continue
to work (authenticate) when the .security index is unavailable,
Security must avoid loading the application privileges from the .security index
(which is unavailable, hence error out).
Roles (defined inside the roles.yml file, not in the index) that must work
when the .security index is unavailable must use inlined action patterns
for application permisions, rather than privilege names.

Related #85312

[elasticmachine]

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

[justincr-elastic]

I would need more information to be able to complete a review, but I did have a feedback point.

[justincr-elastic]

I found it confusing to have a method called validateActionName which does validation on action name, but then also calls through to validatePrivilegeOrActionName.

[albertzaharovits]

Do you also have proposals to improve it?
Also keeping in mind this is a bug-fix PR.
I only slightly changed code in this part to make sure the action names I generate IN TESTS are valid.

[albertzaharovits]

This PR fixes the bug from #85312 by making any file-based role that contains application permissions that do not refer to named application privileges (which only mention inlined action patterns, like the superuser role does) not unnecessarily query the .security index. By avoiding querying the index, such roles can be used even when the index is unavailable.

Another option to fix the same bug would be to always return the statically built superuser role, after failing to resolve a role name list that includes it. We do something like that today, when failing to retrieve any role descriptors, but not when failing to retrieve privileges referred in those role descriptors.

I think both approaches have pros-cons, but I don't think we have to choose between them.
I think it is perfectly reasonable for file-based roles to not reach the index if they don't need to, but if they do, and fail, we should not fail the authentication if the user also has superuser.

---

EDIT:

The above has been partly discussed over Slack, and the other option has been suggested by @tvernum .

[elasticsearchmachine]

Hi @albertzaharovits, I've created a changelog YAML for you.

[tvernum]

Hey @albertzaharovits - this approach looks like a good direction to me.
Are you still looking for a review?

[justincr-elastic]

LGTM

[elasticsearchmachine]

Hi @albertzaharovits, I've updated the changelog YAML for you.

[albertzaharovits]

Hey @albertzaharovits - this approach looks like a good direction to me.
Are you still looking for a review?

Yes, please review. I have adapted the PR description and label to reflect that this is now >enhancement rather than a >bug fix after you have merged #85519 .

[tvernum]

Given this is now an enhancement, I don't think we should backport to 7.17

[tvernum]

LGTM

[albertzaharovits]

@elasticmachine update branch