[FEATURE] Dynamic Sign in options for OpenSearch Dashboards

[cwperks]

Is your feature request related to a problem?

Since OS 2.4, the security-dashboards-plugin has supported having multiple login options from the login screen: #1110

Configuring multi auth is done via settings in opensearch_dashboards.yml. Example:

opensearch_security.auth.type: ["basicauth","openid"]
opensearch_security.auth.multiple_auth_enabled: true

Since these settings are defined in opensearch_dashboards.yml its not possible to change the configuration without restarting OpenSearch-Dashboards. It could be useful to make these settings dynamic to allow cluster admins to change these settings without having to restart dashboards.

What solution would you like?

Allow cluster admins to change multi-auth settings dynamically

Do you have any additional context?

A similar feature was implemented for multi-tenancy: #1302

[stephen-crawford]

[Triage] Hi @cwperks thank you for filing this issue. Going to tag this help wanted for the time being.

[cwperks]

Here's a screenshot where 2 authenticators are configured for OpenSearch-Dashboards. Basic Auth + SAML.

This is Basic Auth + SAML for logging into dashboards. Here's a zip of the configuration as well.

2.10.0-saml-plus-basic-multiauth.zip

The outcome of this issue will be to dynamically change what is shown on the login screen. Through the admin page an admin could configure login with basic + SAML, or remove the option to login with SAML and just have basic (username + pw), or remove basic and have login with SAML by itself (in which case the login screen won't appear and a user will be re-directed to the SAML IdP's login screen).

Any change would be dynamic and not require a reboot of OSD.

[cwperks]

Not all combinations of multi-auth may be valid initially. Its possible to have multiple single-sign on buttons, but the prompt for username and pw can only appear once.

The prompt for username and pw is shown when OSD is configured either with:

• Basic Internal Auth
• LDAP auth

Single sign on would apply to SAML and OIDC. Other auth types would not go through the sign in screen and are out of scope. Other auth types include clientcert, proxy and jwt.

Only the following combinations of auth types are valid to configure for multiauth:

1. basic or ldap
2. one or more of saml or oidc

[davidosorno]

@EduardoCorazon and I are working on this feature and I proposed the following UX/UI design

However @cwperks mentioned that "Not all combinations of multi-auth can be done iirc.
I believe you can only select up to 2 and it would need to be the following combinations:
basic or ldap
one or more of saml or oidc" multi auth documentation.
We'll post some UX/UI ideas and I hope @kamingleung can help us here too to create a good user experience.

[EduardoCorazon]

Here's a little updated design based on the original

[cwperks]

Thank you for posting the mockups @davidosorno and @EduardoCorazon! The UX will need to reflect what valid combos a user can choose from for showing login options on the login screen. There are 2 broad categories:

1. Username and pw entry on OSD login screen (This is the case for Basic internal auth and LDAP)
2. SSO button - when a user clicks the SSO button they are re-directed outside of OSD to their identity provider's login screen. On successful login they are re-directed back to OSD. (SAML and OIDC)

Valid combos are:

1. One of Basic Internal auth and/or LDAP
2. One or more of SAML / OIDC
3. Other authenticators should not be displayed because they are options for programmatically connecting to OpenSearch and not for logging into OSD. JWT is a bit of an exception, but with jwt you pass a url param like https://localhost:5601/app/dashboards?token=<jwt> and never actually have to hit the login screen.

[kamingleung]

In general, we should consider offering a UX with guardrails and guides the users to complete the tasks.

So, a few relateed questions: @cwperks

1. What are some of invalid examples / edge cases?
2. Does multiple auth is only support 3 types: Basic, OIDC, SAML? Assuming a user can select Anonymous as a single auth method, then if a user enables multi auth, does it mean the Anonymous auth will be disabled?
3. If a user enables multi-auth from single auth, what will happen to the existing single auth? What if the admin deselect a method that is currently used to login to the instance? Are there mechanisms to prevent getting locked out?
4. What are the end-to-end steps for an admin to setup authentication? Is it: first select SAML as a method, then go to a config file to config SAML, any other steps?

[cwperks]

Thank you @kamingleung. See my answers below. The documentation on multi-auth on the documentation website is pretty extensive: https://opensearch.org/docs/latest/security/configuration/multi-auth/

1. This feature would not enable or disable the authenticators on the backend, but only change how the login screen for OSD would present. There must be at least 1 login method for OSD defined at any given time. Basic could be configured at most once, anonymous at most once, but for SAML and OIDC there (theoretically) could be many. I have to double check the implementation of multi-auth, but there may already be a restriction of 1 per type.

2. Anonymous login can be a button similar to the SSO button. See Priscilla's post on the OpenSearch forum here to see an example of Log in as Anonymous: https://forum.opensearch.org/t/anonymous-user-multiple-authentication/11577/2?u=cwperks

3. Simply toggling to enable dynamic multi-auth would not change the existing login screen. The login screen would only change if the admin made a change to select multiple login options for the login screen. The second part to this question is a good question. There will always need to be a way to login into dashboards so a user cannot remove all login methods. A cluster admin could always use securityadmin to re-enable other login methods for OSD.

4. Typically setup is done through yaml files before initial cluster startup. The yaml files we ship with has many examples of configs for different types of identity providers, but ultimately its up to a cluster admin to finish the configuration. Sometimes setup requires a lot of trial and error before a user is able to successfully get OpenSearch and OSD configured with SSO. Setting up multi auth means configuring multiple authentication backends in the security plugins config.yml file like this:

config:
  dynamic:
    authc:
      basic_internal_auth_domain:
        description: "Authenticate via HTTP Basic against internal users database"
        http_enabled: true
        transport_enabled: true
        order: 0
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          type: intern
      saml_auth_domain:
        http_enabled: true
        transport_enabled: false
        order: 1
        http_authenticator:
          type: saml
          challenge: true
          config:
            idp:
              entity_id: http://localhost:8080/simplesaml/saml2/idp/metadata.php
              metadata_url: http://localhost:8080/simplesaml/saml2/idp/metadata.php?output=xml
            sp:
              entity_id: opensearch-dashboards
            kibana_url: http://localhost:5601/
            roles_key: Role
            subject_key: NameID
            exchange_key: '<exchange_key>'

and also configuring opensearch-dashboards.yml to enable both login with username/pw or SSO with SAML.

opensearch_security.auth.type: ["basicauth", "saml"]
opensearch_security.auth.multiple_auth_enabled: true

with this feature, an admin would be able to dynamically change whether the SSO button appears on the login screen w/o having to change the opensearch_dashboards.yml file and restart the OSD node.

What I would like to do in the future is be able to start a cluster with Basic Authentication and then configure another SSO provider like SAML or OIDC directly in OpenSearch Dashboards.

[kamingleung]

Thank you @cwperks for your extensive response, very helpful!

If this feature is purely on configuring what appears on the login the screen, we should explicitly name it that way to avoid confusion (especially when the security plugin UI also deal with backend configurations).
Perhaps the header of that section can be named "Sign-in options for Dashboards".

I also wonder if we can simplify the UX by removing the multi-auth switch:

• If a user selects one option, this will be single auth in the yaml file.
• If a user selects more than one option, this will be multi-auth in the yaml file.

cc: @kgcreative

[kamingleung]

I agree that we should offer configuring auth methods within Dashboards, this can allow a much more end-to-end experience under a single pane.

[kgcreative]

We're mixing "read-only" interfaces with an editable interface here. I would suggest a discrete "edit" button that either opens a flyout or a dedicated page for this. This would also make this page a bit less fragile

[kamingleung]

+1 on @kgcreative comment.

For UI components, let's align with the common patterns defined in OUI. Here's a quick proposal.

This page is displaying read-only content, let's be consistent by keeping the new section read-only and add a dedicated Edit flow. We can replace the "Apply changes" button with a Edit button:

I wonder if we can simplify this further by removing the table and instead display the active options as key value pair.

I would suggest clicking on Edit will open a modal to update the options:

[davidosorno]

This is what I've done so far based on the feedback I got.

It gets the sign in options based on authentications available at the back end, so I used HTTP type to get it.
LDAP and Basic are both BASIC authentication, so I add just 1 option.

When Security plugin is installed it has BASIC authentication by default, then the user may update their choices.

I'm still working on updating values on back end, and here are the repos so far.
Security Plugin
Security Dashboard

[kgcreative]

Thanks @davidosorno for this update! Does the "SignIn Option Status" column reflect the current config? This feels redundant and potentially confusing. (For example, in the view you show, would unchecking "basic" change the status from "Enable" to "Disable"? If so, then i'd argue it's not needed.
If instead it's showing the current status before the changes are applied, then perhaps we can rename that column to "Current status" and use "On / Off" instead of "Enable / Disable"
Finally, we want "Cancel" instead of "Close" and "Update" or "Update configuration" instead of "Save changes" (this is because the next action will send out an API call to make the config change, so we'e not really saving a saved object)
cc: @kamingleung

[davidosorno]

Thanks for the feedback @kgcreative.
Yes, it reflects the current values, and I agree that the Edit view is a little bit confusing, I'll make the changes.
I'm planning to remove the Status column from the Edit view, I think the checkbox is enough to show to the user that this value can be activated or deactivated then update the con. What do you think?
Also, I'll rename the column in the main view as Status.

[davidosorno]

I think the feature is ready, and I'm working on testing the UI. It would be great if I can get some feedback about it, here are the updated repos:

Security
Security Dashboard Pluging

[cwperks]

@davidosorno Thank you for providing the branches. Its awesome to see the feature working to change the signin options from the admin pages!

A couple of items:

1. For the 2 primary existing opensearch_dashboards.yml settings for multiauth:

opensearch_security.auth.type: ["basicauth", "saml"]
opensearch_security.auth.multiple_auth_enabled: true

Can these settings be maintained (albeit change their behavior slightly) in order to be backward compatible so that when clusters upgrade there is no change in config?

• opensearch_security.auth.type - Can this be treated as an initial value? i.e. if signin options are not configured in the backend and the API that returns signin options returns empty can this be taken as the initial value? If the response from the backend to get signin options is not empty than that would override this value
• opensearch_security.auth.multiple_auth_enabled - Can this be treated as a feature flag? i.e. if this is true then show the panel in the authentication pages in OSD so a user can configure signin options through OSD and otherwise don't show the panel? true can be the default value for this setting if its not explicitly in opensearch_dashboards.yml

2. The route to update the signin options is registered in a file that requires multi-tenancy to be enabled. Should this route be registered always or when opensearch_security.auth.multiple_auth_enabled is set to true?

3. I noticed that I was able to deselect all options. Can it be required that at least one option is always selected?

Great work!

[davidosorno]

@cwperks Thanks for the feedback.

opensearch_security.auth.type - Can this be treated as an initial value?

Sounds good.

opensearch_security.auth.multiple_auth_enabled - Can this be treated as a feature flag?

This value is used to create a MultiAuthentication handler that it's totally different from the sign in options panel.
If needed, I think we should create another way to disable the panel. Besides, what would be the point to disable the sign in options panel if there are multiple auth backend types added to the security?

The route to update the signin options is registered in a file that requires multi-tenancy

Yes, I 'll fix it.

I noticed that I was able to deselect all options. Can it be required that at least one option is always selected?

That's strange, the Update button should be disabled when there is not option selected or when the options are equal to the actual configuration, I'll take a look.

[kamingleung]

@cwperks

opensearch_security.auth.multiple_auth_enabled - Can this be treated as a feature flag?

On the UI, I am wondering if we can simplify this by integrating this setting as part of the sign-in options:

• If there are multiple sign-in options selected, then that also means multiple auth is enabled
• If there is only a single sign-in option selected, then that means multiple auth is disabled

Would there be a case for users to configure multiple sign-in options that are neither Basic auth, SAML, OpenID?

[kamingleung]

@davidosorno Would it be possible to post a quick walkthrough video capture of your implementation?

E.g. Start from AuthZ AuthN page > go to "Sign-in options" > click on edit, unselect all options > Select options > Save

[davidosorno]

signin-options.mp4

[davidosorno]

I just found this code and I'm wondering if we are going to keep this behavior, any thoughts on this?

if (!includeBasicAuth) {
    return `Authentication type is not configured properly. basicauth is mandatory.`;
}

Also, I already fixed initial values and the route.

[cwperks]

@davidosorno Let's keep that in, but I think it would be possible to remove that restriction in the future. Curious, if you were to remove that restriction and setup 2 SSO methods (i.e. SAML and anonymous), would it render 2 buttons according to each method to sign in or would it produce an error? I'm wondering if there is other work that would need to be done to the login page so that it doesn't render the username and password input.

[davidosorno]

Right now if we remove the Basic authentication it doesn't show an error, it renders the authentication types buttons available.

@cwperks should we include the Anonymous option by default in SignIn options or should we include it only if it is enable in config.yml file?

[cwperks]

should we include the Anonymous option by default in SignIn options or should we include it only if it is enable in config.yml file?

Only if its enabled. It would be an invalid combo to have anonymous disabled, but have multiauth configured with anonymous.

[davidosorno]

I updated the branch to reflect the following changes:

1. It combines auth type from backend and yml file in case there are JWT, PROXY or more auth types available.
2. It shows Anonymous sign in option if it's enable in backend.
3. it doesn't require the multi auth parameter in yml file to enable Multi Authentication.

Also, I found this SAML Auth can not be enable with Anonymous, however I think we don't need to implement sign in options restrictions right now because there is a feature requested for this behaviour.

[davidosorno]

If OPEN ID and SAML sign-in options are available, it displays the buttons without difference.

what should be the buttons text?

or maybe
SAML Single Sign-on
OPEN ID Single Sign-on

any ideas?

[kamingleung]

Log in with {auth_name} aligns with the language we have been using in OpenSearch. It is commonly used on Login screens in general.

[cwperks]

@davidosorno There are static settings (in opensearch_dashboards.yml) that can customize these buttons (https://opensearch.org/docs/latest/security/configuration/multi-auth/#customizing-the-sign-in-environment). Those customization settings should also eventually be dynamic and configurable through pages in OSD.

IMO we can update the default from Log in with Single Sign on to Log in with Single Sign on ({auth_name}) i.e. Log in with Single Sign on (Open ID)

[kamingleung]

@davidosorno A few UI tweaks to align with our OUI patterns:

On the modal:

1. Update title to Dashboards sign-in options. It should be sentence case (only the first word of a sentence is capitalized).
2. Update description text to Select one or multiple authentication options to appear on the sign-in window for OpenSearch Dashboards.
3. Use checkbox group instead of table. This is consider a form.
4. Display the name as human friendly names. E.g. Basic Authentication, SAML, OpenID Connect....
5. Follow the modal component. Cancel buttons should use OuiButtonEmpty.

On the Authentication page:

6. Update title to Dashboards sign-in options. It should be sentence case. Dashboard should be Dashboards. Update description text to Configure one or multiple authentication options to appear on the sign-in window for OpenSearch Dashboards.
7. Display the name as human friendly names. E.g. Basic Authentication, SAML, OpenID Connect....

[EduardoCorazon]

Good evening @kamingleung , I wanted to inquire on the transition from Eui to Oui since as referenced here: [OUI] Refactor namespacing to use OUI instead of EUI #2573 it appears that Oui is aliased to EUI. And since we're currently facing global styling issues when using Oui components and the rest of OpenSeach uses Eui, I wanted to know if the tweaks for OUI patterns involves calling <Eui> components rather than directly calling <Oui>?

Ex. we keep using <EuiModal> instead of <OuiModal> as OUI is aliased to EUI ?

[kgcreative]

@ashwin-pc -- can you provide Eduardo with some guidance here? My understanding is you'll continue to use <EuiModal>, which will call the correct thing under the hood.

[ashwin-pc]

@EduardoCorazon yes. All EUI references inside OSD and its plugins are under the hood aliased to OUI. You cannot directly reference OUI in the code yet.