Vault UI Feature Request: Don't Show all login methods in Vault UI Login Page

[sgleske-ias]

Prior issues

This feature request was originally requested and partially implemented in #4307.

Desired behavior

"Other" methods do not show up at all. I would like to not expose unconfigured methods to users which causes confusion.

Only show auth methods which support showing via unauth visibility.

Screenshot of current behavior

Here's a screenshot including the vault version. "Other" tab is undesirable because it exposes all auth methods.

---

---

[ThomasKasene]

Good suggestion! I'd also like to enable admins to specify a default authentication method.

[slessardjr]

Good suggestion! I'd also like to enable admins to specify a default authentication method.

Agreed, if we can't remove them I'd like to be able to make one the default.

[jmichelgarcia]

I would love to have this!

[erickufrin-okta]

++1.

We need to be able to remove the 'Other' tab. It confuses our end users and causes issues.

[jppitout]

This would be great to alleviate confusion amongst our developers.

[mistial-dev]

If the issue is a "chicken and the egg problem", as mentioned here, then perhaps the best way to handle it would be a setting for "visible methods", rather than actually reading the auth mounts.

While that could mean that the UI and the backends get out of sync, that might actually be a desirable feature. For example, we'd like to retain the capability to use root tokens for APIs if absolutely required, but would rather not show that as an option in the UI.

Hiding it would not technically stop it from being used, but it would serve to discourage the practice and reduce user confusion.

[itman-co]

I believe this is a must feature. Specially if you have a large number of people working with Vault.
Really confusing.

[rjhornsby]

Any thoughts or progress on this? We only use OIDC for our users' web UI access to vault, but I can't make it easier for them to log into vault by removing the unused options. I know it's OIDC because I manage the cluster, but it's kind of a poor UX for everyone else who is expected to remember that.

I don't mean that OIDC is the only possible option ever and the rest should go away. I do wish the list population to be configurable because I want my users to have a good UX, which encourages them to use vault instead of sticky notes.

[davama]

Glad this FR exists.
Hope this gets looked at soon

Thank you for the awesome application!

[via-justa]

This request is open for almost 2 years now, been added the community-sentiment label more than a year ago but still no progress?
Hashicorp can someone please comment if we have false hopes to see it happening?

[hellobontempo]

Hi there 👋 and thank you for the discussion around this! Apologies for the delayed response. We have no plans to remove the Other tab. We understand the login experience can be confusing, but need to keep the dropdown so unauthenticated users are able to select any of the possible login methods.

As an interim solution may I suggest users bookmark their preferred method by doing the following:

1. Configure your method to List when unauthenticated. This adds the method as a separate tab to the login form.
2. Selecting the tab in the login screen adds a query param to the URL which can then be saved as a bookmark. This should allow users to directly navigate to their preferred login method and avoid the "Other" tab all together.

We are listening and want to improve the UX here. @finnstech Could we please save this issue internally where we’re tracking future improvements to the UI login page so this feedback can be revisited?

[rjhornsby]

@hellobontempo i'm a little bit confused by your reply.

we need to keep the dropdown so unauthenticated users are able to select any of the possible login methods.

We, the vault administrators, decide what login methods are available by configuring said authentication methods. It's unclear why all methods - even those explicitly and deliberately not configured and thus not available for use - must necessarily be shown in the list presented to end users.

Second, our vault 1.12 login screen doesn't look like your gif. There are no tabs and nothing called 'other'. What is being asked here is about a dropdown list.

[nneul]

@hellobontempo "We understand the login experience can be confusing, but need to keep the dropdown so unauthenticated users are able to select any of the possible login methods." Why do unauthenticated users need to be able to choose an authentication method that we (as the admins of the server) do not WANT them to use, or even more applicably - have not even configured to be functional?

The option to list one explicitly is fine - but in your example - there are a whole slew of login methods that are not even configured to be functional. Why are they even shown?

Example on my instance - I don't have GitHub or JWT or Radius or Username as configured/usable options. Why are you forcing my users to see those as choices when they can't even USE them?

[hellobontempo]

@rjhornsby
To add methods as tabs, you have to select List method when unauthenticated when configuring the auth method. The gif shows how to navigate in the UI to change this setting. (Both methods, oidc and test_path have listing_visibility: unuath which is why they both appear as tabs) docs here

@nneul
This configuration is then applied to the method, but is not user specific, which is why the dropdown is hardcoded to contain all possible login methods to Vault. Prior to authenticating, Vault has no knowledge of per-user capabilities

[patoarvizu]

@hellobontempo But Vault does have knowledge of what auth methods are available even when the user is unauthenticated, so couldn't it just trim the dropdown list to those options?

[slessardjr]

@hellobontempo maybe there is a misunderstanding, but for my users it was confusing to them why the default method wouldn't be OIDC. It's extra clicks for them, the only users using any other auth methods are Admins.

This feature request is to enhance end-user experience when logging in. As an admin, I should be able to enforce which methods are the acceptable ones and which ones should be default.

[davama]

If you tune your prefered auth method as stated here

ex:

vault auth tune -listing-visibility="unauth" ldap/

i believe the method gets selected by default upon an unauthenticated access to the UI

EDIT

i may be wrong about it showing as default... looks like it's alphabetical... but we only have ldap or token... so ldap is always the first tab

[slessardjr]

@davama that's exactly it. I have Ldap (on-prem ad linked), OIDC (Azure AD), and Token. Ldap needs to be there for legacy reasons so I can't remove it, but trying to move users over to using Azure AD was failing because everyone was still just using LDAP.

[hellobontempo]

@slessardjr

Ldap needs to be there for legacy reasons so I can't remove it.

Are you able to change the listing visibility for LDAP? This won't remove the mount, but it would remove it as a tab in the login form and point users to using the oidc azure option

[hellobontempo]

🪴 TL;DR 🪴
Thank you for this discussion and we will be mindful of this feedback when planning future improvements surrounding the login flow. We understand it's an important feature to many of you, but at this time we are unable to just "filter the dropdown." I highly recommend leveraging the listing_visibility setting to expedite the user login flow (directions below).

---

There are a couple different issues mentioned in this thread that are worth addressing separately:

1. user specific login views 👉 this is not possible as prior to authenticating there is no way for vault to know who is attempting to login 🕵️

2. customizing the dropdown 👉

@patoarvizu: Vault does have knowledge of what auth methods are available even when the user is unauthenticated, so couldn’t it just trim the dropdown list to those options?

The dropdown displays different auth method types not auth mounts. Vault does not actually have knowledge of which methods types are enabled, prior to authentication. The login form relies on this unauthenticated endpoint.

$ curl \
    http://127.0.0.1:8200/v1/sys/internal/ui/mounts

Auth mounts (not auth method types) tuned to have listing_visibility: unauth are returned by the above request. This is how we add the tabs for an auth mount in the login form. Leveraging this param will ✨ save your user clicks ✨ if they select the tab of their preferred login mount and save the URL as a bookmark 😄

---

UI Steps for changing the listing visibility of an auth mount:

1. select the mount and click Configure

2. click Method Options

3. check "List method when unauthenticated" and save! 💾

[patoarvizu]

@hellobontempo Gotcha. So, with the understanding that you don't plan on working on this for now, let me ask the following question for my own education: I can see that the call to /internal/ui/mounts returns the list of auth mounts, but the information about each mount's type is also there, so that could be used to have logic in the front end to filter out the drop down list, wouldn't it? I'm not a front-end developer so I don't want to say how hard or easy it would be, but I know that the information about what auth types are available is there, it's unrelated to the authentication status of the user and that you're already doing some logic with that information to create the tabs.

I don't want to speak for everybody else here, but I don't think the request/wish is to have a dynamic list of auth types available to a yet-unauthorized user (I understand that's next to impossible), but rather just a list of available auth options overall, which doesn't need to be at the user level.

Anyway, thanks for taking the time to reply!

[rjhornsby]

a list of available auth options overall, which doesn't need to be at the user level

Correct. Like @nneul points out, methods like Github and RADIUS are not enabled at any level in our vault and the ask is to not have them shown at all.

[nneul]

I guess what I'm not getting on all of this - the "listing_visibility" setting already has a default of "hidden" and that's already controlling the display when user is unauthenticated. Why not just just "hide it" if that is the setting and there is any listing_visibility set to 'unauth'. Or if you want to have it be highly explicit, add an "invisible" value to choose to not have that auth type be shown at all, even in the other dropdown.

This cannot possibly be more than a few lines of code.

[hsimon-hashicorp]

While we love to see an energetic discussion, I do want to take an opportunity to remind folks of the HashiCorp Community Guidelines. Please remember that we're all human beings behind these screens, and that the Vault developers strive to create the best product they can for our users. Also, with a complex product like Vault, what might seem to be simple changes can have unintended consequences.
Above all else, please be kind and we shall do the same. Thank you! :)

[hellobontempo]

@patoarvizu - Thank you for your question! 😄 Essentially this feature request is more than a simple UI change, but a larger ask that requires lots of cross-team planning to thoughtfully implement.

I understand the main request here is "a dynamic list of auth types". Yes - type is a param returned by that /sys/internal/ui/mounts endpoint. But this information is still only returned when mounts are tuned to have listing_visibility: unauth and - as made apparent by this thread - this is a param many users are still unaware of 😅

Therefore, filtering the dropdown using existing resources would filter the dropdown for every Vault user. The UI would be unusable for anyone who failed to tune their mount accordingly. (In addition, this would likely cause further confusion since it would look like Vault has some awareness of available auth method types, but it would still only be aware of which mounts had been tuned from hidden to unuath)

This means to avoid any breaking changes dropdown customization is reliant on either:
1.) customizing the Vault UI which is unprecedented and would be part of a much larger initiative
2.) adding an additional config parameter to tune auth mounts - this is outside the scope of the ui team and would need to be planned in tandem with backend folks

Hopefully this explains why this isn't a straightforward feature request - though we do recognize there's a lot of support for it!

Utilizing the tabs seems much easier than bothering with the dropdown, but I'm interested in hearing if/why this is not a viable solution. Any insight would help to prioritize this work 🧙

[pascal-hofmann]

@hellobontempo How can I configure a custom logo/text for the login button as seen in your gif above?

[hellobontempo]

@pascal-hofmann - There's an open feature request right now for supporting custom labels #10426.
Right now the button updates automatically if your OIDC provider is gitlab, auth0 or google.

[finnstech]

@hellobontempo tracking internally with other UI/UX asks. Thanks for the feedback!

[Markus-]

I still don't get ist.

As I understood the most comments the only thing we want to have is:

The admins, who configured the valid authentication methods want to have a config-parameter, where the shortcodes of these authentication methods are listed and if this config parameter is set the ui just show the methods in this list and does not check any other "backend"-stuff.