Try to implement Transport client with SG

Jozsef_Basa · January 22, 2018, 2:43pm

Hi

We just are implementing Transport client with SG as https://floragunn.com/searchguard-elasicsearch-transport-clients/ suggests

It says to create a new auth domain

transport_auth_domain:
enabled: true
order: 2
http_authenticator:
authentication_backend:
type: internal

Some options are not set here, for example http_authenticator type challange.

I am wondering whether they have a default value?

internal and intern are interchangable?

Actually before reading the web page below I thought that I had to use type: clientcert

Thanks

jkressin · January 22, 2018, 2:52pm

Hi Jozsef,

users on transport layer are no different from users on REST layer, so Search Guard needs to have a way to validate the credentials. You can use any authentication domain in order to do that. In the example we don’t use any authentication on the REST layer, that’s why many settings for REST are missing. But as I said, you can use any authentication domain for both REST and transport layer auhentication.

If you do not add any Basic Authentication headers to your Transport client, means you just configure a TLS certificate, then the DN of this certificate is used as username and validated against the configured authentication domains.

If you add Basic Authentication headers (see “Basic Authentication headers on transport level” in this article: Security and Alerting for Elasticsearch and Kibana | Search Guard) then those credentials are used. This allows for different users and hence roles on transport level.

What use case are you trying to implement?

···

On Monday, January 22, 2018 at 3:43:33 PM UTC+1, JozsefB wrote:

Hi

We just are implementing Transport client with SG as https://floragunn.com/searchguard-elasicsearch-transport-clients/ suggests

It says to create a new auth domain

transport_auth_domain:
enabled: true
order: 2
http_authenticator:
authentication_backend:
type: internal

Some options are not set here, for example http_authenticator type challange.

I am wondering whether they have a default value?

internal and intern are interchangable?

Actually before reading the web page below I thought that I had to use type: clientcert

Thanks

Jozsef_Basa · January 22, 2018, 3:08pm

Hi,

We don’t want to implement the basic auth over transport

···

On Monday, January 22, 2018 at 3:43:33 PM UTC+1, JozsefB wrote:

Hi

We just are implementing Transport client with SG as https://floragunn.com/searchguard-elasicsearch-transport-clients/ suggests

It says to create a new auth domain

transport_auth_domain:
enabled: true
order: 2
http_authenticator:
authentication_backend:
type: internal

Some options are not set here, for example http_authenticator type challange.

I am wondering whether they have a default value?

internal and intern are interchangable?

Actually before reading the web page below I thought that I had to use type: clientcert

Thanks

Jozsef_Basa · January 22, 2018, 4:36pm

Hi Jochen

You were talking about REST layer. I am afraid I don’t understand you

Jozsef

···

On Monday, January 22, 2018 at 3:43:33 PM UTC+1, JozsefB wrote:

Hi

We just are implementing Transport client with SG as https://floragunn.com/searchguard-elasicsearch-transport-clients/ suggests

It says to create a new auth domain

transport_auth_domain:
enabled: true
order: 2
http_authenticator:
authentication_backend:
type: internal

Some options are not set here, for example http_authenticator type challange.

I am wondering whether they have a default value?

internal and intern are interchangable?

Actually before reading the web page below I thought that I had to use type: clientcert

Thanks

jkressin · January 22, 2018, 5:59pm

There are two ways to connect to ES. Either via the transport layer, for example by using a TransportClient. Or via the ES REST API, for example by using a browser or curl.

Search Guard supports full authentication and authorization on both layers, that’s why I was asking for your use case. The background is that you can use an authentication domain for both layers at the same time.

So from what I understand you want to connect to ES with a Transport client only, and also don’t need different users for that client. Hence, Basic Auth over transport is not relevant. In that case you can ignore all settings regarding HTTP, because you are not using it. So that should do it:

transport_auth_domain:
enabled: true
order: 2
authentication_backend:
type: internal

``

Yes, intern and internal is the same. It was just a typo, and we kept “intern” for backwards capability reasons.

···

On Monday, January 22, 2018 at 5:36:03 PM UTC+1, JozsefB wrote:

Hi Jochen

You were talking about REST layer. I am afraid I don’t understand you

Jozsef

On Monday, January 22, 2018 at 3:43:33 PM UTC+1, JozsefB wrote:

Hi

We just are implementing Transport client with SG as https://floragunn.com/searchguard-elasicsearch-transport-clients/ suggests

It says to create a new auth domain

transport_auth_domain:
enabled: true
order: 2
http_authenticator:
authentication_backend:
type: internal

Some options are not set here, for example http_authenticator type challange.

I am wondering whether they have a default value?

internal and intern are interchangable?

Actually before reading the web page below I thought that I had to use type: clientcert

Thanks

Jozsef_Basa · January 23, 2018, 6:05am

Hi Jochen

Sorry for taking your time, Even without reading the docs I should have known that transport layer has nothing to do with http_authenticator. http_authenticator is for http rest.

One more question regarding type of clientcert http_authenticator. In this case the auth backend type is noop. That means I don’t have to add the DN (CN) to the sg_internal_users.yml (as opposed to transport layer) and I don’t need to use -u with curl, because the cert will identify the user. Of course I have to define roles for the DN (CN).

Am I right?

Best Regads

Jozsef

···

On Monday, January 22, 2018 at 3:43:33 PM UTC+1, JozsefB wrote:

Hi

We just are implementing Transport client with SG as https://floragunn.com/searchguard-elasicsearch-transport-clients/ suggests

It says to create a new auth domain

transport_auth_domain:
enabled: true
order: 2
http_authenticator:
authentication_backend:
type: internal

Some options are not set here, for example http_authenticator type challange.

I am wondering whether they have a default value?

internal and intern are interchangable?

Actually before reading the web page below I thought that I had to use type: clientcert

Thanks

jkressin · January 25, 2018, 2:03pm

Yes, you’re basically right. The clientcert HTTP authenticator picks up an HTTP client certificate if present in the request. It then validates the certificate against the Root CA and intermediate CAs, if any. After that, the DN of the certificate is used to map the certificate / user to roles. So you need to configure a mapping for the DN in roles_mappings.yml.

If you use curl to send a HTTP client certificate, you don’t need the -u switch. This switch is for HTTP Basic Authentication, which does not apply here since you use certificate based authentication.

There’s one setting in elasticsearch.yml which controls how client TLS certificates are handled, namely “searchguard .ssl.http.clientauth_mode”. You can set it to OPTIONAL, REQUIRE or NONE, with OPTIONAL being the default. Just make sure you have not set this to NONE by chance, means, just leave the default setting.

Topic		Replies	Views
How to authenticate via a transport client certificate? Search Guard	2	381	May 27, 2017
TransportClient + ActiveDirectory, having some trouble Search Guard	3	418	August 1, 2017
Search Guard client configuration issue Search Guard	1	657	March 12, 2019
Issue when using the certificate's ADDRESSEMAIL field in a transport client. Search Guard	1	327	January 31, 2017
Using TransportClient with Search guard Search Guard	6	412	May 24, 2018

Try to implement Transport client with SG

Related topics