Supplying settings for custom realm while creating TransportClient

Elastic Stack Elasticsearch
1

Hello everyone,
I have a custom realm implemented and installed as an extension with X-Pack. Now I need to query ES via java api. I am using below code to create TransportClient

TransportClient client = new PreBuiltXPackTransportClient(Settings.builder()
	        .put("cluster.name", CLUSTER_NAME)
	        .put("xpack.security.authc.realms.custom.type","custom")
	        .put("xpack.security.authc.realms.realm.order", "0")
	        .build())

However this is not working as the setting xpack.security.authc.realms.custom.type and xpack.security.authc.realms.realm.order are not known to ES and thus it throws exception. How the TransportClient can be created accepting custom setting ?

2

There is no need to configure the above in a client, that only needs to be configured on the server side, as the transport client is not doing any realm auth.

3

Hi @spinscale,
I removed the xpack.security properties from the client creation but now I am getting another error. In custom realm, we are expecting user to send two headers namely Tenant and AccessToken
which will validate the user based on the token . To do this , sample code is shown below :

TransportClient client = new PreBuiltXPackTransportClient(Settings.builder()
		        .put("cluster.name", CLUSTER_NAME)
		        .build())
		.addTransportAddress(new InetSocketTransportAddress(InetAddress.getByName(IP_ADD), 9300));
Map<String, String> headersMap = new HashMap<String, String>();
		headersMap.put(USER, queryuser);
		headersMap.put(ACCESS_TOKEN, token);
		client.filterWithHeader(headersMap);

I am getting following error on hitting the request:

Caused by: org.elasticsearch.ElasticsearchSecurityException: missing authentication token for action [cluster:monitor/nodes/liveness]
	at org.elasticsearch.xpack.security.support.Exceptions.authenticationError(Exceptions.java:39) ~[x-pack-api-5.4.1.jar:5.4.1]
	at org.elasticsearch.xpack.security.authc.DefaultAuthenticationFailureHandler.missingToken(DefaultAuthenticationFailureHandler.java:74) ~[x-pack-api-5.4.1.jar:5.4.1]
	at org.elasticsearch.example.realm.CustomAuthenticationFailureHandler.missingToken(CustomAuthenticationFailureHandler.java:74) ~[classes/:?]
	at org.elasticsearch.xpack.security.authc.AuthenticationService$AuditableTransportRequest.anonymousAccessDenied(AuthenticationService.java:513) ~[x-pack-api-5.4.1.jar:5.4.1]
	at org.elasticsearch.xpack.security.authc.AuthenticationService$Authenticator.lambda$handleNullToken$14(AuthenticationService.java:331) ~[x-pack-api-5.4.1.jar:5.4.1]
	at org.elasticsearch.xpack.security.authc.AuthenticationService$Authenticator$$Lambda$2265/1905907575.run(Unknown Source) ~[?:?]

Any idea regarding this and does xpack.security.user needs to be passed in the Settings built for the client ?

4

have you overwritten XPackExtension.getRestHeaders() in your plugin and added those two?

5

Yes I have added both the headers and the realm is working properly via http. Now I want to achieve the same thing via transportclient in Java.

6

@spinscale any idea what could be the issue as I am sending proper headers as well.

7

I was able to resolve the issue by making the below changes :

final String yaml = "/elasticsearch.yml";
		TransportClient client = null;
		Settings settings = null;
		settings = Settings.builder()
				.loadFromStream(yaml, getClass().getResourceAsStream(yaml))
				.put(ThreadContext.PREFIX + "." + USER, queryuser)
				.put(ThreadContext.PREFIX + "." + ACCESS_TOKEN, token)
				.build();
		client = new PreBuiltXPackTransportClient(settings)
				.addTransportAddress(new InetSocketTransportAddress(InetAddress
						.getByName(IP_ADD), 9300));

So instead of passing the headers using client.filterWithHeader , the headers are passed in the settings itself and this seem to work . However I am not sure as to why it is not working when we pass the token as header using client.filterWithHeader .

8

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