Rest Client - Any other authentication mechanism?

From the documentation, I see that a user in ES can be authenticated via Kerberos/PKI mechanisms (and others like LDAP/ActiveDirectory). Documentation also mentions that REST Client can only authenticate users with Basic Http Authentication based on User/Password as http is stateless and every request is authenticated. And this sounds reasonable to me.

I can imagine that PKI based authentication for REST API would not be easy (or performant), if every request needs to be authenticated. However, I did read about Watcher using PKI authentication on http client. Hence this doubt.

Also apache http client provides kerberos credentials out-of-the-box, so was wondering if REST API requests can be authenticated using kerberos. Although this also does not sound reasonable if every request will be authenticated by contacting kerberos server.

But I wanted to double check if there are alternative authentication mechanism for REST client.

Here is my use case: A database system would be indexing it's content into Elastichsearch Cluster using REST Client (HTTPS client). So the ES REST Client is a database system. The communication is over https and ES would be secured using Shield. We only care about authenticating one admin user which can index data.

The ES Cluster would belong to a customer and we do not control it as such, except giving steps to perform on ES side for configuring user credentials.

For this use case scenario, a Kerberos or PKI (more preferred) based authentication looks like a better choice as creating a User which sits in two separate systems creates problem of consistency in maintaining their credentials in two separate systems. (Password expiry,changes etc). PKI based authentication is the best possible solution for our use case.

To Summarize. the questions are:
Q1) Apache http-components allow Kerberos Credentials to pass in their http client. But, I assume ES REST API Requests intercepted by Shield will look for User/Password Basic authentication. Is this assumption correct?

Q2)Is there anyway Rest Client can send user credentials based on certificates using PKI realm in Shield? And Shield can somehow authenticate this kind of (http)REST Request without any kind of SSL handshake steps involved.

was wondering if REST API requests can be authenticated using kerberos

Elastic does not provide a Kerberos security realm for Shield or X-Pack Security.
If you wrote your own Kerberos realm, and provided the kerberos ticket in the HTTP headers, then it should work, but I don't imagine you want to write your own realm for this.

Is there anyway Rest Client can send user credentials based on certificates using PKI realm in Shield.

Yes, but ...

Which Rest Client are you using? The REST (http/s) API absolutely supports PKI authentication, so if your HTTP client provides the correct PKI certificates then everything should work.
But obviously that requires that the client you are using has the mechanisms you need to provide that certificate.

You mention Shield which implies you're using Elasticsearch 1.x or 2.x. Which version of Elasticsearch/Shield are you trying to set this up for?

1 Like

There is which might be adaptable.

1 Like

Hi Tim,
Thanks for your answer. I am using 2.x version of ES and Shield for prototyping a solution. I can try with 5.x and X-Pack if there is any benefit in using that for my case.

Good to know that I can call the REST APIs from an https client using PKI, if I can write a client which can provide corresponding authentication header.
I was hoping to work with available AuthScheme and CredentialsProvider available in apache's http-components and not implement a custom AuthScheme for certificates. But I will explore this path now.

I am also trying out the low level REST Client API given in ES 5.0. But this essentially works on apache's http client, so I am not expecting any new AuthScheme implementation in that.

Ok, I was able to get the PKI authentication working both with my http client and Curl call. Thanks.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.