Add TCM LDAP authentication

doc/tooling/tcm/index.rst

@@ -41,7 +41,7 @@ to read data. LDAP authorization is supported as well.
     tcm_cluster_management/index
     tcm_cluster_data_access
     tcm_cluster_migrations
-    tcm_access_control
+    tcm_access_control/index
     tcm_audit_log
     tcm_configuration
     tcm_backend_store

doc/tooling/tcm/tcm_access_control/index.rst

@@ -0,0 +1,31 @@
+..  _tcm_access_control:
+
+Access control
+==============
+
+..  include:: ../index.rst
+    :start-after: ee_note_tcm_start
+    :end-before: ee_note_tcm_end
+
+|tcm_full_name| provides means for managing user and client applications access
+to its own functions and connected clusters:
+
+-   :ref:`Local role-based access model <tcm_access_control_rbac>` allow flexible
+    access management with user accounts created inside |tcm|.
+-   :ref:`LDAP authentication <tcm_ldap_auth>` enable authentication with an external
+    directory server.
+-   :ref:`Access control list <tcm_access_control_list>` enables fine-grained access
+    to entities stored on connected clusters.
+-   :ref:`API tokens <tcm_access_control_api_tokens>` enable integration with third-party applications.
+-   :ref:`Sessions management <tcm_access_control_sessions>` allow administrators to view and
+    revoke user sessions.
+
+
+..  toctree::
+    :maxdepth: 1
+
+    tcm_access_control_rbac
+    tcm_ldap_auth
+    tcm_access_control_list
+    tcm_api_tokens
+    tcm_sessions

doc/tooling/tcm/tcm_access_control/tcm_access_control_list.rst

@@ -0,0 +1,77 @@
+.. _tcm_access_control_list:
+
+Access control list
+===================
+
+..  include:: ../index.rst
+    :start-after: ee_note_tcm_start
+    :end-before: ee_note_tcm_end
+
+|tcm_full_name| *access control list* (*ACL*) determines user access to particular data
+and functions stored in clusters. You can use it to allow or deny access to specific
+stored objects one by one.
+
+Each ACL entry specifies privileges that a |tcm| user has on a particular
+space or a function. There are three access privileges that can be granted in the ACL:
+read, write, and execute (for stored functions only). The privileges work as follows:
+
+-   Spaces:
+
+    - ``Read``: the user sees the space and its tuples on the **Tuples** and **Explorer** pages
+    - ``Write``: the user can add new and edit existing tuples of the space
+
+-   Functions:
+
+    - ``Read``: the user sees the function on the **Functions** tab of the instance details page.
+    - ``Write``: the user can edit or delete the function
+    - ``Execute``: the user can call the function
+
+.. important::
+
+    User access to space data and stored functions is primarily defined by the
+    :ref:`cluster permissions <tcm_access_control_permissions_cluster>` ``cluster.space.data.*`` and ``cluster.func.*``.
+    ACL only increases the access control granularity to particular objects.
+    Make sure that users have these permissions before enabling ACL for them.
+
+.. _tcm_access_control_list_enable:
+
+Enabling ACL for a user
+~~~~~~~~~~~~~~~~~~~~~~~
+
+To granularly manage a user's access to particular objects in a cluster, enable
+the use of ACL in the user profile:
+
+#.  Go to **Users** and click **Edit** in the **Actions** menu of the corresponding table row.
+
+#.  In the user's **Clusters** list, add a cluster on which you want to use ACL
+    or click the pencil icon if the cluster is already on the list.
+
+#.  Select the **Use Access Control List (ACL)** checkbox and save changes.
+
+#.  Repeat two previous steps for each cluster on which you want to use ACL for this user.
+
+#.  Click **Update** to save the user account.
+
+If the user doesn't exist yet, you can do the same when creating it.
+
+.. important::
+
+    When ACL use is enabled for a user, this user loses access to all spaces and
+    functions of the selected cluster except the ones explicitly specified in the ACL.
+
+.. _tcm_access_control_list_manage:
+
+Managing ACL
+------------
+
+The tools for managing ACL are located on the **ACL** page.
+
+To add an ACL entry:
+
+#.  Click **Add**.
+#.  Select a user to which you want to grant access.
+#.  Select a cluster that stores the target object: a space or a function.
+#.  Select the target object type and enter its name.
+#.  Select the privileges you want to grant.
+
+To delete an ACL entry, click **Delete** in the **Actions** menu of the corresponding table row.

doc/tooling/tcm/tcm_access_control.rst → doc/tooling/tcm/tcm_access_control/tcm_access_control_rbac.rst

@@ -1,9 +1,9 @@
-..  _tcm_access_control:
+..  _tcm_access_control_rbac:
 
-Access control
-==============
+Role-based access control
+=========================
 
-..  include:: index.rst
+..  include:: ../index.rst
     :start-after: ee_note_tcm_start
     :end-before: ee_note_tcm_end
 
@@ -57,7 +57,7 @@ There are two types of permissions in |tcm|: *administrative* and *cluster* perm
     Cluster permissions are assigned to users individually when creating or editing them.
 
     For a fine-grained control over user access to particular spaces and functions stored
-    in clusters, there is the :ref:`access control list <tcm_access_control_acl>`.
+    in clusters, there is the :ref:`access control list <tcm_access_control_list>`.
 
 Permissions are predefined in |tcm|, there is no way to change, add, or delete them.
 The complete lists of administrative and cluster permissions in |tcm| are provided
@@ -259,145 +259,6 @@ There are the following password policy settings:
     -   **Digits (0-9)**
     -   **Symbols (such as !@#$%^&\*()_+№"':,.;=][{}`?>/.)**
 
-.. _tcm_access_control_acl:
-
-Access control list
--------------------
-
-|tcm|'s *access control list* (*ACL*) determines user access to particular data
-and functions stored in clusters. You can use it to allow or deny access to specific
-stored objects one by one.
-
-Each ACL entry specifies privileges that a |tcm| user has on a particular
-space or a function. There are three access privileges that can be granted in the ACL:
-read, write, and execute (for stored functions only). The privileges work as follows:
-
--   Spaces:
-
-    - ``Read``: the user sees the space and its tuples on the **Tuples** and **Explorer** pages
-    - ``Write``: the user can add new and edit existing tuples of the space
-
--   Functions:
-
-    - ``Read``: the user sees the function on the **Functions** tab of the instance details page.
-    - ``Write``: the user can edit or delete the function
-    - ``Execute``: the user can call the function
-
-.. important::
-
-    User access to space data and stored functions is primarily defined by the
-    :ref:`cluster permissions <tcm_access_control_permissions_cluster>` ``cluster.space.data.*`` and ``cluster.func.*``.
-    ACL only increases the access control granularity to particular objects.
-    Make sure that users have these permissions before enabling ACL for them.
-
-.. _tcm_access_control_acl_enable:
-
-Enabling ACL for a user
-~~~~~~~~~~~~~~~~~~~~~~~
-
-To granularly manage a user's access to particular objects in a cluster, enable
-the use of ACL in the user profile:
-
-#.  Go to **Users** and click **Edit** in the **Actions** menu of the corresponding table row.
-
-#.  In the user's **Clusters** list, add a cluster on which you want to use ACL
-    or click the pencil icon if the cluster is already on the list.
-
-#.  Select the **Use Access Control List (ACL)** checkbox and save changes.
-
-#.  Repeat two previous steps for each cluster on which you want to use ACL for this user.
-
-#.  Click **Update** to save the user account.
-
-If the user doesn't exist yet, you can do the same when creating it.
-
-.. important::
-
-    When ACL use is enabled for a user, this user loses access to all spaces and
-    functions of the selected cluster except the ones explicitly specified in the ACL.
-
-.. _tcm_access_control_acl_manage:
-
-Managing ACL
-~~~~~~~~~~~~
-
-The tools for managing ACL are located on the **ACL** page.
-
-To add an ACL entry:
-
-#.  Click **Add**.
-#.  Select a user to which you want to grant access.
-#.  Select a cluster that stores the target object: a space or a function.
-#.  Select the target object type and enter its name.
-#.  Select the privileges you want to grant.
-
-To delete an ACL entry, click **Delete** in the **Actions** menu of the corresponding table row.
-
-.. _tcm_access_control_sessions:
-
-Sessions
---------
-
-Administrators can view and revoke user sessions in |tcm|. All active sessions
-are listed on the **Sessions** page. To revoke a session, click **Revoke** in the
-**Actions** menu of the corresponding table row.
-
-To revoke all sessions of a user, go to **Users** and click **Revoke all sessions**
-in the **Actions** menu of the corresponding table row.
-
-.. _tcm_access_control_api_tokens:
-
-API tokens
-----------
-
-|tcm| uses the Bearer HTTP authentication scheme with *API tokens* to authenticate
-external applications' requests to |tcm|. For example, these can be Prometheus
-jobs that retrieve metrics of connected Tarantool clusters.
-
-The API tokens functionality is disabled by default. To enable it, set the
-:ref:`feature.api-token <tcm_configuration_reference_feature_api-token>` configuration option to ``true``.
-
-.. code-block:: yaml
-
-    feature:
-      api-token: true
-
-Each |tcm| API token belongs to the user that created it and has the same :ref:`access permissions <tcm_access_control_permissions>`.
-Thus, if a user has a permission to view a cluster's metrics in |tcm|, this user's
-API tokens can be used to read this cluster's metrics with Prometheus.
-
-API tokens have expiration dates that are set during the token creation and cannot
-be changed.
-
-.. _tcm_access_control_api_tokens_manage:
-
-Managing API tokens
-~~~~~~~~~~~~~~~~~~~
-
-.. note::
-
-    Each user, including **Default Admin** and other administrators, can create only
-    their own tokens. There is no way to create a token for another user.
-
-To create a |tcm| API token:
-
-#. Open the user settings by clicking the user's name in the top-right corner.
-#. Go to the **API tokens** tab and click **Add**.
-#. Specify the token expiration date and an optional description and click **Add**.
-
-The created token is shown in a dialog.
-
-.. important::
-
-    An API token is shown only once after its creation. There is no way to view
-    it again after you close the dialog. Make sure to copy the token in a safe place.
-
-To delete an API token, click **Delete** in the actions menu of the corresponding
-**API tokens** table row.
-
-Administrators can also view information about users' API tokens and delete them
-on the **Secrets** page. To open a user's secrets, click **Secrets** in the **Actions**
-menu of the corresponding **Users** table row.
 
 .. _tcm_access_control_permissions_ref:
 

doc/tooling/tcm/tcm_access_control/tcm_api_tokens.rst

@@ -0,0 +1,57 @@
+.. _tcm_access_control_api_tokens:
+
+API tokens
+==========
+
+..  include:: ../index.rst
+    :start-after: ee_note_tcm_start
+    :end-before: ee_note_tcm_end
+
+|tcm_full_name| uses the Bearer HTTP authentication scheme with *API tokens* to authenticate
+external applications' requests to |tcm|. For example, these can be Prometheus
+jobs that retrieve metrics of connected Tarantool clusters.
+
+The API tokens functionality is disabled by default. To enable it, set the
+:ref:`feature.api-token <tcm_configuration_reference_feature_api-token>` configuration option to ``true``.
+
+.. code-block:: yaml
+
+    feature:
+      api-token: true
+
+Each |tcm| API token belongs to the user that created it and has the same :ref:`access permissions <tcm_access_control_permissions>`.
+Thus, if a user has a permission to view a cluster's metrics in |tcm|, this user's
+API tokens can be used to read this cluster's metrics with Prometheus.
+
+API tokens have expiration dates that are set during the token creation and cannot
+be changed.
+
+.. _tcm_access_control_api_tokens_manage:
+
+Managing API tokens
+-------------------
+
+.. note::
+
+    Each user, including **Default Admin** and other administrators, can create only
+    their own tokens. There is no way to create a token for another user.
+
+To create a |tcm| API token:
+
+#. Open the user settings by clicking the user's name in the top-right corner.
+#. Go to the **API tokens** tab and click **Add**.
+#. Specify the token expiration date and an optional description and click **Add**.
+
+The created token is shown in a dialog.
+
+.. important::
+
+    An API token is shown only once after its creation. There is no way to view
+    it again after you close the dialog. Make sure to copy the token in a safe place.
+
+To delete an API token, click **Delete** in the actions menu of the corresponding
+**API tokens** table row.
+
+Administrators can also view information about users' API tokens and delete them
+on the **Secrets** page. To open a user's secrets, click **Secrets** in the **Actions**
+menu of the corresponding **Users** table row.