Search before asking

[X] I had searched in the feature and found no similar feature requirement.

Description

I know the community is doing management platform，and the auth is an essential module. I am designing the auth module for seatunnel, and complete the architectural design in few days.

Usage Scenario

No response

Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Background

Permission is an indispensable module for every system. As seatunnel is used by more and more companies, the blank of permission control must be a pain point for some small and medium-sized companies. They have to do additional permission control on seatunnel. , which undoubtedly increases the threshold for use of seatunnel, so it is very necessary for seatunnel to have its own rights management capabilities.

Target

It can provide a sufficiently general permission management mode, which can support the permission management and control more modules with the development of seatunnel.

Users, roles, permissions, resources, the CRUD of each of these four objects
Matching between users and roles, roles and permissions, permissions and resources
Authenticate through users and resources

Architectural Design

User service: User information can be synchronized from LDAP, or added by system registration.
Resource service: Provides the ability to add, delete, modify, and search resources. Resources support multi-level, and resources have the attributes of grade and person in charge. It depends on the functions such as permission application are required in the future. When applying for permissions, different approval templates will be selected according to the basic attributes of the resource. This part will have lower priority.
Authorization service: Provide the most basic authentication service based on Casbin, and return T/F for users, resources and operation types passed by Plugin. In addition, the service provides various types of permission models, such as RBAC/ABAC/ACL, etc. As far as the current seatunnel is concerned, the general RBAC model should suffice.
Permission portal: Through WebUi, users, roles, resources, applications and other objects can be managed.
Permission component: The open source component Casbin is used here, that is, the third-party open source access control library we rely on. We will not talk about Casbin. You can refer to the Casbin official website.

Core

Based on the RBAC model, permission control has three elements: resources, roles, and permissions. Users are not directly controlled by permissions. Authorization can only go to the role, not the user level; and it is usually divided into administrator roles and ordinary user roles. The administrator role has all the permissions of the ordinary user role. , and have administrative rights;

Because the current product does not have a plan for role management, we can simply divide the roles into ordinary roles and management roles, and determine the permission boundaries of the two.

The permission scope of common roles is to view and edit resources of their own users.
Admin users can view, edit and delete resources created by any user.

According to this logic, basically every time you add a new user, you need to add a common role. Each common role corresponds to a batch of resources to add, delete, modify and check permissions, but the scenario of this approach is relatively simple. Once a single task needs to be specially processed, it cannot be applied. This requires a role management and control platform to define the relationship between roles and permissions. At present, in order to achieve isolation between users, this can only be done. But this is only temporary. When there is a role management module, more flexible settings can be made, such as customizing the relationship between users and roles, and the relationship between roles and permissions.

Role management (not done in this issue)
1. Add roles
2. Edit roles
3. Delete role
4. View the role (the current version is not planned, but this part of the ability can be provided)
User management
1. Add user
2. Delete user
3. Edit user information
4. View user list
Resources management
1. Add resources
2. Edit the resource
3. Delete resources
4. View resources

Scope of control

It is clear which operations need to be controlled by permissions. Based on personal understanding, the current version includes the following:

User management: Only the administrator role has the authority to manage users The tabs and pages of user management are generally only visible to administrators, and only administrators have the following permissions.
1. Add user permissions
2. Edit User Permissions
3. Remove user rights
4. View User Permissions
Datapipes
1. createPip permission
2. editPip permission
3. deletePip permission
4. readPip permission
5. execute permission: execute includes operations such as start/stop/kill/pause.

In summary, the permission types of the core modules basically include four permissions: read/write/delete/execute.

seatunnel 权限

背景

权限对于每个系统都是一个必不可少的模块，随着seatunnel被越来越多的公司使用，权限管控的空白，一定是部分中小型公司的痛点，他们不得不在seatunnel之上额外做权限管控，这无疑增加了seatunnel的使用门槛，因此seatunnel非常有必要拥有自己的权限管理能力。

目标

能够提供一种足够通用的权限管理模式，可以随着seatunnel的发展，支撑更多模块的权限管控。

用户、角色、权限、资源，这四种对象各自的CRUD
用户与角色、角色与权限、权限与资源的匹配
通过用户与资源进行鉴权

概要设计

用户服务：用户信息可以从LDAP同步，或者系统注册加入。
资源服务：提供资源的增删改查能力，资源支持多层级，资源具有等级、负责人属性。看后续是否需要权限申请等功能，在进行权限申请时，会根据资源的基本属性选择不同的审批模板。这部分优先级会比较低。
权限服务：基于Casbin提供最基础的鉴权服务，通过Plugin传递过来的用户与资源与操作类型，返回T/F。

此外，该服务提供多种类型的权限模型，比如RBAC/ABAC/ACL等。就目前seatunnel而言，一般的RBAC模型应该足够了。
权限门户：通过WebUi，可以对用户、角色、资源、应用等对象进行管理。
权限组件：这里选用开源组件Casbin，也就是我们依赖的第三方开源访问控制库来说，有关Casbin就不展开说，可以参考Casbin官网。

权限核心

基于RBAC模型，权限管控有三个元素：资源、角色、权限。而用户并不是权限直接管控的对象，授权/鉴权只会到角色，不会到用户级别；并且通常会分为管理员角色和普通用户角色，管理员角色除了拥有普通用户角色的所有权限外，还有拥有管理权限；

因为当前产品并没有关于角色管理的规划，所以可以先将简单将角色分为普通角色和管理角色，并确定两者的权限边界。

普通角色的权限范围为可以查看和编辑自己用户的资源。
管理员用户可以查看、编辑、删除任何用户所建的资源。

按照这个逻辑，基本上每新增用一个用户，就需要新增一个普通角色。每个普通角色对应一批资源的增删改查权限，但是这种做法的场景比较单一，一旦需要对单个任务做特殊处理，就无法适用，这就需要角色管控平台，来定义角色和权限之间的关系，当前所以为了做到用户之间的隔离，只能如此。但这只是暂时的，当有角色管理模块时，就可以做更多灵活的设置，比如自定义用户和角色的关系，以及角色和权限的关系。

权限核心能力

角色管理（本期不做）
1. 添加角色
2. 编辑角色
3. 删除角色
4. 查看角色（当前版本没有规划，但是可以提供这部分能力）
添加用户
1. 添加用户
2. 删除用户
3. 编辑用户信息
4. 查看用户列表
添加资源
1. 添加资源
2. 编辑资源
3. 删除资源
4. 查看资源

管控范围

明确哪些操作是需要被权限管控的，基于个人理解，当前版本包含以下内容：

用户管理：只有管理员角色有用户管理的权限

用户管理的tab和页面一般是由管理员才能可见，也只有管理员包含以下权限。
1. 新增用户权限
2. 编辑用户权限
3. 删除用户权限
4. 查看用户权限
Datapipes
1. createPip权限
2. editPip权限
3. deletePip权限
4. readPip权限
5. execute权限：execute包括start/stop/kill/pause等操作。

综上所述核心模块的权限类型，基本就包含：read/write/delete/execute四种权限。

apache / seatunnel

[Feature][Auth] Auth Model for seatunnel #2188