Support SAML authentication for applications multiple URLs (hostname aliases)

[tvernum]

Note: I will write about "Kibana" because that is our primary SAML application, however everything written below applies to other applications as well.

Currently each SAML realm supports a single ACS with a single hostname. If Kibana is available on multiple URLs (most often multiple DNS entries pointing to the same hosts) then it is not currently possible to configure a single SAML realm that can service both of those URLs.

It is possible to configure multiple SAML realms, but then the issue is that we don't have a good process to select which realm to use to authenticate - We can list 2 realms on the Kibana login selector, but the explanatory text would need to try and explain "Use this option if your browser address bar says xyz.host" which is clearly not reasonable.

One option (though there are others would be)

1. Allow a single SAML realm to be configured with "alternate hosts". This could look something like:

   xpack.security.authc.realms.saml.corp_sso:
      sp.entity_id: "https://my.kibana.host/"
      sp.acs: "https://my.kibana.host/api/security/saml/callback"
      idp.metadata.path: saml/idp-metadata.xml
      idp.entity_id: "https://sso.example.com/"
      alternate_hosts: [ "other.kibana.host" ]
   

2. Allow Kibana to pass through a hostname on applicable SAML APIs, and if that is an alternate host use it in place of the hostname in the ACS or logout URL.
3. Likewise when validating SAML messages from the IdP, accept any "alternate_host" in place of the primary host.

That option would assume that the IdP allows multiple ACS URLs for the same entity id.

We could support different EntityIDs per alternate host, if we think that is needed, for example:

xpack.security.authc.realms.saml.corp_sso:
   sp.entity_id: "https://my.kibana.host/"
   sp.acs: "https://my.kibana.host/api/security/saml/callback"
   idp.metadata.path: saml/idp-metadata.xml
   idp.entity_id: "https://sso.example.com/"
   alternatives: 
      - host: other.kibana.host
         entity_id: "https://other.kibana.host/" 

An alternative option would be to force Kibana to redirect to a canonical URL as part of the SAML flow. One way to do that would be for the SAML prepare authc API to return a "hostname" (taken from the ACS URL) and if Kibana is not using that hostname, then it redirects to that host before setting the SAML cookie and bouncing the user to the IdP.

[elasticmachine]

Pinging @elastic/es-security (Team:Security)

[tvernum]

CC: @elastic/kibana-security

[azasypkin]

It is possible to configure multiple SAML realms, but then the issue is that we don't have a good process to select which realm to use to authenticate - We can list 2 realms on the Kibana login selector, but the explanatory text would need to try and explain "Use this option if your browser address bar says xyz.host" which is clearly not reasonable.

If I'm not missing anything, we can also try to handle this purely in Kibana (assuming only supporting Kibana is enough). For example, we can introduce a new optional host configuration property for SAML provider (or for all providers):

xpack.security.authc.providers:
  basic.global-basic:
    order: 0
  saml.corp-saml:
    order: 1
    realm: main-saml
    host: "corp.com"
  saml.cname-corp-saml:
    order: 2
    realm: cname-saml-cname
    host: "cname-corp.com"

• If Login Selector is enabled, it will only display providers with the matching host or without it ("global" options)
• If Login Selector is not enabled, Kibana still does an additional redirect to a special client-side page that captures current URL fragment before preparing SAML request. We can also capture the current host there (or we can just rely on the Host HTTP header?) and then pick the right SAML provider/realm to prepare a SAML request
• During IdP initiated login Kibana already loops through SAML providers (and hence SAML realms) sorted by order until it finds the one that can handle SAML response

We'll still need to think what to do when Kibana is configured with a specific server.publicBaseUrl and users will have a bit more involved configuration on both ES and Kibana ends, but everything else sounds doable.

[jportner]

If I'm not missing anything, we can also try to handle this purely in Kibana (assuming only supporting Kibana is enough). For example, we can introduce a new optional host configuration property for SAML provider (or for all providers):

I like this approach. It would double as a feature that some customers have asked for (to reduce confusion for their users who don't know what provider to pick).

I opened an issue for it in elastic/kibana#109525 if you want to add anything to it.