authentication

docs-2.0/3.ngql-guide/10.tag-statements/2.drop-tag.md

@@ -4,9 +4,9 @@
 
 A vertex can have one or more tags.
 
-- If a vertex has only one tag, the vertex **CANNOT** be accessed after you drop it. But its edges are available. The vertex will be deleted in the next compaction.
+- If a vertex has only one tag, the vertex **CANNOT** be accessed after you delete it. But its edges are available. The vertex will be deleted in the next compaction.
 
-- If a vertex has multiple tags, the vertex is still accessible after you drop one of them. But all the properties defined by this dropped tag **CANNOT** be accessed.
+- If a vertex has multiple tags, the vertex is still accessible after you delete one of them. But all the properties defined by this deleted tag **CANNOT** be accessed.
 
 This operation only deletes the Schema data. All the files or directories in the disk will not be deleted directly until the next compaction.
 

docs-2.0/7.data-security/1.authentication/1.authentication.md

@@ -2,21 +2,21 @@
 
 Nebula Graph replies on local authentication or LDAP authentication to implement access control.
 
-Nebula Graph creates a session when a client connects to it. The session stores information about the connection, including the user information.
+Nebula Graph creates a session when a client connects to it. The session stores information about the connection, including the user information. If the authentication system is enabled, the session will be mapped to corresponding users.
 
-By default, authentication is disabled and Nebula Graph allows connections with the username `root` and any password. If the authentication system is enabled, Nebula Graph checks a session according to the authentication configuration, and decides whether the session should be allowed or denied.
+!!! Note
 
-## Local authentication
+    By default, the authentication is disabled and Nebula Graph allows connections with the username `root` and any password.
 
-Local authentication indicates that usernames and passwords are stored locally on the server, with the passwords encrypted.
+Nebula Graph supports local authentication and LDAP authentication.
 
-### Enable local authentication
+## Local authentication
 
-1. In the `/usr/local/nebula/etc/nebula-graphd.conf` file, set `--enable_authorize=true` and save the modification.
+Local authentication indicates that usernames and passwords are stored locally on the server, with the passwords encrypted. Users will be authenticated when trying to visit Nebula Graph.
 
-  !!! note
+### Enable local authentication
 
-        `/usr/local/nebula/` is the default installation path for Nebula Graph. If you have changed it, use the actual path.
+1. Modify the `nebula-graphd.conf` file (`/usr/local/nebula/etc/` is the default path), set `--enable_authorize=true` and save the modification.
 
 2. Restart the Nebula Graph services. For how to restart, see [Manage Nebula Graph services](../../2.quick-start/5.start-stop-service.md).
 
@@ -26,10 +26,10 @@ Local authentication indicates that usernames and passwords are stored locally o
 
 ## LDAP authentication
 
-!!! Enterpriseonly
+Lightweight Directory Access Protocol (LDAP) is a lightweight client-server protocol for accessing directories and building a centralized account management system. LDAP authentication and local authentication can be enabled at the same time, but LDAP authentication has a higher priority. If the local authentication server and the LDAP server both have the information of user `Amber`, Nebula Graph reads from the LDAP server first.
 
-    LDAP authentication is an Enterprise-only feature. For how to enable LDAP, see Authenticate with an LDAP server (TODO: doc).
+### Enable LDAP authentication
 
-Lightweight Directory Access Protocol (LDAP), is a lightweight client-server protocol for accessing directories and building a centralized account management system.
+!!! Enterpriseonly
 
-LDAP authentication and local authentication can be enabled at the same time, but LDAP authentication has a higher priority. If the local authentication server and the LDAP server both have the information of user `Amber`, Nebula Graph reads from the LDAP server first.
+    LDAP authentication is an Enterprise-only feature. For how to enable LDAP, see Authenticate with an LDAP server (TODO: doc).

docs-2.0/7.data-security/1.authentication/2.management-user.md

@@ -1,50 +1,66 @@
 # User management
 
-This topic describes how to manage users and roles.
+User management is an indispensable part of Nebula Graph access control. This topic describes how to manage users and roles.
 
-By default, Nebula Graph allows connections with the username `root` and any password. After [enabling authentication](1.authentication.md), only valid users can connect to Nebula Graph and access the resources according to the [user roles](3.role-list.md).
+After [enabling authentication](1.authentication.md), only valid users can connect to Nebula Graph and access the resources according to the [user roles](3.role-list.md).
+
+!!! Note
+
+    * By default, the authentication is disabled. Nebula Graph allows connections with the username `root` and any password.
+    * Once the role of a user is modified, the user has to re-login to make the new role takes effect.
 
-Once the role of a user is modified, the user has to re-login to make the new role takes effect.
 
 ## CREATE USER
 
-The `root` user with the GOD role can run `CREATE USER` to create a new user.
+The `root` user with the **GOD** role can run `CREATE USER` to create a new user.
 
 * Syntax
 
-    ```ngql
-    CREATE USER [IF NOT EXISTS] <user_name> [WITH PASSWORD '<password>'];
-    ```
+  ```ngql
+  CREATE USER [IF NOT EXISTS] <user_name> [WITH PASSWORD '<password>'];
+  ```
 
 * Example
 
-    ```ngql
-    nebula> CREATE USER user1 WITH PASSWORD 'nebula';
-    ```
+  ```ngql
+  nebula> CREATE USER user1 WITH PASSWORD 'nebula';
+  ```
 
 ## GRANT ROLE
 
-Users with the GOD role or the ADMIN role can run `GRANT ROLE` to assign a built-in role in a graph space to a user. For more information about Nebula Graph built-in roles, see [Roles and privileges](3.role-list.md)
+Users with the **GOD** role or the **ADMIN** role can run `GRANT ROLE` to assign a built-in role in a graph space to a user. For more information about Nebula Graph built-in roles, see [Roles and privileges](3.role-list.md).
 
-!!! note
+* Syntax
+
+  ```ngql
+  GRANT ROLE <role_type> ON <space_name> TO <user_name>;
+  ```
 
-    If the target user is connected to Nebula Graph when running `GRANT ROLE`, the new role takes effect when the user logs out and logs in again.
+* Example
+
+  ```ngql
+  nebula> GRANT ROLE USER ON basketballplayer TO user1;
+  ```
+
+## REVOKE ROLE
+
+Users with the **GOD** role or the **ADMIN** role can run `REVOKE ROLE` to revoke the built-in role of a user in a graph space. For more information about Nebula Graph built-in roles, see [Roles and privileges](3.role-list.md).
 
 * Syntax
 
-    ```ngql
-    GRANT ROLE <role_type> ON <space_name> TO <user_name>;
-    ```
+  ```ngql
+  REVOKE ROLE <role_type> ON <space_name> FROM <user_name>;
+  ```
 
 * Example
 
-    ```ngql
-    nebula> GRANT ROLE USER ON basketballplayer TO user1;
-    ```
+  ```ngql
+  nebula> REVOKE ROLE USER ON basketballplayer FROM user1;
+  ```
 
 ## SHOW ROLES
 
-Run `SHOW ROLES` to list the roles in a graph space.
+Users can run `SHOW ROLES` to list the roles in a graph space.
 
 * Syntax
 
@@ -63,99 +79,79 @@ Run `SHOW ROLES` to list the roles in a graph space.
   +---------+-----------+
   ```
 
-## REVOKE ROLE
-
-Users with the GOD role or the ADMIN role can run `REVOKE ROLE` to revoke a user's role in a graph space.
-
-!!! note
-
-    If the target user is connected to Nebula Graph when running `REVOKE ROLE`, the old role still takes effect until the user logs out.
-
-* Syntax
-
-    ```ngql
-    REVOKE ROLE <role_type> ON <space_name> FROM <user_name>;
-    ```
-
-* Example
-
-    ```ngql
-    nebula> REVOKE ROLE USER ON basketballplayer FROM user1;
-    ```
-
 ## CHANGE PASSWORD
 
-With the correct username and password, users can run `CHANGE PASSWORD` to set a new password for a user.
+Users can run `CHANGE PASSWORD` to set a new password for a user. The old password is needed when setting a new one.
 
 * Syntax
 
-    ```ngql
-    CHANGE PASSWORD <user_name> FROM '<old_password>' TO '<new_password>';
-    ```
+  ```ngql
+  CHANGE PASSWORD <user_name> FROM '<old_password>' TO '<new_password>';
+  ```
 
 * Example
 
-    ```ngql
-    nebula> CHANGE PASSWORD user1 FROM 'nebula' TO 'nebula123';
-    ```
+  ```ngql
+  nebula> CHANGE PASSWORD user1 FROM 'nebula' TO 'nebula123';
+  ```
 
 ## ALTER USER
 
-The `root` user with the GOD role can run `ALTER USER` to set a new password for a user.
+The `root` user with the **GOD** role can run `ALTER USER` to set a new password for a user. The old password is not needed when setting a new one.
 
 * Syntax
 
-    ```ngql
-    ALTER USER <user_name> WITH PASSWORD '<password>';
-    ```
+  ```ngql
+  ALTER USER <user_name> WITH PASSWORD '<password>';
+  ```
 
 * Example
 
-    ```ngql
-    nebula> ALTER USER user1 WITH PASSWORD 'nebula';
-    ```
+  ```ngql
+  nebula> ALTER USER user1 WITH PASSWORD 'nebula';
+  ```
 
 ## DROP USER
 
-The `root` user with the GOD role can run `DROP USER` to remove a user.
+The `root` user with the **GOD** role can run `DROP USER` to remove a user.
 
 !!! note
 
-    Removing a user does not close the user's current session, and the user role still takes effect in the session until the session is closed.
+    Removing a user does not close the current session of the user, and the user role still takes effect in the session until the session is closed.
 
 * Syntax
 
-    ```ngql
-    DROP USER [IF EXISTS] <user_name>;
-    ```
+  ```ngql
+  DROP USER [IF EXISTS] <user_name>;
+  ```
 
 * Example
 
-    ```ngql
-    nebula> DROP USER user1;
-    ```
+  ```ngql
+  nebula> DROP USER user1;
+  ```
 
 ## SHOW USERS
 
-The `root` user with the GOD role can run `SHOW USERS` to list all the users.
+The `root` user with the **GOD** role can run `SHOW USERS` to list all the users.
 
 * Syntax
 
-    ```ngql
-    SHOW USERS;
-    ```
+  ```ngql
+  SHOW USERS;
+  ```
 
 * Example
 
-    ```ngql
-    nebula> SHOW USERS;
-    +-----------+
-    | Account   |
-    +-----------+
-    | "test1"   |
-    +-----------+
-    | "test2"   |
-    +-----------+
-    | "test3"   |
-    +-----------+
-    ```
+  ```ngql
+  nebula> SHOW USERS;
+  +-----------+
+  | Account   |
+  +-----------+
+  | "test1"   |
+  +-----------+
+  | "test2"   |
+  +-----------+
+  | "test3"   |
+  +-----------+
+  ```

docs-2.0/7.data-security/1.authentication/3.role-list.md

@@ -1,54 +1,70 @@
 # Roles and privileges
 
-A role is a collection of privileges. You can assign a role to a user for access control.
+A role is a collection of privileges. You can assign a role to a [user](2.management-user.md) for access control.
 
 ## Built-in roles
 
 Nebula Graph does not support custom roles, but it has multiple built-in roles:
 
 * GOD
-  * GOD is the original role with all privileges not limited to graph spaces. It is similar to `root` in Linux and `administrator` in Windows.
+
+  * GOD is the original role with **all privileges** not limited to graph spaces. It is similar to `root` in Linux and `administrator` in Windows.
+
   * When the Meta Service is initialized, the one and only GOD role user `root` is automatically created with the password `nebula`.
-  !!! note
 
-      Modify the password for `root` as soon as possible for security.
-  * The default username `root` is immutable.
-  * If [authentication](1.authentication.md) is disabled, you can use any username and password to connect to Nebula Graph. This user is regarded as the GOD role.
+  !!! caution
+
+      Modify the password for `root` timely for security.
+
+  * One cluster can only have one user with the GOD role. This user can manage all graph spaces in a cluster.
+
+  * Manual authorization of the God role is not supported. Only the `root` user with the default God role can be used.
 
 * ADMIN
-  * An ADMIN role can read and write both the Schema and the data in a specific graph space.
+
+  * An ADMIN role can **read and write** both the Schema and the data in a specific graph space.
+
   * An ADMIN role of a graph space can grant DBA, USER, and GUEST roles in the graph space to other users.
 
+    !!! note
+
+        Only roles lower than ADMIN can be authorized to other users.
+
 * DBA
-  * A DBA role can read and write both the Schema and the data in a specific graph space.
+
+  * A DBA role can **read and write** both the Schema and the data in a specific graph space.
+
   * A DBA role of a graph space CANNOT grant roles to other users.
 
 * USER
-  * A USER role can read and write data in a specific graph space.
-  * The Schema information is read-only to the USER roles in a graph space.
+
+  * A USER role can **read and write** data in a specific graph space.
+
+  * The Schema information is **read-only** to the USER roles in a graph space.
 
 * GUEST
-  * A GUEST role can only read the Schema and the data in a specific graph space.
+  * A GUEST role can **only read** the Schema and the data in a specific graph space.
 
 !!! note
 
-    A user can have only one role in a graph space.
+    * Nebula Graph does not support custom roles. Users can only use the default built-in roles.
+    * A user can have only one role in a graph space. For authenticated users, see [User management](2.management-user.md).
 
 ## Role privileges and allowed nGQL
 
 The privileges of roles and the nGQL statements that each role can use are listed as follows.
 
-Privilege|God|Admin|DBA|User|Guest|Allowed nGQL|
-|-|-|-|-|-|-|-|
-|Read space|Y|Y|Y|Y|Y|`USE`, `DESCRIBE SPACE`|
-|Write space|Y|||||`CREATE SPACE`, `DROP SPACE`, `CREATE SNAPSHOT`, `DROP SNAPSHOT`, `BALANCE DATA`, `BALANCE DATA STOP`, `BALANCE DATA REMOVE`, `BALANCE LEADER`, `ADMIN`, `CONFIG`, `INGEST`, `DOWNLOAD`, `SUBMIT JOB COMPACT`, `SUBMIT JOB FLUSH`, `SUBMIT JOB STATS`, `STOP JOB`, `RECOVER JOB`, `BUILD TAG INDEX`, `BUILD EDGE INDEX`|
-|Read schema|Y|Y|Y|Y|Y|`DESCRIBE TAG`, `DESCRIBE EDGE`, `DESCRIBE TAG INDEX`, `DESCRIBE EDGE INDEX`|
-|Write schema|Y|Y|Y|||`CREATE TAG`, `ALTER TAG`, `CREATE EDGE`, `ALTER EDGE`, `DROP TAG`, `DROP EDGE`, `CREATE TAG INDEX`, `CREATE EDGE INDEX`, `DROP TAG INDEX`, `DROP EDGE INDEX`|
-|Write user|Y|||||`CREATE USER`, `DROP USER`, `ALTER USER`|
-|Write role|Y|Y||||`GRANT`, `REVOKE`|
-|Read data|Y|Y|Y|Y|Y|`GO`, `SET`, `PIPE`, `MATCH`, `ASSIGNMENT`, `LOOKUP`, `YIELD`, `ORDER BY`, `FETCH VERTICES`, `Find`, `FETCH EDGES`, `FIND PATH`, `LIMIT`, `GROUP BY`, `RETURN`|
-|Write data|Y|Y|Y|Y||`INSERT VERTEX`, `UPDATE VERTEX`, `INSERT EDGE`, `UPDATE EDGE`, `DELETE VERTEX`, `DELETE EDGES`, `DELETE TAG`|
-|Show operations|Y|Y|Y|Y|Y|`SHOW`, `CHANGE PASSWORD`|
+  |Privilege|God  |Admin|DBA|User|Guest|Allowed nGQL|
+  |:---|:---|:---|:---|:---|:---|:---|
+  |Read space|Y|Y|Y|Y|Y|`USE`, `DESCRIBE SPACE`|
+  |Write space|Y|||||`CREATE SPACE`, `DROP SPACE`, `CREATE SNAPSHOT`, `DROP SNAPSHOT`, `BALANCE DATA`, `BALANCE DATA STOP`, `BALANCE DATA REMOVE`, `BALANCE LEADER`, `ADMIN`, `CONFIG`, `INGEST`, `DOWNLOAD`, `SUBMIT JOB COMPACT`, `SUBMIT JOB FLUSH`, `SUBMIT JOB STATS`, `STOP JOB`, `RECOVER JOB`, `BUILD TAG INDEX`, `BUILD EDGE INDEX`|
+  |Read schema|Y|Y|Y|Y|Y|`DESCRIBE TAG`, `DESCRIBE EDGE`, `DESCRIBE TAG INDEX`, `DESCRIBE EDGE INDEX`|
+  |Write schema|Y|Y|Y|||`CREATE TAG`, `ALTER TAG`, `CREATE EDGE`, `ALTER EDGE`, `DROP TAG`, `DROP EDGE`, `CREATE TAG INDEX`, `CREATE EDGE INDEX`, `DROP TAG INDEX`, `DROP EDGE INDEX`|
+  |Write user|Y|||||`CREATE USER`, `DROP USER`, `ALTER USER`|
+  |Write role|Y|Y||||`GRANT`, `REVOKE`|
+  |Read data|Y|Y|Y|Y|Y|`GO`, `SET`, `PIPE`, `MATCH`, `ASSIGNMENT`, `LOOKUP`, `YIELD`, `ORDER BY`, `FETCH VERTICES`, `Find`, `FETCH EDGES`, `FIND PATH`, `LIMIT`, `GROUP BY`, `RETURN`|
+  |Write data|Y|Y|Y|Y||`INSERT VERTEX`, `UPDATE VERTEX`, `INSERT EDGE`, `UPDATE EDGE`, `DELETE VERTEX`, `DELETE EDGES`, `DELETE TAG`|
+  |Show operations|Y|Y|Y|Y|Y|`SHOW`, `CHANGE PASSWORD`|
 
 !!! note