Open cwperks opened 1 year ago
[Triage] Hi @cwperks thank you for filing this issue. Going to tag this help wanted for the time being.
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.
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:
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:
@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.
Here's a little updated design based on the original
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:
Valid combos are:
https://localhost:5601/app/dashboards?token=<jwt>
and never actually have to hit the login screen.In general, we should consider offering a UX with guardrails and guides the users to complete the tasks.
So, a few relateed questions: @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/
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.
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
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.
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.
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:
cc: @kgcreative
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.
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
+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:
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
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
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.
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:
@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:
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 valueopensearch_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
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?
I noticed that I was able to deselect all options. Can it be required that at least one option is always selected?
Great work!
@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.
@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:
Would there be a case for users to configure multiple sign-in options that are neither Basic auth, SAML, OpenID?
@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
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.
@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.
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?
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.
I updated the branch to reflect the following changes:
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.
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?
Log in with {auth_name}
aligns with the language we have been using in OpenSearch. It is commonly used on Login screens in general.
@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)
@davidosorno A few UI tweaks to align with our OUI patterns:
On the modal:
Dashboards sign-in options
. It should be sentence case (only the first word of a sentence is capitalized).Select one or multiple authentication options to appear on the sign-in window for OpenSearch Dashboards.
On the Authentication page:
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.
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 ?
@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.
@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.
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: https://github.com/opensearch-project/security-dashboards-plugin/pull/1110
Configuring multi auth is done via settings in
opensearch_dashboards.yml
. Example: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: https://github.com/opensearch-project/security-dashboards-plugin/issues/1302