[security-in-core] Expose userProfile APIs from Core

[pgayvallet]

Part of #174578

This issue is about migrating the userProfile APIs to re-expose them from Core, similar to what was done to authc in #177976

• We want to expose them from their dedicated service (so core.userProfile and not core.security.userProfile)

• The public API doesn't need to change, we can re-expose them exactly the same

• The internal API will need to expose all the APIs for Core to use

  • update is not exposed on the server-side as a public API

• There is a package about UI components for user profile, but we don't need to do anything about it

• (Optional) Given we have only few consumers of the userProfiles APIs, we could even adapt the existing consumers to use the new Core APIs and then simply remove them from the security plugin’s contract (if the effort is reasonable)

Tech pointers

Server-side:

kibana/x-pack/packages/security/plugin_types_server/src/plugin.ts

Lines 44 to 47 in f7fa846

	/**
	* User profiles services to retrieve user profiles.
	*/
	userProfiles: UserProfileServiceStart;

Browser-side:

kibana/x-pack/packages/security/plugin_types_public/src/plugin.ts

Lines 33 to 36 in f7fa846

	/**
	* A set of methods to work with Kibana user profiles.
	*/
	userProfiles: UserProfileAPIClient;

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[elasticmachine]

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

[pgayvallet]

We want to expose them from their dedicated service (so core.userProfile and not core.security.userProfile)

This is the only point we need to figure out. In my initial PR I assumed we would be registering all of security's API from a single registration hook

kibana/packages/core/security/core-security-server/src/contracts.ts

Lines 17 to 24 in b816af4

	export interface SecurityServiceSetup {
	/**
	* Register the security implementation that then will be used and re-exposed by Core.
	*
	* @remark this should **exclusively** be used by the security plugin.
	*/
	registerSecurityApi(api: CoreSecurityContract): void;
	}

kibana/packages/core/security/core-security-server/src/api_provider.ts

Lines 11 to 19 in b816af4

	/**
	* The contract exposed by the security provider for Core to
	* consume and re-expose via its security service.
	*
	* @public
	*/
	export interface CoreSecurityContract {
	authc: AuthenticationServiceContract;
	}

But this also assumed everything was exposed from the same service.

If we want this core.userProfile service, we need to figure out how the registration should be performed.

If we want to keep the registration being done with a single hook (and I think we do), then it means a few things:

• the userProfile service will depend on the security service (as it will need to retrieve the registered APIs from it)
• there is something to figure out regarding the type packages
  • as the CoreSecurityContract types from the @kbn/core-security-server and @kbn/core-security-browser will need to know about the userProfile contract

The alternative would be to have a distinct registerUserProfile registration API exposed from our new userProfile service. This will allow to have the types fully isolated. But the downside is that we need to redo all the boilerplate that was done in the previous PR for this new service.

[TinaHeiligers]

As discussed, I tentatively assigned myself to take this work on. We can change that if needed later.

[pgayvallet]

We discussed it with @TinaHeiligers today, and came to the agreement that adding a dedicated registration hook for the userProfile API was the best solution, long term.