安全任务
增加多租户思想，支持资源隔离：
- 命名空间。类似于不同公司，或者不同环境如 dev 和 生产。
- 应用。如不同业务线，不同团队之间进行业务隔离
- 项目。如 ods、cdm、dwd、ads 等分层，支持同一应用内进行按照业务、功能维度组织数据和任务
重新梳理用户-角色-资源为核心的 RBAC 系统，实现更简单的页面（菜单，页面，按钮，字段）权限控制。
现有的权限配置服务端和前端是分离的，前端的权限树是前端单独维护的。通过重构，前端提供权限树的增删改查功能，服务端提供权限树接口，动态控制前端页面权限。
其次，服务端接口权限和页面权限是一对一的，接口权限和页面权限并不适合一对一的形式。服务端权限配置增加路径匹配功能
公司+部门，异或团队方式。
部门方式则允许建立子部门和平级部门，每个用户必须加入到某个部门中。团队则不允许建立层级关系。
公司+部门多见于企业管理系统，以部门+员工构成的树级结构展示、浏览全体成员。
团队方式多见于多人协作产品。团队人员往往较少，通过邀请或者申请方式，加入团队，团队内角色管理也比较扁平，往往只有 2 ～ 3 个固定角色，如管理员、成员。
组织是否具有权限，当用户加入组织后，可以自动拥有一些权限。
如果使用部门方案。当部门拥有大量人员时，如果每个用户授权都是通过角色，那么很容易出现角色爆炸问题。
增加部门权限，当用户加入部门时，自动拥有部门拥有的权限，用户离开部门，权限自动失效。
角色与职位的关系。
如果将如果把角色和职位等同，每个用户在组织内只能拥有一个职位，也即只能拥有一个角色。
用户与组织。用户是属于组织，还是加入组织？
任何用户都拥有创建角色的能力，但是为角色添加的权限不能超过自身拥有的权限。
即用户只能授予自己创建的角色通过部门与角色拥有的权限，而无法授予自身没有的权限。
前端权限分为 4 类：菜单、页面、按钮和字段权限。
菜单、页面和按钮一般会做成可见性效果，即没有权限则无法查看。
字段权限如密钥，身份证号会采用脱敏、星号或空白展示、隐藏字段等页面效果。同时字段权限旁边也会增加点击查看的按钮，可以二次请求服务端查看字段值。
服务端权限主要是接口权限和数据权限。
服务端接口使用 RESTful 风格:
- GET。查
- PUT，POST。增
- POST。改
- DELETE。删
服务端需要对访问接口的用户进行认证和鉴权，以判定是否是系统用户，是否具有接口访问权限。
数据权限分为行、列权限。二者的生效时机和处理方式都不一样。
行权限，比如数据源，用户是否具有某些数据源的访问、使用权限。
列权限，比如数据源，用户可以查看 url、用户名信息，但是无权查看密码信息。
行权限一般在查询存储系统时控制，需要把权限控制在 query 的过滤条件内。
列权限一般在接口最终返回数据的时候，过滤某些字段。
前端动态权限方案。
前端请求服务端接口获取用户拥有的菜单树，根据菜单树，动态渲染出菜单、页面、按钮和字段。
当为用户赋予角色，或者调整角色权限，都会在前端页面上直接生效。
服务端动态权限方案。
在 spring-security 中权限认证是通过 @PreAuthorize 注解实现的。判断是否具有权限是通过 SPEL 表达式实现的。spring-security 提供的可以在 SPEL 表达式中直接调用的方法有 SecurityExpressionOperations 中的 hasAuthority、hasAnyAuthority、hasRole、hasAnyRole 等方法。
通过实现 SecurityExpressionOperations 接口，覆盖对应的方法，加入通配符，就可实现类似 /api/user/** 或者 system:user:** 之类的表达式，避免每个接口都需要定义一个权限表达式。
前端与服务端动态权限组合问题
服务端接口与前端页面并不能一一对应。
服务端的接口主要分为增删改查 4 类，对于前端页面，查一般为列表页和详情页，增和改一般为弹框或者页面，删为按钮。另外就是接口复用，比如店铺接口，会在商品页面使用。
当前端权限做到动态权限时，比如新增角色，并为角色增加页面权限时，因为页面权限不能和接口权限直接构成映射，可能会出现当用户打开页面时，无法查看页面内数据，或者点击按钮，显示无权限。
为实现 scaleph 与第三方系统集成，增加外部系统认证、授权功能