Editorial cleanup

Author: aetter

docs/security-access-control/default-action-groups.md

@@ -23,24 +23,24 @@ Name | Description
 :---| :---
 CLUSTER_ALL | Grants all cluster permissions. Equates to `cluster:*`.
 CLUSTER_MONITOR | Grants all cluster monitoring permissions. Equates to `cluster:monitor/*`.
-CLUSTER\_COMPOSITE\_OPS\_RO | Grants read-only permissions to execute requests like `mget`, `msearch`, or `mtv`, plus permissions to query for aliases.
-CLUSTER\_COMPOSITE\_OPS | Same as `CLUSTER_COMPOSITE_OPS_RO`, but also grants `bulk` permissions and all aliases permissions.
+CLUSTER_COMPOSITE_OPS_RO | Grants read-only permissions to execute requests like `mget`, `msearch`, or `mtv`, plus permissions to query for aliases.
+CLUSTER_COMPOSITE_OPS | Same as `CLUSTER_COMPOSITE_OPS_RO`, but also grants `bulk` permissions and all aliases permissions.
 MANAGE_SNAPSHOTS | Grants permissions to manage snapshots and repositories.
 
 
 ## Index-level
 
 Name | Description
 :--- | :---
-INDICES\_ALL | Grants all permissions on the index. Equates to `indices:*`.
+INDICES_ALL | Grants all permissions on the index. Equates to `indices:*`.
 GET | Grants permissions to use `get` and `mget` actions only.
 READ | Grants read permissions such as search, get field mappings, `get`, and `mget`.
 WRITE | Grants write permissions to documents.
 DELETE | Grants permissions to delete documents.
 CRUD | Combines the READ, WRITE and DELETE action groups.
 SEARCH | Grants permissions to search documents. Includes SUGGEST.
 SUGGEST | Grants permissions to use the suggest API. Included in the READ action group.
-CREATE\_INDEX | Grants permissions to create indices and mappings.
-INDICES\_MONITOR | Grants permissions to execute all index monitoring actions (e.g. recovery, segments info, index stats, and status).
-MANAGE\_ALIASES | Grants permissions to manage aliases.
+CREATE_INDEX | Grants permissions to create indices and mappings.
+INDICES_MONITOR | Grants permissions to execute all index monitoring actions (e.g. recovery, segments info, index stats, and status).
+MANAGE_ALIASES | Grants permissions to manage aliases.
 MANAGE | Grants all monitoring and administration permissions for indices.

docs/security-configuration/concepts.md

@@ -9,18 +9,18 @@ nav_order: 1
 
 Understanding the authentication flow is the best way to get started with configuring the Security plugin for Open Distro for Elasticsearch.
 
-1. In order to identify the user who wants to access the cluster, the Security plugin needs the user's credentials.
+1. To identify a user who wants to access the cluster, the Security plugin needs the user's credentials.
 
-   These credentials differ depending on how you've configured the plugin. For example, if you use basic authentication, these credentials are a username and password. If you use a JSON web token, these credentials are stored within the token itself. If you use TLS certificates, the credentials are the distinguished name (DN) of the certificate.
+   These credentials differ depending on how you've configured the plugin. For example, if you use basic authentication, the credentials are a user name and password. If you use a JSON web token, the credentials are stored within the token itself. If you use TLS certificates, the credentials are the distinguished name (DN) of the certificate.
 
 2. The Security plugin authenticates the user's credentials against a backend: the internal user database, Lightweight Directory Access Protocol (LDAP), Active Directory, Kerberos, or JSON web tokens.
 
-   The plugin supports chaining backends. If more than one backend is configured, the plugin tries to authenticate the user against all backends until one succeeds. A common use case is to combine the Security plugin's internal user database with LDAP/Active Directory.
+   The plugin supports chaining backends. If more than one backend is configured, the plugin tries to authenticate the user against all backends until one succeeds. A common use case is to combine the internal user database of the Security plugin with LDAP/Active Directory.
 
 3. (Optional) After an authenticator verifies the user's credentials, the plugin collects any backend roles. In most cases, this backend is LDAP/Active Directory.
 
-4. Now that the user has authenticated and any backend roles have been retrieved, the Security plugin uses the role mapping to map security roles to the user (or to the user's backend roles).
+4. After the user is authenticated and any backend roles are retrieved, the Security plugin uses role mapping to map security roles to the user (or to the user's backend roles).
 
-   If the role mapping doesn't include the user (or the user's backend roles), the user successfully authenticates, but has no permissions.
+   If the role mapping doesn't include the user (or the user's backend roles), the user is successfully authenticated but has no permissions.
 
 5. The user can now perform actions as defined by the mapped security roles. For example, a user might map to the `kibana_user` role and thus have permissions to access Kibana.