REST 层授权

REST 层授权为插件和扩展 API 请求提供了额外的安全层级，通过在 REST 层提供授权检查机制。此安全层级位于传输层之上，提供了一种补充的授权方法，而不替换、修改或以任何方式改变传输层上的同一过程。REST 层授权最初是为了满足对扩展的授权检查需求而创建的，这些扩展不在传输层进行通信。然而，该功能也可供希望在为 UDB-SX 创建未来插件时使用它的开发者使用。

对于使用 REST 层授权的用户，分配角色、映射用户和角色以及插件和扩展的一般使用方法保持不变——唯一的额外要求是用户熟悉新的权限方案。

使用 REST 层进行授权的好处包括能够在 REST 层授权请求并过滤掉未经授权的请求。因此，这减少了传输层的处理负担，同时允许对 API 访问进行细粒度控制。

一些读取操作，例如滚动，管理状态。因此，建议使用 Security 插件权限来控制读写访问，而不是允许/阻止 HTTP 请求动词。

必须启用 Security 插件才能使用 REST 层授权。

NamedRoute

REST 层授权使集群管理员能够授予或撤销对集群中特定端点的访问权限。为此，资源的路由使用一个唯一的名称。

为了促进 REST 层授权，UDB-SX 引入了 NamedRoute 的概念用于路由注册。对于开发者，此标准要求一种新的路由注册方法，该方法使用唯一名称。虽然传输操作通常由方法名称、路径部分和相应的传输操作组成，但这种新实现要求方法名称、路径部分和路由的唯一名称。顾名思义，它必须在所有插件和扩展中是唯一的，或者换句话说，不能注册到任何其他路由。

例如，考虑以下用于异常检测资源的路径：

_/detectors/<detectorId>/profile

对于扩展，可以通过引用资源的 settings.yml 文件中的 routeNamePrefix 值（在这种情况下为 ad）并将其添加到路由中以完成唯一名称来创建 NamedRoute。结果如下例所示：

ad:detectors/profile

对于插件，可以使用插件名称代替 routeNamePrefix 值。

然后，路由名称可以以与传统权限相同的方式映射到角色。如下例所示：

ad_role:
  reserved: true
  cluster_permissions:
    - 'ad:detectors/profile'

映射用户和角色

使用 NamedRoute 映射用户和角色的方式没有变化。此外，新的权限格式与现有配置兼容。本节提供了一个示例，说明用户和角色映射在旧版和 NamedRoute 配置中如何显示，以及它们如何为操作授权已注册的路由。

当用户发起 REST 请求时，会检查用户的角色，并评估与用户关联的每个权限，以确定是否与分配给路由的唯一名称匹配，或者与路由注册期间定义的任何旧版操作匹配。用户可以映射到包含为唯一名称或旧版操作格式化的权限的角色。考虑以下用于虚构插件 abc 的角色：

abcplugin_read_access:
   reserved: true
   cluster_permissions:
     - 'cluster:admin/UDB-SX/abcplugin/route/get'

同时考虑以下角色映射：

abcplugin_read_access:
	 reserved: true
	 users:
		 - "user-A"

如果 user-A 向路由 /_plugins/_abcplugin/route/get 发起 REST API 调用，则该用户被授予对该操作的授权。但是，对于不同的路由，例如 /_plugins/_abcplugin/route/delete，请求将被拒绝。

相同的逻辑也适用于使用路由唯一名称和 NamedRoute 概念的角色和角色映射。考虑以下用于同一插件 abc 的角色：

abcplugin_read_access_nr:
   reserved: true
   cluster_permissions:
     - 'abcplugin:routeGet'
     - 'abcplugin:routePut'
     - 'abcplugin:routeDelete'

同时考虑以下角色映射：

abcplugin_read_access_nr:
	 reserved: true
	 users:
		 - "user-B"

在这第二种情况下，如果 user-B 向任何路由 /_plugins/_abcplugin/route/get、/_plugins/_abcplugin/route/put 或 /_plugins/_abcplugin/route/delete 发起 REST API 调用，则该用户被授予对该操作的授权。