do not warn when switching capabilities for resources with optional auth

[mshustov]

Summary

You can see a warning in logs when landing on /login page:

{"type":"log","@timestamp":"2020-03-23T19:17:47+00:00","tags":["warning","plugins","spaces"],"pid":18348,"message":"Error toggling capabilities for request to /api/core/capabilities: [security_exception] missing authentication credentials for REST request [/_security/user/_has_privileges], with  ....

AFAIK It doesn't break any logic.
I'm not sure what it the right solution for this use case if we need to get capabilities for a resource with 'optional' auth. Any other plugin can use the Security plugin API to verify that a user is authenticated, but Spaces & Security cannot call each other due to circular dependencies.

UPDATED: based on a conversation with @legrego: it's expected behavior, and we should downgrade log level to avoid confusion.

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

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

[legrego]

LGTM, thanks for the fix! This check is consistent with what the security plugin does in its switcher today

edit: looking at failing test..

[legrego]

We may have to check if security is enabled before bailing here. Luckily (?), Spaces declares an optional dependency on security, so we can check if security is enabled, and if it is an authenticated request

[mshustov]

@legrego our tests verify another behavior.

kibana/x-pack/test/ui_capabilities/spaces_only/tests/catalogue.ts

Line 25 in d66b3c7

const expected = mapValues(uiCapabilities.value!.catalogue, () => true);

Seems that it doesn't rely on security plugin availability.

[legrego]

Our goal here is to skip toggling capabilities if we don't have credentials, but would otherwise need them in order to perform the capabilities check. We used to silently fail in the past, but we made this more explicit in #57693 (comment).

So we need to figure out a way to determine if credentials are required in order to toggle capabilities. Prior to #58589, we had two distinct routes to retrieve capabilities: one which required auth, and another which didn't. This made the check easy for us here, but it's no longer sufficient now that we have a single route with optional auth.

When security is disabled, then I believe request.auth.isAuthenticated will always be false, but in this case, we will still want to attempt to toggle capabilities.

When security is enabled, then we only want to attempt to toggle capabilities when request.auth.isAuthenticated is true

[mshustov]

When security is disabled, then I believe request.auth.isAuthenticated will always be false, but in this case, we will still want to attempt to toggle capabilities.

It sounds like you want to know AuthState, which is available via auth api
And you need to retrieve capabilities for authenticated & unknown statuses. Is it right? Moreover, Spaces plugin will log the same warning. Then the current PR can wait or we even can keep the current behavior from the master.

[legrego]

When security is disabled, then I believe request.auth.isAuthenticated will always be false, but in this case, we will still want to attempt to toggle capabilities.

It sounds like you want to know AuthState, which is available via auth api
And you need to retrieve capabilities for authenticated & unknown statuses. Is it right? Moreover, Spaces plugin will log the same warning.

Yes, that sounds correct to me

Then the current PR can wait or we even can keep the current behavior from the master.

Perhaps it'd be worthwhile to reduce this message from warn to debug then, if this is a message we're going to expect in certain conditions. I don't want to pollute the logs unnecessarily.

[kibanamachine]

💚 Build Succeeded

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

History

• 💔 Build #35729 failed 9fe92e1

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[liza-mae]

Thanks for setting up a PR to fix, I was seeing this message on master and 7.x -- when I would login or logout.

I am seeing this error in the logs when I login or out of Kibana, is it expected or is it an issue?
{"type":"log","@timestamp":"2020-03-23T19:17:47+00:00","tags":["warning","plugins","spaces"],"pid":18348,"message":"Error toggling capabilities for request to /api/core/capabilities: [security_exception] missing authentication credentials for REST request [/_security/user/_has_privileges], with { header={ WWW-Authenticate={ 0="ApiKey" & 1="Basic realm=\"security\" charset=\"UTF-8\"" } } } :: {"path":"/_security/user/_has_privileges","query":{},"body":"{\"applications\":[{\"application\":\"kibana-.kibana\",\"resources\":[\"space:default\"],\"privileges\":[\"version:8.0.0-SNAPSHOT\",\"login:\"]}]}","statusCode":401,"response":"{\"error\":{\"root_cause\":[{\"type\":\"security_exception\",\"reason\":\"missing authentication credentials for REST request [/_security/user/_has_privileges]\",\"header\":{\"WWW-Authenticate\":[\"ApiKey\",\"Basic realm=\\\"security\\\" charset=\\\"UTF-8\\\"\"]}}],\"type\":\"security_exception\",\"reason\":\"missing authentication credentials for REST request [/_security/user/_has_privileges]\",\"header\":{\"WWW-Authenticate\":[\"ApiKey\",\"Basic realm=\\\"security\\\" charset=\\\"UTF-8\\\"\"]}},\"status\":401}","wwwAuthenticateDirective":"ApiKey, Basic realm=\"security\" charset=\"UTF-8\""}"}

[mshustov]

@liza-mae yes, as stated in the PR title:

UPDATED: based on a conversation with @legrego: it's expected behavior, and we should downgrade log level to avoid confusion.

[liza-mae]

Thanks @restrry !