I'm implementing SAML for elasticsearch cluster. After hitting kibana url I get redirected to IDP saml page for login but after login I get below error in browser -
< {"statusCode":401,"error":"Unauthorized","message":"[security_exception] unable to authenticate user [<unauthenticated-saml-user>] for action [cluster:admin/xpack/security/saml/authenticate], with { header={ WWW-Authenticate="Basic realm=\"security\" charset=\"UTF-8\"" } } :: {"path":"/_xpack/security/saml/authenticate","query":{},"body":"{\"ids\":[\"_d263c43dea4fa7997bddfa0eaf6fbbdb7ed11011\"]>
Seeing below error in elasticsearch.yml file:-
<[2019-04-12T09:57:43,977][WARN ][o.a.x.s.s.XMLSignature ] Signature verification failed.
[2019-04-12T09:57:43,997][WARN ][o.e.x.s.a.AuthenticationService] [es-coordinating] Authentication to realm saml1 failed - Provided SAML response is not valid for realm saml/saml1 (Caused by ElasticsearchSecurityException[SAML assertion [U8eyywQktnmBPxDobRY/fZisgzoe62kh...] is encrypted, but no decryption key is available])>
NOTE- I have confirmed that ( sp.entity_id ) match with what has been configured as the SAML Service Provider Entity ID in the SAML Identity Provider documentation
You can, but we discourage it. The signing & encryption certificates for SAML are unrelated to your server identity for network services (TLS), and it is not usually a good idea to mix them.
It will work, but you're better off just generating a new certificate.
You do, but your IdP team already thinks you have a certificate, so you should probably ask them about that before you go any further.
SAML assertion [U8eyywQktnmBPxDobRY/fZisgzoe62kh...] is encrypted,
but no decryption key is available
If you are getting this error, then the IdP thinks it is supposed to send you encrypted assertions, and is encrypting them using some sort of certificate that it got from somewhere.
That could be a mistake from your IdP team - maybe they just copied the config from another service and forgot to remove the encryption certificate. Maybe they generated a new certificate for you, but didn't give you a copy.
It would be advisable for you to talk to them about this before you try and fix it from your side.
yes the IDP is using some certificate to encrypt responses. So I should provide them my own crt.pem and ask them to use the same. Just one question, I should provide crt.pem of es-coordinating or kibana ?
The question is why? and can they just turn it off.
You might have a local policy to always encrypt assertions, but the circumstances under which this is truly necessary are pretty rare. So for simplicity's sake, I would suggest you simply disable encryption (on the IdP) if you have that option.
No, as mentioned above, we recommend that you generate a new certificate specifically for SAML encryption and/or signing. The documentation that @ikakavas linked to (above) walks you through that process.
They don't need a copy of your TLS certificates, they just need your SAML encryption certificate (the encryption.certificate setting from your realm).
Alternatively, If your IdP can import SAML metadata, then you can simply generate a metadata file using the elasticsearch-saml-metadata tool, and pass that to your IdP team.
Hi TimV,
This worked after IDP disabled encryption from there end. As of now this is in UAT so disabling encryption is fine but once I move to production, is it mandatory to enable encryption from IDP end ? Any harm to Elasticsearch security if we keep encryption disabled ?
Not sure about any local policy to encrypt assertions
Elasticsearch will not impose any requirements on the encryption of SAML Assertions. For most of the cases, the necessary confidentiality property which is provided by TLS (over which the SAML Assertion is sent, via https ) is enough. If the IDP, or a local security policy dictates the use of encrypted SAML Assertions, Elasticsearch can consume them if correctly configured.
Not sure what you mean by "it had routed me to kibana UI" but there is no way your SAML user would have access to any indices or the kibana UI (you need the kibana_user role) unless you have explicitly granted them the role.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.