Kibana SAML integration issue

[Indisol]

Hello Experts,

While trying to enable SAML authentication for Kibana 6.2, i am getting an error in the elasticsearch logs

[WARN ][o.e.x.s.a.AuthenticationService] [nfvn304-1] Authentication to realm saml1 failed - Provided SAML response is not valid for realm saml/saml1 (Caused by ElasticsearchSecurityException[SAML response zXOgCxQAuXSqVMZI6Ick7Yv_KFA is for destination null but this realm uses https://nfvn304-1:5605/api/security/v1/saml])"

#SAML authentication configuration
xpack.security.authc.realms.saml1:
type: saml
order: 1
idp.metadata.path: saml/idp-metadata.xml
idp.entity_id: "https://vm00000617.nopl.com"
sp.entity_id: "https://nfvn304-1:5605/"
sp.acs: "https://nfvn304-1:5605/api/security/v1/saml"
sp.logout: "https://nfvn304-1:5605/logout"
attributes.principal: "nameid:persistent"

I have installed the security certificate also from the SAML response XML. some how i feel its related to encryption.
thanks in advance

[TimV (Tim Vernum)]

It looks like your Identity Provider is sending an invalid SAML response.
Can you tell us which IdP you are using?

[Indisol]

thanks for the response Tim, we are using PingFederate.
The IDP response is signed with *.p12 certificate.

we have extracted the certificate from xml, stored in the server as .p12.
And imported this certicate(.p12) in our elastic Keystore.
we have made the following change also in the elasticsearch.yml file
encryption.keystore.path
encryption.keystore.alias
encryption.keystore.secure_password

Is there some thing/step that i am missing here.

Regards,
indi

[ikakavas (Ioannis Kakavas)]

Hi Indi.

The issue at hand is that Ping Federate doesn't set the Destination element in the SAML Response it sends, and the Elastic Stack SAML implementation attempts to match it to the Assertion Consuming Service endpoint of the SP, which fails.

SAML response zXOgCxQAuXSqVMZI6Ick7Yv_KFA is for destination null but this realm uses https://nfvn304-1:5605/api/security/v1/saml])

According to the SAML 2 specification, If the SAML Response is not signed (only the Assertion it contains is), it's not mandatory that the Destination element is included and this is what Ping Federate does. **

We have identified this behavior as a potential point where our SAML implementation is stricter than it should be and harming interoperability so we addressed it in this PR . The changes will be available in one of our future releases.

In the meantime, assuming my interpretation of your setup is correct, one way to temporarily fix this issue is to configure Ping Federate to sign the SAML Responses (instead of just the SAML Assertions). Please consult your PingFederation configuration on how to do this, this seems to suggest that you need to uncheck the "Always sign the SAML Assertion" option in your configuration

** If you have configured Ping Federate to sign responses ( this is apparently the default configuration ) and it still doesn't set the Destination element, then this is something that Ping needs to fix.

[Indisol]

Hi Loannis,

thanks for your suggestion. post unchecking the "Always sign the SAML Assertion"option, SAML log-in is happening successfully.

regards,
Indi

[ikakavas (Ioannis Kakavas)]

@ikakavas

We have identified this behavior as a potential point where our SAML implementation is stricter than it should be and harming interoperability so we addressed it in this PR . The changes will be available in one of our future releases.

@Indisol , for completeness, the aforementioned fix is now included in 6.3.1 ( see Release notes ), so that means that there will not be any interoperability issues now if you revert your configuration back to signing SAML Assertions.