[PROPOSAL] OpenSearch Dashboards Authentication out of box

[seraphjiang]

What/Why

What are you proposing?

We are proposing add Authentication out of box feature for OpenSearch Dashboards (OSD). Today OSD doesn't has build-in security feature, there is security plugin, but it has two plugins, one is frontend another backend. It needs both to run OSD with security feature enabled. It is not easy for any site admin to setup and enable security for their usage.

Refer to meta issue on security out of box. https://github.com/opensearch-project/OpenSearch-Dashboards/issues/1215

In this proposal , we'd like to focus build MVP authentication out of box feature for OSD. Basically support basic auth, openid, saml within only NodeJS code.

What problems are you trying to solve?

Site Admin has to install OpenSearch, Security Dashboards Plugin, Security Backend Plugin then they could enable security OSD.

What we expected, Site admin just need to setup OSD to enable security for user.

What is the developer experience going to be?

developer still use /auth/login api to login for different authentication type, but implementation will be all in NodeJS.

For basic auth.

Here is simple approach we could start to evaluate

install a basic-auth npm package which could use to parse basic auth header

yarn add basic-auth

use it to parse credential

const auth = require('basic-auth');
const credentials = auth(req);

// Check credentials
// The "check" function will typically be against your user store
if (!credentials || !check(credentials.name, credentials.pass)) {
    res.statusCode = 401
    res.setHeader('WWW-Authenticate', 'Basic realm="example"')
    res.end('Access denied')
} else {
    res.end('Access granted')
}

verify user credential

// Basic function to validate credentials for example
// different authentication type will has different support
function check (name, pass) {
  let valid = true

  // Simple method to prevent short-circut and use timing-safe compare
  valid = compare(name, 'john') && valid
  valid = compare(pass, 'secret') && valid

  return valid
}

Are there any security considerations?

No.

Are there any breaking changes to the API

We don't want to introduce any API break-change, but we might change implementation detail. e.g. user data might persist into a separate storage

What is the user experience going to be?

Admin will feel much easy to setup/maintain OSD with security enabled There is no impact to end user

Are there breaking changes to the User Experience?

no

Why should it be built? Any reason not to?

We want to simplify the setup. Get ride of dependencies of OpenSearch, Security Plugins and reduce operational cost.

What will it take to execute?

• [ ] Research: how many APIs are required to implement basic authentication out box
• [ ] POC: create a poc to re-implement the login/logout for each auth type (Basic Auth, OpenId, SAML in this order)
• [ ] POC: persist the identity info into separate storage (not OpenSearch), not save through saved objected api. It could be just MySQL database.
• [ ] Come up detail design and proposal

Any remaining open questions?

1. Is authorization in scope? No, we will discuss in another project.

2. Do we want to support user-role of existing security plugin? No. first, role permission mode will be part of Authorization OOB project scope not in authentication. second, even in authorization out of box, we will not redesign existing index/doc based access control which is purely for data access control. It is not end user facing access control.

[davidlago]

Thanks for getting this ball rolling, @seraphjiang !

Is the user store a separate one from the backend? If so, how will you be mapping between the two? I don't fully understand how you would have security just on the OSD side but not need it in the backend.

Also dropping the link here, you might want to follow what changes are coming for Identity in Core, as those might provide other options for you to consider while designing this https://github.com/opensearch-project/OpenSearch/issues/3846

[davidlago]

After thinking about if for a bit longer, I think I get it... let me know if this is right: we are thinking about AuthN/Z in the context of just OSD, but not in the context of access to the backend data. For that second part, we will be leveraging connections, which could be to OpenSearch or to other data sources in the future.

With this approach, you will be adding authentication mechanisms to OSD but they are independent of the backend. Identity mapping when using the data connections to the different backends is outside of the scope of this proposal but something that will have to be considered as we walk down that road.

Is my understanding correct?

[seraphjiang]

Thanks for getting this ball rolling, @seraphjiang !

Is the user store a separate one from the backend? If so, how will you be mapping between the two? I don't fully understand how you would have security just on the OSD side but not need it in the backend.

Also dropping the link here, you might want to follow what changes are coming for Identity in Core, as those might provide other options for you to consider while designing this opensearch-project/OpenSearch#3846

Yes, it will be a purely separate user store.

Imagine a traditional web application with a database. We don't have to create a database user every time a new user signs up. Between the database and the web application, it is a service-to-service communication/integration, including authentication. This means we only need one service user to connect to the database.

End users will not have access to the database at all. They will only be able to access the backend through the service account.

[seraphjiang]

After thinking about if for a bit longer, I think I get it... let me know if this is right: we are thinking about AuthN/Z in the context of just OSD, but not in the context of access to the backend data. For that second part, we will be leveraging connections, which could be to OpenSearch or to other data sources in the future.

With this approach, you will be adding authentication mechanisms to OSD but they are independent of the backend. Identity mapping when using the data connections to the different backends is outside of the scope of this proposal but something that will have to be considered as we walk down that road.

Is my understanding correct?

Yes, we are build independent security out of box, start from authentication. it could be run without OpenSearch.

Mapping different data connections to different backends is outside the scope of authentication, but it should be considered for overall security out-of-the-box. There is no single universal user/role access control for all databases, for example, we cannot expect the same role access in MySQL, MongoDB, and Prometheus. This is why the security out-of-the-box feature will allow customers to manage their feature and functionality permissions. In the meantime, users should continue to rely on existing security plugins to manage cluster-specific access control at the index, document, and column level.

[shanilpa]

Tracking some discussions on this topic here as well: https://github.com/opensearch-project/ux/discussions/54#discussioncomment-4477579. Posting for visibility but also a request if you want to add any additional use cases to this topic or any of the other ones in the discussion thread.