Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DOC] Clarify that there is no distinction between usernames from the internal database and external identity providers #4937

Closed
1 of 4 tasks
davidlago opened this issue Aug 29, 2023 · 5 comments
Assignees
Labels
1 - Backlog Issue: The issue is unassigned or assigned but not started security Sev2 High-medium priority. Upcoming release or incorrect information.

Comments

@davidlago
Copy link

What do you want to do?

  • Request a change to existing documentation
  • Add new documentation
  • Report a technical problem with the documentation
  • Other

We've seen cases where there is confusion with the way OpenSearch does/does not make a distinction between users based on where they are coming from. It does not. For example, user name dave represents the same user whether it is coming from the internal users database or an external LDAP. We should add a sentence in the relevant documentation page to signal as much.

@cwperks
Copy link
Member

cwperks commented Aug 29, 2023

There is a little bit of nuance. While there could be a dave internal user and a dave LDAP user depending on how the user logged in they may have permissions to do different things. They also can be logged into dashboards simultaneously.

The dave that logs into the external IdP may have backend roles from the external IdP that get mapped to different security roles within OpenSearch than the dave that logs in through basic auth and the internal user list.

@cwperks
Copy link
Member

cwperks commented Aug 29, 2023

Consider these 2 roles mapping like this:

all_access:
  reserved: false
  backend_roles:
    - "admin"
  users:
    - "dave"
  description: "Maps admin backend role and dave user to all_access"

readall:
  reserved: false
  users:
  - "craig"

If I have 2 users called dave (one internal and one LDAP), they will both be mapped to all_access because of the user mapping.

Now let's say the internal user craig logs on. The internal user craig has no backend roles and is only mapped to readall.

Now an LDAP user named craig comes around and that LDAP user has a backend role admin
. When it comes to mapping the roles for that user they will get readall and all_access.


  1. Direct user mappings in a roles_mapping would treat users from different IdPs as the same
  2. Backend roles are unique to an IdP so if a user with the same username logs in through different IdPs, they may resolve to different sets of backend roles which could be mapped to different security roles.

@cwillum cwillum self-assigned this Aug 29, 2023
@cwillum cwillum added 1 - Backlog Issue: The issue is unassigned or assigned but not started security Sev2 High-medium priority. Upcoming release or incorrect information. and removed untriaged labels Aug 29, 2023
@stephen-crawford
Copy link
Contributor

Added the following line to the first part of the page @davidlago linked:

"Please note, the Security plugin does not distinguish between identity providers when handling standard role mappings. As a result, only backend roles will differ between two users with the same name coming from two different identity providers."

@davidlago
Copy link
Author

Thanks @scrawfor99 ! Is there a PR you could link here so we can track/close when merged?

@stephen-crawford
Copy link
Contributor

Yeah here you are: #5580

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1 - Backlog Issue: The issue is unassigned or assigned but not started security Sev2 High-medium priority. Upcoming release or incorrect information.
Projects
None yet
Development

No branches or pull requests

4 participants