Migrate Capabilities to new platform

[pgayvallet]

Summary

Fix #45393

Migrates Capabilities feature to new platform

• Introduce the core server-side CapabilitiesService
• Migrate the capabilities provider/modifiers logic from capabilities_mixin to this service
• Capabilities are now accessed from client using an http call performed during platform start phase instead of using the injectedMetadatas
• Adapt security and spaces plugins to use the NP api instead of the legacy one
• Adapt tests, mainly x-pack/test/ui_capabilities

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

- [ ] This was checked for cross-browser compatibility, including a check against IE11
- [ ] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support

• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
  - [ ] This was checked for keyboard-only and screenreader accessibility

For maintainers

- [ ] This was checked for breaking API changes and was labeled appropriately
- [ ] This includes a feature addition or change that requires a release note and was labeled appropriately

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 26a9cdd4afe1c5e4d07bad3a199c686c883235d2

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request
• Commit: a5106595cd8172ccc0503aced3274eb6edadc4ca

[pgayvallet]

I'm having issues with the security capabilities modifiers when switching passing capabilities from the server to client from injectedMetadata to an http call.

My issue is quite simple: As the platform setup is executed on every pages, without distinctions between authenticated routes and non-authenticated routes, I need the endpoint to be accessible in both cases.

I started by naively disabling authentication from the route (authRequired: false,). However, I learned that way that when doing this, authentication is totally disabled, meaning that these routes are in a forced-anon mode. The consequences for the capabilities endpoint is that it returns all capabilities disabled, even when the user is effectively 'logged in'.

kibana/x-pack/plugins/security/server/authorization/index.ts

Lines 115 to 120 in ad356f5

	// if we're an anonymous route, we disable all ui capabilities
	if (request.route.options.authRequired === false) {
	return disableUICapabilities.all(capabilities);
	}
	return await disableUICapabilities.usingPrivileges(capabilities);

The only workaround I currently have is to declare two endpoints with the same handler, but one with authRequired set to true, and the second one set to false. Then, from the frontend, I will call the secured endpoint, and if it returns a 401, call the second one. This is as bad as it sounds.

After speaking with @restrry about the try HAPI auth mode, he directed me to #41959, which is closed for being superseeded by #50634

ping @elastic/kibana-security: I would like you opinion on changing

if (request.route.options.authRequired === false) {
        return disableUICapabilities.all(capabilities);
      }

By something like

if (!Authenticator.authenticate(request).succeeded()) {
        return disableUICapabilities.all(capabilities);
      }

From what I see in the code, the Authenticator#authenticate method is not exposed in setupAuthentication (x-pack/plugins/security/server/authentication/index.ts). is this something that is acceptable to change? What is your opinion on this?

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: cd19e2e5e59c8e2fbcafb4a0fd8762a0f2580692

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: a20df2a

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 7cb5513

[jportner]

Two comments on this:

1. The status page may require authentication unless the status.allowAnonymous setting is used
2. I already added a NP status_page plugin in Improve session idle timeout, add session lifespan #49855 (recently merged, probably after you started working on this PR), see plugin.ts, so this code is redundant now :)

TL;DR I believe you can remove this line now!

[pgayvallet]

if (isStatusPageAnonymous) {
      core.http.anonymousPaths.register('/status');
    }

This is indeed better. Thanks a lot, will remove

[jportner]

Please remove the anonymous route change from the Security plugin, and this LGTM!

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: c4e313f

[kobelb]

@pgayvallet do you envision #51956 removing the necessity to use the /defaults route? Or should this be handled separately?

[pgayvallet]

@kobelb This mostly depends on the security team's answer to #51438 (comment). If the proposal is acceptable to your team, I'll gladly add this point to #51956 yes

[kobelb]

@pgayvallet I overlooked that question, apologies.

From what I see in the code, the Authenticator#authenticate method is not exposed in setupAuthentication (x-pack/plugins/security/server/authentication/index.ts). is this something that is acceptable to change? What is your opinion on this?

Sure, exposing this and using it seems reasonable to me. #50634 (comment) is planning on doing so as well.

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 4cee19c