Kibana: Reset password link when on Cloud

[andrew-moldovan]

Describe the feature:
When running on Cloud, Kibana should offer a "reset password" link back to Cloud (the security tab of the deployment). At worst case (if we can't link back, we should show a set of instructions on where to access the reset button).

Describe a specific use case for the feature:
When coming from Cloud, users are given an autogenerated set of credentials that they might not know or have missed. We should give them the ability to reset that password from Cloud.

Challenges
Finding the right link.

In ESS we know the base url (cloud.elastic.co), but also need to know the deploymentId. In https://github.com/elastic/cloud/issues/53649#issuecomment-603814633 @nachogiljaldo mentions that the cloudId can be decoded to have the clusterId. This is good enough because we have a redirect (@bevacqua to confirm). So this data is already in Kibana, just the cloudId needs to be decoded on the frontend, not just in Beats (which I think is where it is decoded now). See https://github.com/elastic/kibana/blob/master/x-pack/plugins/cloud/server/plugin.ts#L44 for the code that has this.

In ECE we don't know the link (https://github.com/elastic/cloud/issues/54009). This is something that we're not likely to fix anytime soon since the first we could do it would be 2.6. So we'll need to plan for a world where ECE doesn't have this link. We can probably just show a tooltip in this case? Though I don't know if there's a way for Kibana to know about if it's running in ESS vs ECE.

@joshdover @legrego @cjcenizal I'm not sure who owns the Kibana login page, but this is something that would be awesome to add asap (since it shouldn't require much coding once we have a path). Also don't know what labels to add here.

Btw this is coming out of a product review where it was made obvious that this is a very simple thing we can do to hugely improve UX (which is very true).

/cc @gjones

[elasticmachine]

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

[andrew-moldovan]

Related to https://github.com/elastic/kibana/issues/19596, but this is for Cloud specifically

[cjcenizal]

@andrew-moldovan I confirmed with @legrego that the Security team will be responsible for helping you with this one (not ES UI).

[bevacqua]

In ESS we know the base url (cloud.elastic.co), but also need to know the deploymentId. In elastic/cloud#53649 (comment) @nachogiljaldo mentions that the cloudId can be decoded to have the clusterId. This is good enough because we have a redirect (@bevacqua to confirm)

We would need the regionId as well, we have a resolver route like this:

GET /deployments/resolve/kibana/:regionId/:kibanaId

It takes you to the Kibana for the deployment

[andrew-moldovan]

Sounds good @cjcenizal, in retrospect there's no reason why your team would handle this. @legrego thanks for taking this on!

So the cloudId is 64bit encoded and breaks out into <region_id>.<provider>.<cname>$<cluster_id>$<kibana_id>. Eg. us-east-1.aws.found.io$f0e7f777a2bb4a2cb42b142ef2f095ca$5a69c20b264a4b5dbbd71fa30bc0dca2

@bevacqua don't we have a resolver for cluster id specifically, since we said that people could have bookmarked the url before we migrated to deployments api? But I guess worst case we can use the kibana id since we do have that. But we want to drop them into the Security page.

So that means we should be able to detect if it's in ECE or not by checking to see the cname. If in ECE, I think we're going to have to just rely on some docs because we can't know the direct link of the console (see https://github.com/elastic/cloud/issues/54009).

Example cloudIds:
ESS:

eastus2.azure.elastic-cloud.com:9243$59ef636c6917463db140321484d63cfa$a8b109c08adc43279ef48f29af1a3911
us-east-1.aws.found.io$a2a21d1fe8c33036e62fa144f7760893$76498e5ec1298d14d47560955f1ef774
us-west-1.aws.found.io$21e7851922104b0f9715fb41114afc35$7d81e1320baa47a6bbcb16e7faaeb703
us-central1.gcp.cloud.es.io$3e83fc465b934d2582175dfffd9b34a6$bac3be47a4d34732bccba675d89e9eb3

ECE:

192.168.44.10.ip.es.io:9243$38ab00fbf02446a4b9ab2cebc58e7921$d721383b0de0488caa427d5871fa9493

192.168.44.10.ip.es.io is the cname in ECE, so it's a bit hard to know exactly how to differentiate between ESS and ECE. I guess look for the region/provider structure and if you don't find it, just assume it's ECE and show docs instead of a full link.

[bevacqua]

@bevacqua don't we have a resolver for cluster id specifically, since we said that people could have bookmarked the url before we migrated to deployments api? But I guess worst case we can use the kibana id since we do have that. But we want to drop them into the Security page.

Yes, I thought you were saying we have the Kibana ID, my bad. Yes, we have a ES Cluster ID resolver as well.
It's:

GET/deployments/resolve/cluster/:regionId/:esClusterId/**

Where /** will take you to any page on the deployment, e.g. /kibana will take you to the Kibana page of the deployment once resolved.

---

It still needs to know the regionId, FWIW

[andrew-moldovan]

Yep we have regionId as well

[azasypkin]

Thanks for filing this issue @andrew-moldovan !

to add asap (since it shouldn't require much coding once we have a path)

Let's discuss the broader questions we outlined here first https://github.com/elastic/kibana/issues/61144#issuecomment-606471717, make sure we are aligned and then we can see how much work is really needed.

//cc @arisonl

[azasypkin]

Okay, here is the excerpt from https://github.com/elastic/kibana/issues/61144 that's related to this issue:

The login form supports the following cases:

• When users should be able to log in with native or reserved realm.
  
  
  
  • Users can change/reset password with Kibana/Elasticsearch help in this realm
  
  
• When users should be able to log in with file, ldap or active_directory realm.
  
  
  
  • Users cannot change/reset password with Kibana/Elasticsearch help in this realm
  
  

There is no way currently for Kibana to know whether user can change password or not __before__ they log in and there are just 2 out of 5 realms for which it would actually make sense. If we decide to add Change Password Link then obviously we'll need to support two scenarios, with and without this link, to not make experience worse/confusing for the existing "non-native" Kibana users.

So assuming we have a strong reason to not use login assistance message to cover Forgot password? link scenario, I see at least two cases that Kibana will have to support:

1. If Kibana is run in non-Cloud context, Kibana Admin can configure the following optional setting in kibana.yml: xpack.security.authc.providers.basic|token.<provider-name>.forgotPasswordLink

2. If Kibana is run in Cloud context, then same solution can be used here (Cloud will have to add a bunch of other Kibana config entries to support Cloud SAML by default anyway, right?).

If the solution in 2. is a no-go for some reason then we'll have to introduce dependency between Security and Cloud plugins. Either Security will have to introduce an optional dependency on Cloud that in its turn would expose this link through the setup/start contract based on whatever conditions Cloud thinks make sense. Or Cloud will introduce dependency to Security and will use some API exposed by the Security to set that Forgot password? link.

Neither dependency feels ideal from the architectural standpoint. Also I'm not sure how I feel about the fact that we handle Cloud scenario differently and need to test it separately assuming that it's a temporary stop gap solution until Cloud can manage users on its own and hence allow them to use SSO instead (please correct me if my assumption is wrong).

Am I missing or over-complicating anything here? What do you think?

[legrego]

Reminder to folks collaborating on this issue: we're in a public repository, so we should refrain from linking to private issues, so that we aren't leaving dead links all over the place.

---

I agree with @azasypkin's assessment above. Whatever solution we come up with for cloud needs to also work as a first-class experience for Kibana off-cloud, and introducing a dependency between the security and cloud plugins for this scenario feels less than ideal.

[andrew-moldovan]

My apologies, I'm used to being in the Cloud repo.

---

Ok I talked to some folks on the Cloud side and we should be able to make use of the Login Assistance Message. Is the correct yaml setting xpack.security.loginAssistanceMessage?

Let's go with this option for now as it's the simplest and can revisit if others disagree. Once we get confirmation on the exact yaml setting, we can close this issue as there isn't any Kibana work required.

[kobelb]

Has the xpack.security.loginAssistanceMessage been white-listed as a setting users can configure in Cloud? If it hasn't, taking advantage of it in the short-term makes sense.

Since it was already determined that the login assistance message doesn't satisfy https://github.com/elastic/kibana/issues/18176, perhaps we're alright with not allowing end-users to ever configure this long-term in Cloud. It does seem somewhat limiting though.

[peterschretlen]

What would happen for a native realm user who is not elastic- how does the password reset link help in this case? Or does this only apply to the elastic user. Sorry if this has already been covered, just trying to understand how the various flows might work.

[andrew-moldovan]

It does not help the native realm user, only someone coming from Cloud with elastic user. We'd have to make that clear in the messaging we used.

@kobelb it looks like it has been whitelisted actually (to my surprise). I'd still say it makes sense to use because this is a best effort and if we determine the user already has this set, we should just not do anything for that Kibana

[kobelb]

FWIW, there's potential that I was wrong when I stated the following:

Since it was already determined that the login assistance message doesn't satisfy #18176, perhaps we're alright with not allowing end-users to ever configure this long-term in Cloud. It does seem somewhat limiting though.

I believe that @arisonl is currently trying to determine whether or not we need an explicit acknowledgement, and how that would affect the use of the logic assistance.