Skip to content

Commit

Permalink
taking out unnesesary changes
Browse files Browse the repository at this point in the history
  • Loading branch information
leanneeliatra committed Jun 13, 2024
1 parent bfc9073 commit a118f46
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion _security/access-control/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ Term | Description
Permission | An individual action, such as creating an index (e.g. `indices:admin/create`). For a complete list, see [Permissions]({{site.url}}{{site.baseurl}}/security/access-control/permissions/).
Action group | A set of permissions. For example, the predefined `SEARCH` action group authorizes roles to use the `_search` and `_msearch` APIs.
Role | Security roles define the scope of a permission or action group: cluster, index, document, or field. For example, a role named `delivery_analyst` might have no cluster permissions, the `READ` action group for all indexes that match the `delivery-data-*` pattern, access to all document types within those indexes, and access to all fields except `delivery_driver_name`.
Backend role | (Optional) A backend role is a specific identifier assigned to a user or group of users by an external authentication system (such as LDAP or Active Directory). Instead of mapping permissions to individual users, you can assign these permissions to backend roles, which significantly streamlines the role mapping process. If 100 users share a common function within the organization, they can all be assigned the same backend role. This way, you only need to map the role to the backend role identifier, rather than to each user individually.
Backend role | (Optional) A backend role is a specific identifier assigned to a user or group of users by an external authentication system (for example, LDAP/Active Directory). Instead of mapping permissions to individual users, you can assign these permissions to backend roles, which can significantly streamline the role mapping process. If 100 users share a common function within the organization, they can all be assigned the same backend role. With this approach you only need to map the role to the backend role identifier, rather than to each user individually.
User | Users make requests to OpenSearch clusters. A user has credentials (e.g. a username and password), zero or more backend roles, and zero or more custom attributes.
Role mapping | Users assume roles after they successfully authenticate. Role mappings map roles to users (or backend roles). For example, a mapping of `kibana_user` (role) to `jdoe` (user) means that John Doe gains all the permissions of `kibana_user` after authenticating. Likewise, a mapping of `all_access` (role) to `admin` (backend role) means that any user with the backend role of `admin` gains all the permissions of `all_access` after authenticating. You can map each role to multiple users and/or backend roles.

Expand Down

0 comments on commit a118f46

Please sign in to comment.