OpenID Connect in Kibana Open Distro: too_many_redirects

Hi all.
We want to integrate OpendistroKibana with WSO2 as Identity Server.
When accessing, it redirects us to the WSo2 page to enter the credentials. We enter them correctly and the IS responds to the callback URL with the corresponding code parameter. However, in Kibana it redirects to the login page instead of requesting the token and ending the flow.
We have done a test with Azure as Identity Server and the same thing happens to us.
We have configured the Kibana / openDistro part as it appears in the official configuration, but it does not work correctly.
These are the settings:

config.yml: |-
type: “config”
config_version: 2
anonymous_auth_enabled: false
enabled: false
internalProxies: ‘|’ # regex pattern
description: “Authenticate via HTTP Basic against internal users database”
http_enabled: true
transport_enabled: true
order: 0
type: basic
challenge: false
type: internal
http_enabled: true
transport_enabled: true
order: 1
type: openid
challenge: false
subject_key: preferred_username
roles_key: roles
openid_connect_url: “[URL_well_known]”
type: noop

config: kibana
server.basePath: /kibana “0”
elasticsearch.hosts: https://opendistro-es-client-service:9200
elasticsearch.ssl.verificationMode: none
elasticsearch.username: kibanaserver
elasticsearch.password: kibanaserver
elasticsearch.requestHeadersWhitelist: [“securitytenant”,“Authorization”]
opendistro_security.multitenancy.enabled: true
opendistro_security.multitenancy.tenants.preferred: [“Private”, “Global”]
opendistro_security.readonly_mode.roles: [“kibana_read_only”] true
newsfeed.enabled: false
telemetry.optIn: false
telemetry.enabled: false
security.showInsecureClusterWarning: false
map.includeElasticMapsService: false
opendistro_security.auth.type: “openid”
opendistro_security.openid.connect_url: “[URL_well_known]”
opendistro_security.openid.client_id: “[client_id]”
opendistro_security.openid.client_secret: “[client_secret]”
opendistro_security.openid.scope: “openid”
opendistro_security.openid.base_redirect_url: “https://myKibana/kibana

Can anyone help us?
Thanks in advance

Moved to security category.

1 Like

@igonzalez what is the OpenDistro version?

The OpenDistro version is 7.10.2

I’ve noticed the following settings in kibana.yml

server.basePath: /kibana
opendistro_security.openid.base_redirect_url: “https://myKibana/kibana”

I assume you’re using haproxy in front of Kibana. Would you mind setting it like the below?

server.basePath: /kibana
opendistro_security.openid.base_redirect_url: “https://myKibana

Thanks Pablo.
We have tried it but the result is the same.
The Identity Server rediirect to:
Kibana does not complete OIDC flow and redirects back to IS

Have you tried to test OIDC without a proxy?
What is the redirect URL in your IdP?

I have the same problem and tried everything under the sun to no avail. I see that it redirects to the …/auth/openid/login and never recovers from that.

Hi @pablo
Without proxy it doesn’t work. The URL that is sent in the first step of the flow is not correct, so the subsequent redirection does not
The redirect URL in the Idp is: https: // myKibana / kibana / auth / openid / login

Hi @alphanero
That’s it. It always redirects to the IdP when it has already been authenticated and redirects with the corresponding code.
We have also tested with Azure as IdP and the result is the same :frowning:
I don’t know if there is someone for whom SSO based on the OIDC with Kibana / OpenDistro works …

on checking the security audit logs - it looks like opensearch-dashboards is not receiving a username that it expects and hence redirecting back to IDP and then eventually fails.

I think that OpenDistro-Kibana receives a request of the type https: // myKibana / kibana / auth / openid / login? Code = XXX & state = YYY that it must process: retrieve the code to then make a POST to the / token of the IS with the corresponding parameters so that it returns the JSON with the “id_token” that contains the user information.
But for some reason it doesn’t identify the url as the answer from the IS and it redirects back to the auth page starting the loop again

switch authenticator order :

  • openid authenticator must be in first place (order : 0)
  • basic authenticator must be in second place (order : 1)

Hi @vgiacomini
We have also tested it and the result is the same :frowning:

Weird… For me I got the “too_many_redirects” error was because basic authenticator was the first one in the authentication chain, reply from keycloak doesn’t contain properties awaited by basic authentication. To pass OIDC authentication first in the chain fixed this problem

FYI, I joined a copy of config.yml file for opensearch security and also opensearch-dashboard config file. This configuration works well for my authentication case with keycloak OIDC

Hope it will help you

Thank you, @vgiacomini
Unfortunately I have tried with the configuration you have sent and the same thing happens to me.
I now attach the configuration of our config.xml and the kibana.xml. Maybe something catches your attention and it is not correct.



Could you either use HTTP or HTTPS for IDP and Kibana? I had a redirect issue when authentication was switching between HTTP and HTTPS.

I see that @vgiacomini has IDP and Kibana HTTP URLs

Hello @pablo . We have started from scratch again and tested both HTTP and HTTPS.
The problem persists, however we see a warning in the Mozilla Firefox console:

I don’t know if it has to do with it but it seems like a cookie problem. Has something similar happened to anyone?

[OpenID Connect in Kibana Open Distro: too_many_redirects] - Facing same issue opensearch_security:
type: “openid”
connect_url: “xxxxxx.well-known/openid-configuration”
client_id: “xxx”
client_secret: “xxxxx”
scope: “openid”
enabled: true
- Private
- Global
- kibana_read_only
secure: true
- https://xxxxxhost:9200
verificationMode: none
username: “kibanaserver”
password: “kibanaserver”
- authorization
- securitytenant

Able to authenticate with user and pwd , but after that its throws too_many_directs…kindly help me on this issue please.