SAML Authentication not working for Kibana

The SAML integration with OKTA doesn’t seem to be working. I keep getting redirected to customerror?type=samlConfigError#?_g=() or to this /customerror?type=samlAuthError#?_g=().

I have enabled debug log in the elasticsearch machine but the request doesn’t seem to reach the es machine.

The kibana is running on a different server and the kibana_url added in the OKTA app is being proxy passed through a nginx machine.

Here is the opendistro_security/securityconfig/config.yml file:

       enabled: true
       order: 1
         type: saml
         challenge: true
             metadata_file: metadata.xml
             entity_id: kibana-saml
           roles_key: 'Roles'
           kibana_url: https://kibana-node-1:5601
           exchange_key: 'asd4nlksanflkanl3k2nlknlk'
         type: noop

In the kibana.yml I have added these two blocks as well.

opendistro_security.auth.type: "saml"

server.xsrf.whitelist: ["/_opendistro/_security/saml/acs", "/_opendistro/_security/saml/logout"]

Nothing in the logs is helpful, the request do go till the kibana machine but nothing after that.

Update: I enabled debug log on the elasticsearch machine and now I am getting these logs:

' INVALID_COMPACT_JWS' extracting credentials from saml http authenticator
	at ~[opendistro_security_advanced_modules-]

Any help would be really appreciated!


We are also using Okta. We have it working, with the exception of getting continually flooded with JWS errors. (Although maybe these are coming from our Lets Encrypt certs?)

Dec 14, 2019 3:12:30 AM
WARNING: Compact JWS does not have 3 parts

This is what we are using for the saml block in config.yml:

    http_enabled: true
    transport_enabled: false
    order: 1
      type: saml
      challenge: true
          metadata_file: metadata.xml
          entity_id: okta-entity
        kibana_url: https://url/
        roles_key: roles
        exchange_key: '(key)'

… based upon and .

Hello guys,

Can you please provide more log details? Try add logging.verbose: true to kibana.yml

This is not a error, it’s just a warning. For okta SAML integration read this article, it’s ver useful and easy to understand, give me some feedback later pls.

Hello Anant,

Can you show me your configurations for enabling debug log in elasticsearch.
I am struggling to get OpenID Connect successfully authenticate on OD Kibana 1.3.0.

I keep getting redirected to /customerror?type=authError#?_g=() in Kibana but nothing regarding JWT shows up in elasticsearch logs /var/log/elasticsearch/.log.

I followed the documentation at and added the following to /etc/elasticsearch/ to no affect as there is no additional debug information telling me how the node is processing the JWT token from my Keycloak IdP. =
logger.opendistro_security.level = trace

and for good measure I added this as well =
logger.token.level = trace

Donno what i am doing wrong, but its impossible to diagnose the OpenID Connect Keycloak/elasticsearch negotiation without seeing a debug trace. When I decode the keycloak Browser JWT send to Kibana from Keycloak, i get the following. But unable to know if this is enough data to process authentication.
“typ”: “JWT”,
“alg”: “HS256”
“jti”: “0d5afc90-3818-4c9c-be6e-deba360756a2”,
“iat”: 1577091849,
“exp”: 1577095449

So can you show me the contents of your /etc/elasticsearch/ please?
Hopefully that will help illuminate why elasticsearch is failing to process the JWT Token response.

Oh, I got Okta working thanks to that article and a lot of playing, since the article has some markup issues (at least in my browser on Firefox) and points to another article without any sort of real pointer as to where to start in that other article.

But the JWS warning is pretty destructive; it spams the logs at least once every 20 seconds and there doesn’t seem to be any sort of real pointer as to what the warning actually means. I’ve seen other mentions that it is the exchange_key not being a multiple of 32 characters, but mine is so I’m not sure what the real problem might be. At this point, I’ve set up a curator job to just nuke the security-auditlog on a fairly regular basis so it doesn’t trash my disk space.