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:
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 org.apache.cxf.rs.security.jose.jws.JwsCompactConsumer
WARNING: Compact JWS does not have 3 parts
This is what we are using for the saml block in config.yml:
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.
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.
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.
Header
{
“typ”: “JWT”,
“alg”: “HS256”
}
Payload
{
“jti”: “0d5afc90-3818-4c9c-be6e-deba360756a2”,
“iat”: 1577091849,
“exp”: 1577095449
}
So can you show me the contents of your /etc/elasticsearch/log4j2.properties 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.