Kibana uses the configuration set for xpack.security.public in order to construct the Assertion Consumer Service URL that it subsequently passes in a request to Elasticsearch. Elasticsearch uses this ACS URL in order to match the SAML realm that the SAML Authentication request is for.
For example, given the following configuration:
xpack.security.public:
protocol: https
hostname: kibana.proxy.com
port: 443
Kibana would construct and pass to Elasticsearch an ACS URL that is https://kibana.proxy.com:443/api/security/v1/saml .
The matching for the realm in Elasticsearch is performed as a string comparison(as it should), and even if the default port number is superfluous as part of the URL, it matters when matching the sp.acs configuration parameter in the SAML Realm configuration.
The other manifestation of this problem is that users have the expectation that given the aforementioned config, they can then set the ACS configuration value in their SAML IdP and in the Elasticsearch SAML Realm config to https://kibana.proxy.com/api/security/v1/saml and it would work.
In practice, what happens is that the HTTP part of the communication works, as the request reaches Kibana correctly, but Kibana still constructs the ACS URL to be https://kibana.proxy.com:443/api/v1/saml (from the configuration) and forwards that to Elasticsearch which fails to match the saml realm because https://kibana.proxy.com:443/api/security/v1/saml is different than https://kibana.proxy.com/api/security/v1/saml
The summary of the above, is that when xpack.security.public is used, for a working configuration a user needs to set the ACS URL to https://kibana.proxy.com:443/api/security/v1/saml in both the IDP and the SAML Realm configuration and the part where the :443 is required is troubling end users.
We could look into not adding the default port for the protocol when building the ACS URL from configuration. The tricky part is to do it in a backwards compatible way, as if we change this in a following version it would break existing configurations. It could be that we only need to call this out in the documentation explicitly.
Kibana uses the configuration set for
xpack.security.publicin order to construct the Assertion Consumer Service URL that it subsequently passes in a request to Elasticsearch. Elasticsearch uses this ACS URL in order to match the SAML realm that the SAML Authentication request is for.For example, given the following configuration:
Kibana would construct and pass to Elasticsearch an ACS URL that is
https://kibana.proxy.com:443/api/security/v1/saml.The matching for the realm in Elasticsearch is performed as a string comparison(as it should), and even if the default port number is superfluous as part of the URL, it matters when matching the
sp.acsconfiguration parameter in the SAML Realm configuration.The other manifestation of this problem is that users have the expectation that given the aforementioned config, they can then set the ACS configuration value in their SAML IdP and in the Elasticsearch SAML Realm config to
https://kibana.proxy.com/api/security/v1/samland it would work.In practice, what happens is that the HTTP part of the communication works, as the request reaches Kibana correctly, but Kibana still constructs the ACS URL to be
https://kibana.proxy.com:443/api/v1/saml(from the configuration) and forwards that to Elasticsearch which fails to match the saml realm becausehttps://kibana.proxy.com:443/api/security/v1/samlis different thanhttps://kibana.proxy.com/api/security/v1/samlThe summary of the above, is that when
xpack.security.publicis used, for a working configuration a user needs to set the ACS URL tohttps://kibana.proxy.com:443/api/security/v1/samlin both the IDP and the SAML Realm configuration and the part where the:443is required is troubling end users.We could look into not adding the default port for the protocol when building the ACS URL from configuration. The tricky part is to do it in a backwards compatible way, as if we change this in a following version it would break existing configurations. It could be that we only need to call this out in the documentation explicitly.