Custom authentication with Kibana + Shield


(Curtis) #1

I have a custom Shield plugin working with Elasticsearch that authenticates using a SAML token passed in the HTTP header. I want this authentication scheme work with Kibana as well. Kibana should deny access when the authentication fails and restrict access to Elasticsearch indices as appropriate.

Is it possible to configure Kibana to pass the HTTP header contents through to Elasticsearch for authentication? One use case is Kibana users will use a login page that populates the SAML token in the HTTP header then redirects them to Kibana. Kibana should then pass the HTTP Authentication information through to the Elasticsearch + Shield + Custom Realm Plugin on each call.

Another option might be upgrading to Kibana 4.4 to get the login screen then modify it using a plugin to authenticated using the SAML token?

Any suggestions would be appreciated
Thanks
Curtis


(Spencer Alger) #2

There isn't any way to configure Kibana to do this today, but it's definitely possible if you want to write a plugin or tweak the source.


(Curtis) #3

Thanks. Would prefer writing a plugin. Would that be a plugin to Shield installed with Kibana or something else? Any sample code or docs available?


(Spencer Alger) #4

Most of the core functionality in Kibana is implemented as plugins, so you can treat them as "sample code". They are available here: https://github.com/elastic/kibana/tree/master/src/plugins

Since the Kibana server sends elasticsearch the headers of each request, you probably just need to add an "onRequest" extension to the hapi server so that you can inject headers into each request.

example from the hapi docs:

server.ext('onRequest', function (request, reply) {

    // Change all requests to '/test'
    request.setUrl('/test');
    return reply.continue();
});

(Steve Kearns) #5

@spalger , does the Kibana backend forward all headers to ES from incoming requests? If it does, in theory, this should almost "just work" right?

For example, if the client browser has a SSO plugin thingy that adds a custom SAML header to the HTTP requests the browser makes to the Kibana backend, does the Kibana backend attach that header in the request it makes to ES?

If it works as described above (and there are several ways it might not), this would probably only be an 80% solution (no functioning logout button, etc), but it would allow the SSO AuthZ/N to work as expected without showing a login screen of any kind.


(Marcel Matus) #6

@nielsoncr - did you succeeded in your effort to have kibana 4.x working with your SAML realm? I am in the same situation now. There is one option, to upgrade to 5.2+, where custom headers are configurable. But that won't happen anytime soon, and I need to support SAML 2 ASAP on our ES v2.3 version (kibana 4.5.3).

Tnx


(Curtis) #7

Our solution ended up being writing a thin proxy installed in front of Kibana that performed automatic redirect to a login page for authentication. SAML information was included in the authorization header which was passed on to the Kibana instance running on the same server connecting to localhost. (i.e. accessing Kibana from an external connection without getting a SAML token from the proxy is prevented)

We wrote a shield custom realm plugin and installed it in Elasticsearch which performed further authentication/authorization on the search requests made by Kibana. This solution works, but IMO clumsy and isn’t making for an easy upgrade to 5.3.x.

[cid:image003.png@01D27AE2.AAB80570]
Curtis Nielson | Software Architect
3M Health Information Systems Div
3M Silver Spring, 12215 Plum Orchard Drive | Silver Spring, MD 20904
Office: 301 281 8352 Mobile: 301 675 3573
cnielson@mmm.commailto:cnielson@mmm.com | www.3M.comhttp://www.3m.com/

The information contained in this message and any attachments is intended only for the use of the individual or entity to which it is addressed, and may contain information that is PRIVILEGED, CONFIDENTIAL, and exempt from disclosure under applicable law. If you have received this message in error, you are prohibited from copying, distributing, or using the information. Please contact the sender immediately by return e-mail and delete the original message from your system.


(system) #8