Limit authentication providers based on hostname

[jportner]

Original comment: elastic/elasticsearch#75557 (comment)

Describe the feature:

We can introduce a new optional hosts configuration property for authentication providers to limit what host(s) they can be used on. Example:

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 you access Kibana via "corp.com", you will see the global-basic and corp-saml auth providers in the login selector.
If you access Kibana via "cname-corp.com", you will see the global-basic and cname-corp-saml auth providers in the login selector.

This can also be applied to non-login-selector scenarios, such as IdP-initiated login where we loop through auth providers.

Describe a specific use case for the feature:

• Multitenancy: if you want to serve two or more different groups of users on one Kibana instance, you may not want all authentication providers to be displayed to all groups of users.
• Supporting multiple hostnames for the same IdP: The relatively recent introduction of user-customizable aliases in Cloud has interesting consequence that there are two ways to access a Kibana instance: with the custom alias, or with the deployment ID. To support single sign-on for both hostnames for the Elastic Cloud IdP, Kibana needs two separate auth providers. This would allow us to support both hostnames with a nice clean UX, only showing the user the appropriate auth provider.

[elasticmachine]

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

[mnewswanger]

Hey all, is there any estimated window of when we can support this in Kibana? We've recently rolled out LetsEncrypt based certificates for our cloud infrastructure, which puts this as the only blocker to getting our Elastic Cloud integrated SSO working.

[jportner]

Thanks for the ping, we'll move this into our list of items to discuss during our next grooming meeting

[legrego]

We'll want to discuss with the @elastic/kibana-core team to understand how this interacts with the server.publicBaseUrl setting. Does Kibana even support being accessed from different public URLs, or from a URL that doesn't match server.publicBaseUrl?

[jportner]

Good point!

It looks like this config setting was added to support Alerting: #85075
Josh mentioned this very same concern in a comment for the follow-on task to make a warning toast message: #45815 (comment)

Based on that issue's linked PR (#85344), the warning toast is only displayed if 1. the client is accessing Kibana with a non-localhost URL, and 2. server.publicBaseUrl is not configured.

It appears there are at least two consumers of server.publicBaseUrl, it's used for both Alerting and Sharing.

Accessing Kibana on different hosts is already technically possible today, but emailed alerts and shared URLs will only reflect the configured server.publicBaseUrl, which is not ideal.
So maybe we need to have better support for this in Core as well.

[legrego]

Accessing Kibana on different hosts is already technically possible today, but emailed alerts and shared URLs will only reflect the configured server.publicBaseUrl, which is not ideal.
So maybe we need to have better support for this in Core as well.

++ Agreed. Receiving an email notification with a link back to Kibana should allow you to login the way you expect to, whatever that happens to mean. If the notification is only capable of using server.publicBaseUrl to generate the URL, then this will inherently exclude some authentication mechanisms if we move forward with this as-is. We may decide that this is an acceptable trade-off in the short-term, but I want us to be explicit about what we are supporting vs. not supporting.

We can't control how other features adopt server.publicBaseUrl, and we also can't assume that other features will keep this one in mind when building on top of server.publicBaseUrl

[Elastic-Steve]

Following up while MikeN is out - is there anything you need from Cloud to decide on a path forward here? I'm working on roadmap timing for SSO support but recognize we're dependent on this issue first being implemented.

[jportner]

Following up while MikeN is out - is there anything you need from Cloud to decide on a path forward here?

I don't believe we need anything from Cloud, this sounds like an enhancement we want to implement.

I'm working on roadmap timing for SSO support but recognize we're dependent on this issue first being implemented.

We aren't planning on this in the next couple of weeks, but it is near the top of our backlog. Stay tuned!

[legrego]

Something else that comes to mind is the External URL service. I believe it assumes that there is only one canonical public URL, and that is the location that the browser currently has open. This should account for the fact that there may be multiple public URLs. Otherwise, it will incorrectly think that some links back into Kibana are external when they're in fact internal:

kibana/src/core/public/http/external_url_service.ts

Lines 58 to 68 in 14c0d35

	return function validateExternalUrl(next: string) {
	const base = new URL(location.href);
	const url = new URL(next, base);
	const isInternalURL =
	url.origin === base.origin &&
	(!serverBasePath || url.pathname.startsWith(`${serverBasePath}/`));
	if (isInternalURL) {
	return url;
	}

Naively, I think one way to solve this could be to allow multiple entries for server.publicBaseUrl, and then ensure that the configured auth provider hostnames match one of the server.publicBaseUrl entries.

[Elastic-Steve]

Hi Team - any updates here? Is there a decision on how the requisite URL configuration will be supported?

[jportner]

Hi Team - any updates here? Is there a decision on how the requisite URL configuration will be supported?

This work hasn't been prioritized yet and we haven't made any decisions on what exactly the implementation will be, but it's likely to align pretty closely with the issue description.

[alxchalkias]

Hello team, new Ingress team PM here. I was wondering if there are any updates on this w.r.t. getting it prioritized.

[legrego]

Hey @alxchalkias, welcome! Unfortunately this hasn't been prioritized yet.
We'll discuss prioritization of this issue next week, and report back. cc @arisonl

[erictung1999]

Seems like this feature is not yet implemented. I'm also looking for a way to show different IdPs based on hostname as we are currently having multitenancy setup where we have different groups of people will access the Kibana.

Since it's still not yet implemented, I might need to find a workaround, perhaps I can launch multiple instances of Kibana but with different kibana.yml configuration, particularly on the xpack.security.authc.providers setting.

[azasypkin]

perhaps I can launch multiple instances of Kibana but with different kibana.yml configuration, particularly on the xpack.security.authc.providers setting.

This can work as an interim solution, but it will be quite brittle since it's not what Kibana officially supports. If you go this route, you should make sure that all Kibana instances that are connected to the same cluster have exactly the same list of authentication providers, with exact same names (realm name, hint, icon, description and showInSelector can differ though - this would allow you to tweak login selector for every instance as you wish). Otherwise, Kibana instances will periodically invalidate sessions created by the providers they aren't aware of (based on the provider type and name only).

Moreover, you'll need to synchronize all data encryption keys and correctly configure server.publicBaseUrl for every instance.

[alxchalkias]

@arisonl @legrego any chance you can review the priority of this? I want to start planning the CP work on https://elasticco.atlassian.net/browse/CP-1190 and ideally have it done by the end of CY23.

[legrego]

I've opened #161379 to discuss the limitations around server.publicBaseUrl that we mentioned above. I would like to understand our options around #161379 before proceeding with this. I wouldn't want to solve this problem in isolation without at least understanding the broader problem around accessing Kibana via multiple public URLs.