Send 401 Unauthorized with WWW-Authenticate: Basic header to enable HTTP authentication via URL

[morganchristiansson]

We want to display authenticated Kibana dashboards on TV monitors that cycle through URLs to display various dashboards and data.
We've considered a number of different approaches to enable authentication and settled on passing credentials in URL like this: https://user:[email protected]/.

Now this doesn't work because the webserver needs to send HTTP/1.1 401 Unauthorized with WWW-Authenticate: Basic header or the browser won't send its Authorization header.

From reviewing the shield plugin source code I've discovered that Shield accepts credentials via Authorization: header but it's not possible to trigger a 401 Unauthorized with WWW-Authenticate header to make the browser send it.

As such we've implemented a workaround where nginx will respond to requests without Authorization: header:

map $remote_user $realm {
    '' 'Kibana with Shield';
    default off;
}

server {
    ....

    location /shield/ {
        auth_basic $realm;
        auth_basic_user_file /dev/null;

        rewrite              ^/shield/(.*) /$1 break;
        proxy_pass           http://localhost:5602;
        ....
    }
}

This enables authorization with HTTP auth and Kibana will parse the Authorization header correctly and grant access.

It would be great if Kibana with Shield could send this response could be made to return 401 Unauthorized with WWW-Authenticate: Basic header instead of rendering the current ajax based login screen.

[morganchristiansson]

Also due to phishing security this approach doesn't work in several browsers, the browser will display a warning or error to alert the user about potential phishing alerts. Some of the browsers can be configured to allow it. See http://kb.mozillazine.org/Network.http.phishy-userpass-length

As such alternative methods of authentication may be needed for other users. For example sending credentials or authentication token through URL parameters would work universally regardless of browser.

For us the Samsung SmartTV builtin browser supports credentials in URL and Firefox can be configured to support it by changing the network.http.phishy-userpass-length setting.

[Bargs]

@morganchristiansson The Kibana security plugin supports sessions with cookies. What's the disadvantage to logging in via the login form, and relying on the existing session functionality in the Security plugin? Session timeout is configurable if that's the issue: https://www.elastic.co/guide/en/shield/2.3/kibana.html#shield-ui-settings

From reviewing the shield plugin source code I've discovered that Shield accepts credentials via Authorization: header but it's not possible to trigger a 401 Unauthorized with WWW-Authenticate header to make the browser send it.

I don't think we'll ever support credentials passed via the URL. Support for the authorization header mainly exists for programmatic access. In the future, I imagine we'll implement some sort of token based system for API access.

[gmoskovicz]

@Bargs if using ngnix proxy and sending the headers, shouldn't Kibana just pass this headers to Elasticsearch and then authenticate the user?

[Bargs]

Headers will work, but putting credentials in the URL will not.

[morganchristiansson]

It's needed to display graphs and dashboards on tv monitors around the office. It is not possible to interactively login on them, so url authentication is needed

[Bargs]

@lukasolson any thoughts on this? Do we have any alternative that might be helpful?

[lukasolson]

The simple solution for this case is to disable the shield Kibana plugin. If you're not using the login/logout capabilities, it shouldn't be of much use anyway. And if you disable the plugin, it should fall back to basic auth. Let me know if that helps!

[gmoskovicz]

For this, i guess that it is needed a secondary Kibana instance pointing to the same Elasticsearch cluster. I think that one doesn't want to remove the plugin in the main Kibana instance that people will be logging, right?

[morganchristiansson]

@gmoskovicz Yeah that solution would be fine. However we already have secondary instance, so this would be tertiary instance. And managing multiple instances is a bit of a hassle.

We now need 3 kibana instances:

• no-shield login, anonymous access (we want public access within the company)
• shield authenticated access (we want to allow authenticated access)
• no-shield, authenticated access (for TV monitors we want to allow public pre-authenticated access)

If configuring multiple Kibana profiles/backend connections from a single instance (like the Marvel plugin supports multiple clusters) then that might work for us.

[lukasolson]

@Bargs From my understanding, passing the credentials in the url as @morganchristiansson suggested will result in them being passed as basic auth headers in most (if not all) browsers.

[Bargs]

@lukasolson In the OP @morganchristiansson said this:

We've considered a number of different approaches to enable authentication and settled on passing credentials in URL like this: https://user:[email protected]/.

Now this doesn't work because the webserver needs to send HTTP/1.1 401 Unauthorized with WWW-Authenticate: Basic header or the browser won't send it's Authorization header.

I'm guess this is because we're redirecting to the login page? @morganchristiansson can you confirm that's what's happening? Also, what browser are you using?

[morganchristiansson]

There's nowhere in the kibana or shield code where a HTTP/1.1 401 Unauthorized response with a WWW-Authenticate: Basic header is sent, so most/all browsers will refuse to send the Authorization: Basic xxx header with the provided credentials.

If an Authorization header is sent, kibana&shield parses and recognizes it correctly. So my nginx hack to send HTTP/1.1 401 Unauthorized response with a WWW-Authenticate: Basic header when no Authorization header is sent by the browser enabled the browser to attempt authentication with the Authorization: Basic xxx header.

[morganchristiansson]

A simple solution would be a new login URL.

https://kibana.app/shield/login**-http-auth**?next=%2Fapp%2Fkibana#/disc....

This would then respond with 401 response and WWW-Authenticate header and allow login.

[epixa]

I'm going to close this because current versions of X-Pack security should handle basic auth by default. Feel free to drop a comment here if the issue is still present.