Capabilities endpoint and authentication

[kobelb]

With the addition of the dedicated endpoint for determining the capabilities, there are a few oddities which we've uncovered which I missed in the initial PR review.

The first is something that @azasypkin brought up, which I've addressed in a rather rudimentary fashion already. When querying the capabilities endpoint, we weren't including the kbn-system-api header which security uses to determine whether or not it should extend the session of the end-user. This request happens immediately after the page-load, so the impact is super negligible, but we shouldn't be doing it.

The other part of this is we're hitting the capabilities endpoint from routes like /login, /logout and /logged_out. This is potentially problematic as @azasypkin is working on the Kerberos auth provider which could theoretically re-authenticate the user if this request is still made and the timing of the events is right. I've added the disableCapabilities injected var so that we can not do this request for these specific pages.

The part which isn't solved is what we should do when the capabilities endpoint returns a legitimate 401. With the way this is currently implemented, there are likely fatal errors that are going to happen because we commonly consume these with code like the following:

kibana/src/legacy/core_plugins/kibana/public/dashboard/dashboard_config.js

Line 25 in c2f4123

let hideWriteControls = !capabilities.get().dashboard.showWriteControls;

which because of:

kibana/src/core/public/application/capabilities/capabilities_service.tsx

Lines 96 to 104 in d4540b2

	if (res.status === 401) {
	return {
	availableApps: [],
	capabilities: deepFreeze({
	navLinks: {},
	management: {},
	catalogue: {},
	}),
	};

is going to throw a TypeError: Cannot read property 'showWriteControls' of undefined

We could potentially change capabilities.get to require a "key" which would handle this common retrieval scenario and return undefined when this occurs. Or, we could consider redirecting the user to the server root when we get a 401 when loading the capabilities. Or, perhaps there is something that I'm not thinking of.

[kobelb]

/cc @joshdover

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[legrego]

The part which isn't solved is what we should do when the capabilities endpoint returns a legitimate 401.

... we could consider redirecting the user to the server root when we get a 401 when loading the capabilities

This is my vote. IMO, it's undefined behavior when an application can't retrieve its own capabilities. We originally designed this to assume that your own capabilities would always be available, which IIRC is one of the reasons we had to introduce them into OSS to begin with.

If capabilities can't be retrieved, I feel like Kibana should be rendering an error page of sorts. Allowing applications to attempt to run without capabilities defined adds another level of complexity that developers shouldn't have to reason about. Even the server root (Kibana Home?) relies on these capabilities, so I'm not sure we should even be redirecting there.

[joshdover]

Now that the HTTP service (#35486) has been merged into the new platform, we could also go ahead and use that to make this fetch to populate the kbn-xsrf header.

If capabilities can't be retrieved, I feel like Kibana should be rendering an error page of sorts.

Big +1 to that. If this ever fails, something is wrong and the user is going to see some very strange issues in the UI.

[kobelb]

@joshdover and I briefly spoke about potential solutions for the last part of this PR today. Initially, I proposed allowing the capabilities endpoint to respond with a 302 which would be handled in the client-side code appropriately. However, Josh later brought to my attention that the security plugin in x-pack currently intercepts 401s and will redirect to the /logout page when they occur, which gives us the opportunity to clear the sessionStorage before forcing the logout itself: https://github.com/elastic/kibana/blob/master/x-pack/plugins/security/public/hacks/on_unauthorized_response.js#L27

We're going to instead replicate this "on unauthorized response" logic within the new platform to maintain parity with the current solution.

[kobelb]

@eliperelman will be adding the interceptors for us per #22594 (comment) which we can take advantage. Do you feel confident that we'll be able to get this change in for 7.2? Otherwise, we risk shipping a bug if we were to get a 401 from this capabilities call.

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[eliperelman]

@kobelb I currently have an local implementation of this completed, just waiting to land #36611.

[joshdover]

FYI you should be able to revert #36710 as your first commit in this PR to get the async way of loading capabilities back.

[kobelb]

Once we have the hooks in place to intercept requests/responses from the NP http service, I'll resurrect this PR.

[eliperelman]

The interception functionality is now in place.

[kobelb]

@joshdover I was hoping to change Security's on_unauthorized_response hack to also intercept requests from the NP's http service, to unblock us from moving the capabilities back. However, just importing { npSetup } from 'ui/new_platform'; within the existing hack, it's too late to intercept the requests which the NP capabilities service makes during start-up.

Last I heard, there isn't a way to use the NP plugins in x-pack, and I'm also not aware of how we'd emulate the "hacks" with the new platform. Do you happen to have any recommendations?

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[joshdover]

@joshdover I was hoping to change Security's on_unauthorized_response hack to also intercept requests from the NP's http service, to unblock us from moving the capabilities back. However, just importing { npSetup } from 'ui/new_platform'; within the existing hack, it's too late to intercept the requests which the NP capabilities service makes during start-up.

Last I heard, there isn't a way to use the NP plugins in x-pack, and I'm also not aware of how we'd emulate the "hacks" with the new platform. Do you happen to have any recommendations?

Correct, the Legacy Platform doesn't get a chance to execute any code before start begins. We'll have to hold off on this PR until NP x-pack plugins are supported, though work is about to resume on that 😄

The New Platform doesn't have "hacks" because all plugins are actually setup and started on every page. Only a single application UI is displayed at any time, but all plugins are invoked before any UI is displayed.

[joshdover]

@kobelb While X-Pack plugins are now possible, we're still waiting on licensing to be done before we can enable this.