Try to implement Transport client with SG

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

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: https://floragunn.com/transport-client-authentication-authorization/) 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

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

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

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

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

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.

See also:

“Advanced: Client authentication”

···

On Tuesday, January 23, 2018 at 7:05:46 AM UTC+1, JozsefB wrote:

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