Kibana: Login page layout improvements

[ryankeairns]

Potential follow-on work based upon: https://github.com/elastic/kibana/pull/53010

---

Following are a few design and UX considerations, by way of the Cloud design team, that would also better align our login pages.

• Place the form first
• Change 'OR' to 'or login with' as it reduces redundancy of button text
• Consider using smaller buttons

Re-order

Re-order + smaller buttons

cc:/ @cristina-eleonora

[elasticmachine]

Pinging @elastic/kibana-core-ui (Team:Core UI)

[myasonik]

I know we're not super far in our internationalization efforts, but having every button on each line will be easier to work with across a variety of languages (unless you're ok with the button widths not lining up nicely with the form width)

[ryankeairns]

+1 I had mentioned to Cristina in a Slack chat the button size change felt least certain for making the cut. She noted her own reservations when sharing these screenshots.

[cristina-eleonora]

I'm also in favor of the first one, due to the same concerns.

[azasypkin]

Thanks for the unification effort in this area! Just wanted to mention few other things that we'd need to consider:

• login assistance message (markdown, applies to both login form and selector buttons)
• info message (plain text, applies to both login form and selector buttons)
• error message (plain text, applies only to login form, mutually exclusive with info message _right now_)

See screenshots below:

• login assistance message (By logging in to this application you accept:\n* [The Corporate Terms of Use](..)\n* [Privacy Terms](...)) + info message (You have logged out of Kibana.):

• login assistance message (By logging in to this application you accept:\n* [The Corporate Terms of Use](..)\n* [Privacy Terms](...)) + error message (Invalid username or password. Please try again.):
  

• [bonus] form in "in progress" mode (e.g when we clicked on the Log in with Elastic Cloud button):

• [bonus] form in with error toast (e.g when Log in with Elastic Cloud failed. But when login through login form fails we display error message shown above instead):

[cristina-eleonora]

In cloud, we put the Terms of Service and Privacy Terms at the bottom. We only use ir for the signup page.

Perhaps the structure for could be similar:

• Kibana login
• SSO /SAML login
• ToU + Privacy Terms

This is how we handle login errors:

[azasypkin]

In cloud, we put the Terms of Service and Privacy Terms at the bottom. We only use ir for the signup page.

ToS was just an example, Kibana login assistance message can contain literally anything that markdown can handle: from simple maintenance notification to any sort of pre-login warnings that are configured by the Kibana admin through kibana.yml.

[ryankeairns]

One more thing to add to the Kibana login page:

• A reset password link that (as I understand it) would only appear for Cloud users and directs them to the appropriate security page within the Cloud UI for their current deployment. https://github.com/elastic/kibana/issues/61808
• Eventually, there would also be a reset password link for basic non-Cloud Kibana users as well. https://github.com/elastic/kibana/issues/19596

[elasticmachine]

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

[ryankeairns]

I've labeled this with Team:Security, but the Core UI team can assist with the design. I'll start with some mockups that capture the above suggested changes + the feedback from Shay today.

Regarding the latter, there is some clarification needed to differentiate between the SAML and Basic form actions. This may benefit from some layout changes but, most importantly, some text to help explain what is going on.

The particular use case that stood out to me is:

1. I have a cloud cluster and now I'd like to add some people to my Kibana deployment.
2. I create a new user in Kibana > Management > Users and send them a link to the Kibana log in.
3. They open the link and it should be clear that they need to use the basic form (presuming they don't/won't have a Cloud log in).

As it stands, it's not clear which log in mechanism to use - click the SAML button or submit the form. It may also come as a bit of a surprise that the former will redirect you to the Cloud log in which, upon logging in, routes you back to Kibana.

[ryankeairns]

@alexfrancoeur @AlonaNadler Is there any input from the Kibana PM side for these log in page changes? Wanting to loop you in, just in case.

[azasypkin]

but the Core UI team can assist with the design. I'll start with some mockups that capture the above suggested changes + the feedback from Shay today.

Thank you! Maybe let's take a step back a bit first and outline all the scenarios we _have to_ keep in mind before we spend time on mocking and implementing anything in code. After a product review it became obvious that not everyone realizes what cases are possible, how complex they can be and basically how everything can work together. Please bear with me.

Terminology

__Login Selector__ - the screen you see when you go to Kibana's /login route

__Login Form__ - is a part of __Login Selector__ that includes username and password text fields and Log In button.

__Login Selector Entries__ - needs a better name, are representing part of the __Login Selector__ that provides _alternative_ means of login. Think of something like Log in with Google Account or Log in with Facebook that you see all over the place now.

__Login Assistance Message__ - is a part of __Login Selector__ that can display helpful content in markdown (links, emphasis etc.) and is configured by Kibana Admin (hence by Cloud as well).

__Login Info Message__ - is a part of __Login Selector__ that can display basic plain text and __is solely reserved__ for a set of predefined messages (e.g. notify user about the reason of logout)

First of all, the Login Selector appearance is mainly dictated by the configuration provided by the Kibana Admin in kibana.yml. At this stage we don't try to guess too much about the configuration Kibana deployment has and give the necessary primitives to configure experience to the customer needs instead, based on what we knew so far.

Login form

This 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.

In 7.7+ or 7.8+ we can potentially allow Kibana admin to set Change Password Link via xpack.security.authc.providers.basic|token.<provider-name>.changePasswordLink or something like this if they want users to see it. @elastic/kibana-security any objections/ideas here?

__Question for Cloud:__ @legrego brought a good point yesterday, we have a Login Assistance Message support since 7.6.0. @andrew-moldovan @jowiho Any reason you couldn't use it to display Change Password Link-like stuff within this message? Yes, UX wouldn't be ideal, but it could potentially solve the issue Cloud users are struggling with right away.

Login Selector Entries

From the __user perspective__ we can split the types of flow that Login Selector Entries can trigger into two different categories:

Flows that involve 3rd-party (SAML and OpenID Connect)

These flows require external Identity Provider (Auth0, Okta or brand new Cloud IdP fwiw) to authenticate the user __before__ it can log in to Kibana. And hence users will have to be redirected back and forth.

That's a usual flow you see literally everywhere these days when you log in with Google or Okta. I'm still not entirely getting where the confusion around Log in with Elastic Cloud is coming from when Kibana Admin configured _multiple_ authentication mechanisms.

Flows that don't involve 3rd-party (Kerberos and PKI)

These flows don't require additional user involvement, when users click on these buttons they will immediately log in to Kibana assuming their "credentials" are valid.

In some sense this flow is very similar to the Login Form flow, but instead of username and password that user used to enter manually, browser will automatically provide its client certificate or a special TGT token that Kibana will use to log user in.

Login Selector

As you may have already guessed, Login Selector will either display Login Form, or Login Selector Entries, or both. Kibana can also display Login Assistance Message if needed. Everything is determined by the configuration Kibana Admin would like to have.

---

Regarding the latter, there is some clarification needed to differentiate between the SAML and Basic form actions. This may benefit from some layout changes but, most importantly, some text to help explain what is going on.

Yeah, I agree. Since Login Form is used for a number of different realms and there is no clear _logical_ link from Cloud to these form it's much more confusing that it can be. Feels like a context problem to me.

We also should keep in mind that Cloud is just one context (albeit important), but not the only one in which Kibana Login Selector is used. So we need something that fits everywhere or is configurable (again Login Assistance Message was done exactly for that).

The particular use case that stood out to me is:

• I have a cloud cluster and now I'd like to add some people to my Kibana deployment.
• I create a new user in Kibana > Management > Users and send them a link to the Kibana log in.
• They open the link and it should be clear that they need to use the basic form (presuming they don't/won't have a Cloud log in).

I'd like Cloud to chime in here to understand the desired flow as well since having just ability to log in to Kibana with multiple realms turned out to be just a tip of an iceberg. We are eager to help here, but we need more details.

• Where users that "we'd like to share Kibana dashboard link with" are going to be managed? Are these going to be "native" Elasticsearch users or users managed by Cloud SAML?
• What other scenarios Cloud SSO is supposed to solve that may involve Kibana login and Kibana isn't capable of handling right now?

/cc @arisonl

[andrew-moldovan]

@azasypkin took a look at Login Assistance Message. So this is set up in the Kibana yaml and would require Cloud to go and update the yaml for each Kibana that we have today and restart them (we're talking like 20,000 Kibanas). Plus write code that would inject this yaml setting for all new Kibanas. That's the bad part. The good part is that this way it becomes easier to find out the correct url, because we know each deployment id when creating the Kibana (I think). Overall it's not a great solution because it does require all this work up front, but probably worth considering. I'll need to consult some others as well. Should we take this question back to https://github.com/elastic/kibana/issues/61808? I don't want to make this issue anymore convoluted.

Where users that "we'd like to share Kibana dashboard link with" are going to be managed? Are these going to be "native" Elasticsearch users or users managed by Cloud SAML?

They're going to be native ES users for now. Cloud does not have any RBAC in place so we can't create separate users. That's today, in the future we do want to be able to create Cloud users that will be managed by Cloud, but they should have the same login flow as the "one" Cloud user today.

[azasypkin]

would require Cloud to go and update the yaml for each Kibana that we have today and restart them (we're talking like 20,000 Kibanas).

Hmm, that is still purely operational task and if it's considered to be a difficult one we could make it only as a part of next upgrade like we most likely will have to do anyway if we decide to implement a new thing on Kibana side. But you're right, let's move this reset password discussion to https://github.com/elastic/kibana/issues/61808.

They're going to be native ES users for now. Cloud does not have any RBAC in place so we can't create separate users. That's today, in the future we do want to be able to create Cloud users that will be managed by Cloud, but they should have the same login flow as the "one" Cloud user today.

I see, thanks.

[ryankeairns]

Based upon recent feedback, I've added a 'Forgot password?' link to the log in form which opens a flyout for further instructions. This saves us from adding a bunch of text to the page (via the log in assistance message) and keeps the full form in view as opposed to blocking it with a modal.

The wording in the flyout is just my initial take at trying to accommodate what I understand to be the two scenarios most likely at play - 1) I'm a cloud admin/user who forgot my deployment creds or 2) I'd like to log in but I don't have a Cloud account and may/may not have a Kibana username/pw (i.e. an admin sets me up via Kibana > Management > Users).

There are several ways the link could be worded. I felt that 'Forgot password?' is succinct and the most familiar even if, in this specific case, there is a little more going on. Some other alternatives that came to mind were:

• Forgot credentials? ('credentials' is less common compared to 'password')
• Can't log in? (this feels and looks repetitive to the button label which is also 'Log in')
• Trouble logging in?
• Need assistance? (sounds like a help chat might pop up)

In the self-hosted setup, there would (presumably) be no 'Forgot password?' link and thus no accompanying flyout.

The mockup below also re-orders the content so that the SAML buttons are underneath the log in form, as suggested in the description of this issue.

Figma prototype

https://www.figma.com/proto/WpaxqMIDXYMzXrGYxuC8xc/Log-in?node-id=8%3A603&viewport=-1059%2C414%2C0.4636690616607666&scaling=min-zoom

Screenshot from prototype

[legrego]

@ryankeairns thanks so much for the updated mockups!

Tagging others who expressed an interest: @bytebilly @jowiho @snide @arisonl

[jinmu03]

@VijayDoshi

[jinmu03]

@ryankeairns would it be too wordy to modify the message to "If you are a cloud user and having trouble login" in the "forgot your password" flyout?

[jowiho]

What about the confused Cloud user who normally just clicks on their deployment link in Cloud UI to get automatically SSO'ed, but who now sees the login screen for the first time because they bookmarked their Kibana? They should just click on "Elastic Cloud SAML" (that caption should be improved) of course, but they might be trying to enter their cloud credentials in the login/password form. How do we help those users?

[legrego]

@ryankeairns would it be too wordy to modify the message to "If you are a cloud user and having trouble login" in the "forgot your password" flyout?

What about the confused Cloud user who normally just clicks on their deployment link in Cloud UI to get automatically SSO'ed, but who now sees the login screen for the first time because they bookmarked their Kibana? They should just click on "Elastic Cloud SAML" (that caption should be improved) of course, but they might be trying to enter their cloud credentials in the login/password form. How do we help those users?

The idea is that we can customize the text to say whatever we want -- this will be configurable by cloud via kibana.yml, so we can work with our writers/doc team to make sure we're conveying the right message. These mockups are just meant to illustrate the overall design: the wording is less important here.

To be more explicit, the following pieces of text will be configurable by cloud:

• The "Forgot password?" link text / Flyout header
• The entirety of the Flyout contents (via markdown), excluding the "Close" button text at the bottom
• The display order and text for the login buttons under the "or login with" section

[ryankeairns]

Updated the mockup in my previous comment:

• Changed button label to read 'Log in with Elastic Cloud'
• Updated flyout text to start with 'If you are a Cloud user and having trouble logging in...'

[bytebilly]

Nice mockup @ryankeairns!

There is something that I'd like to better understand, because I still feel that we could help users in a different manner.

The possible confusion I see with the current proposal is:

1. I have a cloud account, so I click to log in with Elastic Cloud
2. I successfully enter my Elastic Cloud credentials
3. I got rejected because I'm not the owner of this specific deployment
4. I'm back to the login page, looking for help (the flyer)
5. I'm suggested to change my Elastic Cloud credentials
6. I do, but I cannot login anyway!

The main point is that the owner of the deployment is the only one that can login via Elastic Cloud (unless I'm missing something), so this should be super-clear in this page. Also, Cloud SSO and custom SSO are put on the same level, but they are very different (custom SSO can be used by "regular" users, while Cloud SSO cannot).

What about adding a sentence like "If you are the owner of this deployment" to clarify who is allowed to use Elastic Cloud SSO?

I also have a couple of suggestions/questions, coming while approaching this login screen as the "dummy user" that is not already familiar with it.

1. Do we need to mention the word "SAML" at all? As a user, I may not know anything about the technology behind the login process, what SAML is, and frankly I don't really have to care as long as I'm able to login.
2. Is it possible to add icons for login buttons? It's a small thing, but I strongly feel that the Elastic Cloud icon will help people to focus on it. For custom providers, we could use a generic one, or allow people to specify them in the config. This action may be split into different steps and implemented in different iterations in case.

Let me know what you think!

[cristina-eleonora]

2. Is it possible to add icons for login buttons? It's a small thing, but I strongly feel that the Elastic Cloud icon will help people to focus on it.

+++

Will cloud SSO exist only for ESS or also for ECE?

[legrego]

@azasypkin and @jowiho discussed a possible simpler solution, which I'll try to outline here:

Rather than trying to encode all of this information into the login screen, we could use the existing xpack.security.loginAssistanceMessage to display a simple one-liner. Something to the effect of:

Need help logging in?

This would be a link to a cloud docs page which could explain all of the different scenarios based on the user type.

This has the following advantages:

No code changes required to Kibana

Cloud could configure Kibana without any additional work on the Kibana side, via the existing xpack.security.loginAssistanceMessage.

Documentation can be dynamic

If we encode all of these instructions into Kibana itself (even via kibana.yml), then any changes we want to make would require Kibana to be restarted. Having Kibana link to external docs means that the docs can be updated and refined without restarting all Kibana instances.

I think this is important because Cloud SSO will continue to improve over time, which will allow for more users and user types to exist. The changing nature of Cloud SSO means that the instructions/help text will likely want to change too, once it's possible for "average Kibana users" (non-deployment owners) to login via Cloud SSO. We wouldn't want to force-restart Kibana instances to get new help text, nor would we want existing instances to live stale help text.

Localization

An externally linked doc has the possibility of being localized, whereas hard-coded messages in kibana.yml are much more difficult to localize.

Metrics

We can collect metrics on how many page visits this documentation link receives, to see how effective our login experience is going forward

[ryankeairns]

@bytebilly I can answer a couple of those:

• The custom button text can ultimately say whatever the customer wants, so we should not get too hung up that. That said, I've removed the 'SAML' text from the mockup.
• Regarding icons, I had them in the original design but the feedback was that it was too much to tackle in this short window of time, so they were hidden in the mockups. I agree that a Cloud icon would be helpful, but leave it up to the implementors to determine when best to add them.

I would also add that, in my opinion, adding more text to the base log in screen will eventually have the opposite effect we desire. It will become noisy and possibly begin to stir doubt and confusion. The flyout neatly tucks much of this away, so I'd recommend keeping the explanation over there without getting too verbose.

[azasypkin]

Thanks everyone for the feedback and @ryankeairns for the hard work on trying to accommodate all the great suggestions we're having here!

But let's try to finally settle on something that's reasonable, feasible and most importantly solves the main problem that spurred that discussion: Cloud users aren't always sure how to log in to Kibana and having a choice makes this issue more apparent.

We believe that the simple solution outlined by @legrego in https://github.com/elastic/kibana/issues/61144#issuecomment-610380361 can solve this problem and has the most reasonable cost/value ratio at the moment along with other benefits (l10n, telemetry etc.). We'll definitely iterate further once we have data for the more informed decisions.

Forgot password? feature that is tightly coupled to Login Form is related, but still a different topic that's discussed and will be eventually implemented in the scope of https://github.com/elastic/kibana/issues/61808. We (Kibana Security team) has this item in our backlog, but it doesn't seem to be something that we should solve right away.

So there are three questions:

1. Does anyone have a strong reason to believe that proposed solution wouldn't work?
2. Can someone from the Cloud Team confirm whether the Cloud part of the proposed solution is feasible and makes sense (page with the instructions presumably somewhere in the Cloud docs and simple predefined value for login assistance message, we can discuss technical details over Slack)? @andrew-moldovan @jowiho
3. Who is going to work on and approve the exact wording? Engineers may not be the right people to solve this. @arisonl @VijayDoshi

[andrew-moldovan]

I filed https://github.com/elastic/cloud/issues/54532 on the Cloud side a few days ago on how we were going to add the loginAssistanceMessage from Cloud. In short, it's doable, especially if we're just linking to a docs page.

[VijayDoshi]

@azasypkin is the proposed wording we should be looking at what is in the prototype? Happy to pull folks in to do a review.

[ryankeairns]

To clarify, the wording is my 'best guess' and definitely needs more consideration. That said, I'm not sure that we've settled on the final design/UX yet.

[azasypkin]

That said, I'm not sure that we've settled on the final design/UX yet.

I believe right now we're trying to settle on the design proposal you've made initially and we already have in 7.7.0. The another design/flow that @snide is working on currently will likely be available only in 7.8.0.

@azasypkin is the proposed wording we should be looking at what is in the prototype? Happy to pull folks in to do a review.

As @ryankeairns noted we don't really have any wording yet, we need some simple text for the link that will lead to the Cloud docs page with instructions/clarifications/etc. (see the assistance message in highlighted area on the screenshot above). This help link will likely be used by the user only once so I think good enough text would do the job.

---

P.S. re-ordering of buttons and form is probably something we can still squeeze into 7.7.0 if everyone thinks it's better.

[VijayDoshi]

@alexfrancoeur @arisonl can you propose wordage? Please focus on making sure the user understands the the "task" they are performing. Please add me to review.

[snide]

These were the latest round of designs discussed over slack. Again, the main importance here is presenting the question before the answer. Don't show the login forms till the user has made that first decision.

Copy in the "help" text is verbose, but I can't think of a way around it at the moment.

If possible. I would suggest these changes for 7.7. @ryankeairns had a comment that maybe the help text could be a modal, instead of a dedicated page. I'm fine with that if others feel similar.

[VijayDoshi]

Regarding the text a couple of thoughts. Current organization favors the administrator flow, is that what we want, should we be optimizing for normal users?

This is very verbose, can we remove cognitive load for end users by putting them first in the order of the explanation and perhaps have something you expand if you are an administrator?

I think we can simplify the wordage too. Will take a look at that in a bit.

[snide]

Regarding the text a couple of thoughts. Current organization favors the administrator flow, is that what we want, should we be optimizing for normal users?

This is very verbose, can we remove cognitive load for end users by putting them first in the order of the explanation and perhaps have something you expand if you are an administrator?

I think we can simplify the wordage too. Will take a look at that in a bit.

@VijayDoshi Feel free to give it a shot. It could definitely be improved. I'm a serial documenter so I tend to be overly verbose. Any editing would be appreciated.

[VijayDoshi]

@azasypkin Do we know the email address of the administrator for the deployment they are logging into at this point in the flow?

[jinmu03]

Do we know the email address of the administrator for the deployment they are logging into at this point in the flow?

@VijayDoshi We don't know the email address at this moment

[VijayDoshi]

Proposed text:

If you were invited here, try logging in with your Kibana Account. If you've lost your password, contact your administrator.

Administrators: (can this be an expandable chunk of markup)
If you set up this deployment, use the account you created on Elastic Cloud or reset your password.

When you set up a deployment we create something called the "Elastic user" account, this is used for Beats among other things. If you've lost that password you can reset it in the Security tab of the Cloud Console.

Contact Support - Elastic Support (link not a button?)

[snide]

@VijayDoshi here you go in prototype form. Slight copy changes.

https://www.figma.com/proto/1yRyEEPb8NMcPOj2cbybQB/Kibana-SSO-login?node-id=1%3A126&scaling=min-zoom

[snide]

Bad link, fixed.

[VijayDoshi]

We could remove the Basic Primer on Logging into Kibana title IMO.

[jinmu03]

Administrators: (can this be an expandable chunk of markup)
If you set up this deployment, use the account you created on Elastic Cloud or reset your password.

@VijayDoshi Should we specify the "account" should be the native Kibana user account instead of cloud admin account?

[jowiho]

Clicking on "Login with Elastic Cloud" in figma currently leads to the Cloud login page. TBC: that only happens when your Cloud SSO session has expired. If you still have an active Cloud SSO session, clicking on "Login with Elastic Cloud" will directly log you into Kibana.

Administrators: (can this be an expandable chunk of markup)
If you set up this deployment, use the account you created on Elastic Cloud or reset your password.

@VijayDoshi Should we specify the "account" should be the native Kibana user account instead of cloud admin account?

I agree that "use the account you created on Elastic Cloud" is ambiguous. Do we mean your personal Elastic Cloud account, or the "elastic" count that was created when you created your deployment? I guess the first (because the paragraph after this deals with the "elastic" account"), but then the text should just say "If you set up this deployment, click on Login with Elastic Cloud". No need to talk about resetting passwords there, because clicking on that button leads you to the Cloud login page that includes a "Forgot your password" link.

[jowiho]

About the "When you set up a deployment.." text. This could be improved.

Firstly, it doesn't actually tell you that you can use the "elastic" account to login. On the contrary, it suggests that the "elastic" account is used for other purposes like Beats.

Secondly, "something called the Elastic account" can be sharper, like "a local account with the username elastic" (not the lowercase e in elastic).

Finally, "if you you've lost that password you can reset it.." can be sightly more concise "You can reset the password for that account.."

[VijayDoshi]

Good feedback, how about this:

If you were invited here, try logging in with your Kibana Account. If you've lost your password, contact your administrator.

Administrators: V
If you set up this deployment, click on Login with Elastic Cloud

You can also log in as the "Elastic" user which was set up when you created your deployment. If you've lost that password, you can reset it in the Security tab of the Cloud Console.

Contact Support - Elastic Support (link not a button?)

.

[jowiho]

Nit: "elastic" user is with a lower case "e". Not sure if ES usernames are case sensitive, but we use all lowercase everywhere else.

[bytebilly]

Not sure if ES usernames are case sensitive, but we use all lowercase everywhere else.

FYI the elastic user is case sensitive.

[arisonl]

Where do the "Kibana account" and "Cloud account" links point to in this primer? The fact that they are separate is the root of the confusion and I am not sure to what extent "Kibana account" is clear to all users. Since the new experience is aiming 7.8, would it make sense to put together a nice and simple 2-minute explanatory video to bridge the gap, possibly as part of the 7.8 marketing activities for Cloud SSO and link it from the Primer?

[azasypkin]

We're planning to start working on these improvements this week so that we can deliver that on time.

@snide, thanks for the mock-ups! I have few questions that we need to clarify before we can start working on this. Please see some details on what login selector consists of and what cases we need to support here:

• Login Selector:

  1. Do we also display Login with Kibana account button if only basic provider is enabled (the one that requires username/password)?

  2. Where do we display Login Assistance Message if it's configured? At the Login Selector only, or at the Login Selector __and__ Login Form?

  3. How the transition between Login Selector and Login form is supposed to look like exactly (slide-in from the right side or ...)? I assume we'll have a single page to eliminate transition delay as much as possible.

  4. Are we OK with buttons without customizable icons? We can likely do this, but there is a cost, we need to understand how important these are.

  5. Do we really need two configurable fields for every button (e.g. Login with Elastic Cloud + Typical for administrators) in addition to common Need help? text? Again, there is a cost for every new configuration value we introduce, document, maintain BWC for etc.

  6. Where is the user authenticated via Login Form supposed to be redirected to when they log out? To Login Selector again or to Login Form? We have to display special Logged out message on the page where user is redirected to after logout, no mater how they logged in, hence the question to make sure we're aligned.

• Login Form:

  1. How would user go back to the Login Selector?

  2. I see Logging in with a Kibana account link leads to the Cloud login page for some reason, what is the purpose? It also means we'll have to introduce one (markdown) or two (text + link) additional configurable values to support that and Cloud will have to configure it.

• Need help? dialog/panel

  1. I assume the title won't be configurable and should work for Cloud and non-Cloud scenarios.

  2. That one seems to be the most confusing for everyone here - I doubt we can come up with a text that is applicable for both Cloud and non-Cloud scenarios and at the same time is useful enough. That means that some part should be customizable and this customizable part can only be plain string or markdown - we cannot use fancy controls in this case (collapsible things, buttons). Is it possible to have something where "fixed" part is generic enough and only customizable part (string/markdown) mentions Cloud and Cloud specific links.

The exact wording/links of the customizable Cloud-specific part is out of scope here, relevant people can discuss it in a separate issue in the Cloud repository in parallel to not clutter this thread even more. Also "Kibana Account" term may not work for the cases when Login Form is used for LDAP/AD authentication that is technically not "Kibana account", so it seems it's not generic enough to me.

[snide]

Thanks. Answering inline.

Do we also display Login with Kibana account button if only basic provider is enabled (the one that requires username/password)?

No. I'd skip to the login screen. The choice screen should only exist if more choices are available.

Where do we display Login Assistance Message if it's configured? At the Login Selector only, or at the Login Selector and Login Form?

Given that these are generally used to overtake and give messaging. I'd put it on both.

How the transition between Login Selector and Login form is supposed to look like exactly (slide-in from the right side or ...)?

Agree with you, state transition, rather than distinct pages is likely fine to keep it fast.

Are we OK with buttons without customizable icons?

Assuming you're talking about the logo for the SAML one. I would certainly try for it if you can. Think of our own internal systems. Seeing the "Elastic" logo when I auth to Github gives me some confidence in my selection. That said, I think it's fine to do an bool check on it if no icon exists. I'm happy to give you a design PR to rough out the UI. I just need the state flows.

Do we really need two configurable fields for every button

Given the problem I've been presented, which is that there are two separate login systems and users are unlikely to know which selection to make (at least initially) I think it's worthwhile.

Where is the user authenticated via Login Form supposed to be redirected to when they log out? To Login Selector again or to Login Form?

To wherever they would go if they hit the unauthed page directly. So back to the login selector if they have choices, back to the form if they don't.

Need help? dialog/pane questions

Understood. Given the limitations, when you have a PR going, I'm happy to do the grunt work to fill this stuff in and make sure we get the proper wording / signoff from everyone. Sounds like we've just got a markdown, flat file. @VijayDoshi and I can figure it out.

[azasypkin]

Improvements for the Login Selector discussed here were merged and will be available starting from 7.8.0.

Parts of the Login Selector that Kibana Admin and/or Cloud will be able to customize are outlined here