Kibana Client side headers and not getting forwarded to Elasticsearch!

Elastic Stack Elasticsearch
1

We are implementing Custom Realm in Kibana 5.6 and we are using a Siteminder login page and bypassing the Kibana login page. We are seeing the Kibana client side headers in Kibana logs. However, the ThreadContext in Elasticsearch doesn't contain any headers.

Can someone please help me in this!

2

Have you tried setting the following in your kibana.yml?

elasticsearch.requestHeadersWhitelist: [ header_you_want_to_forward ]

3

Yes, I did.

elasticsearch.requestHeadersWhitelist: [ es-security-runas-user, Authorization, authorization, sm_user, user_id, host, source ]

As soon as I login to Siteminder, I keep getting the below message in ES logs

[2017-11-07T22:11:11,470][WARN ][o.e.x.s.a.AuthenticationService] [AMA_MONITOR] An error occurred while attempting to authenticate [elastic] against realm [reserved] - ElasticsearchSecurityException[failed to authenticate user [elastic]]
[2017-11-07T22:11:11,670][WARN ][o.e.x.s.a.AuthenticationService] [AMA_MONITOR] An error occurred while attempting to authenticate [elastic] against realm [reserved] - ElasticsearchSecurityException[failed to authenticate user [elastic]]

4

Are you trying to authenticate as the built-in elastic user or one that you've created?

5

sm_user is the header that Siteminder responds and we wanted to read its value ( as whomsoever logged in user ) into ES and Custom Realm

6

From what you've posted, it sounds like you have a custom realm that is handling the sm_user header, and are trying to use that to log in as the elastic user.

Is that an accurate summary?

If so, then that won't work. A custom realm is not able to authenticate reserved users such as "elastic". Those users are authenticated exclusively by the reserved realm, they will not be delegated to any other realms down the authc chain.

if you need to be able to login through Siteminder as a superuser, then it will need to be a new custom user that is handled by your realm. You can simply assign the superuser role to your user and it will have the same privileges as elastic does.

7

Yes, I am able to create a new custom user and also able to handle the roles mapping in my Custom Realm.
The thing is we do not want the Kibana login page, instead we want Kibana to be protected by Siteminder. We achieved it by setting up reverse proxy using IBM HTTP Server; and we are hardcoding it with a custom user.

But by doing so we were able to bypass the kibana login page but the no headers are being sent from Kibana to ES and Custom Realm; and thereby ThreadContext is just returning an empty map.

Note: If we remove the reverse proxy, the ThreadContext is populating the map with sm_user, but in this case, we are getting Kibana login page as well (which we do not want it and want it to bypass).

8

I'm having trouble following exactly what parts are causing which issue. Please try to be as precise with your information as you can be, and provide direct answers to the questions people ask.

@lukas suggested using elasticsearch.requestHeadersWhitelist

You responded showing a log message:

[2017-11-07T22:11:11,470][WARN ][o.e.x.s.a.AuthenticationService] [AMA_MONITOR] An error occurred while attempting to authenticate [elastic] against realm [reserved] - ElasticsearchSecurityException[failed to authenticate user [elastic]]

But that error shows that you're trying to log in as elastic. That won't work.
If you are seeing that error, then you are trying to do something that will never work.

If you are have troubles when you try to login as your custom user, then please show the errors for that user.

We achieved it by setting up reverse proxy using IBM HTTP Server;

Is this separate to SiteMinder?
So you have

  • SiteMinder in front, generating a sm_user header
  • going to the IBM reverse proxy, which is adding a "custom user"
  • then it goes to Kibana
  • and Kibana goes to Elasticsearch ?

That's a lot of moving parts. If you want to debug this you'll need to be thorough at checking that each component is doing what you think it's doing.

and we are hardcoding it with a custom user.

What exactly does this mean? You are adding an Authorization header? Or something else?

If we remove the reverse proxy, the ThreadContext is populating the map with sm_user

That makes it sound like the reverse proxy is removing the sm_user header. Why do you think this is a Kibana problem?

9

We sorted out the issue!

It was the config entry in the kibana.yml, for elasticsearch.requestHeadersWhitelist. When we tried user impersonation we required authorization header. But in our case we just need sm_user. Since we have both authorization and sm_user in the list, the authorization bypassed rest of the headers.

Now we removed the authorization from the list, and having only sm_user, we see the sm_user is getting passed to ThreadContext.

10

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