Authorization errors with custom Shield plugin

Elastic Stack Elasticsearch
1

Hello,

I'm writing an ElasticSearch Shield plugin in order to integrate with my organization's internal authorization systems but have unfortunately hit a problem.

For context, at the moment, there is no integration with any external services within the plugin, all I'm trying to do is hard code a username and a set of roles to get something simple working. Later on, I'll be amending the plugin to determine the list of roles from an external service.

The problem that I'm experiencing is that, when the plugin is installed, I get an ElastisearchSecurityException upon starting the cluster. This is prior to any interaction with the cluster from any clients.

I can't easily copy and paste over, but the message upon starting ES is:

i. I can see that code within my class "CustomRealm" is being invoked. This is the authenticate method which returns a User object. I'm returning a new User with the name "es_admin" and a set of roles including 'admin'.

ii. a WARN message then appears from the 'gateway' class telling me that recovery has failed.

I then get an ElasticsearchSecurityException[action [ internal:gateway/local/metadata] is unauthorirzed for user and cluster recovery fails.

So, I'm trying to inject in a static user and give it the admin role, which is defined in the roles file as having all privileges on all indexes in the cluster.

This is using ElasticSearch 2.3 with Shield installed. Happy to provide any other information that anyone needs.

2

Hey Russ,

I think you need to make sure that the incoming request has a token that your realm expects and is valid. Otherwise you might try to authenticate all requests including some internal ones and attach the wrong authentication to them, causing authorization to fail. Even admin users cannot execute internal requests.

-Jay

3

Hi Jay,

Thanks for your help. It turns out that I wasn't always returning null in all the circumstances that I should have been in the method that generates the token from the incoming HTTP/binary message, giving the internal users a token that they shouldn't have had.

Simple when I spotted it!