用户与权限设计

目前我们已经有一些服务，主要基于ECS,结合现有的服务和现状,做出以下设计和考量。

权限方案比较

AWS IAM

特点：

与现有的AWS服务深度集成
基于策略(Policy)的细粒度权限控制
支持用户、组、角色和资源级别的权限
支持条件化权限（如IP限制、时间限制）

优势：

细粒度的资源访问控制
适合云原生架构
支持临时凭证和联合身份

劣势：

主要针对AWS服务,严格遵守AWS的范式,深度绑定
配置复杂度高
学习曲线陡峭

RuoYi-Admin + OPA

用户管理在Foxx_Web_Service 使用的开源的ruoyi框架提供

特点：

基于角色(RBAC)的权限模型
内置用户管理、菜单管理功能
OPA提供灵活的策略评估

优势：

ruoyi框架本身开箱即用的管理界面
在中小规模系统中已于实现
权限管理界面友好

劣势：

扩展性受限
多租户支持不够强大
与云原生架构集成需要额外工作,可能需要深度定制源码

Keycloak + OPA

特点：

完整的身份认证与授权解决方案
支持多种认证协议(OIDC, OAuth2, SAML)
细粒度的权限控制
多租户支持(Realm)

优势：

强大的身份管理能力
与云原生架构兼容性好
可扩展的权限模型

劣势：

部署和维护相对复杂
资源消耗较高
配置学习曲线陡峭

方案选择与设计

基于系统现状（包括门户网站、数字孪生系统和其它服务），推荐采用 Keycloak + OPA 方案：

架构图

身份验证流程详解

实现方案

身份管理
- 部署Keycloak作为主要身份提供者
- 定义用户角色层次：系统管理员 >项目租户>楼栋管理员>访客。
认证流程
- 基于OAuth2/OIDC实现SSO
- 支持多种认证方式（密码、证书、MFA）
- JWT token包含必要权限信息
授权模型
- 使用OPA实现RBAC+ABAC混合模型
- 权限粒度：系统级、租户级、资源级
- 动态权限评估，支持条件表达式
租户隔离
- 基于Keycloak Realm实现租户隔离
- 数据隔离通过租户ID实现
- 跨租户操作需特殊授权

权限模型示例

根据业务初步粗略的分为以下角色:
系统管理员 > 项目租户 > 楼栋管理员 > 访客。

角色定义

json

{
  "roles": {
    "system_admin": {
      "description": "系统管理员，拥有全部权限",
      "permissions": [
        "*:*"
      ]
    },
    "project_admin": {
      "description": "项目租户，管理整个项目的所有资源",
      "permissions": [
        "project:*",
        "building:*",
        "robot:*",
        "cicd:*",
        "dt:*",
        "logs:*"
      ]
    },
    "building_admin": {
      "description": "楼栋管理员，管理指定楼栋内的资源",
      "permissions": [
        "building:read",
        "building:manage",
        "robot:read",
        "robot:execute",
        "dt:read",
        "logs:read"
      ]
    },
    "viewer": {
      "description": "访客，基础查看权限",
      "permissions": [
        "building:read",
        "robot:read",
        "dt:read",
        "logs:read"
      ]
    }
  }
}

OPA策略示例

rego

package authz

import input

default allow = false

# 系统管理员有所有权限
allow {
  input.user.role == "system_admin"
}

# 项目租户可以管理其项目内的所有资源
allow {
  input.user.role == "project_admin"
  input.user.project_id == input.resource.project_id
}

# 楼栋管理员可以管理其负责的楼栋资源
allow {
  input.user.role == "building_admin"
  input.resource.building_id == input.user.building_id
  input.user.project_id == input.resource.project_id
}

# 多楼栋管理权限
allow {
  input.user.role == "building_admin"
  building_ids := input.user.building_ids
  building_id := input.resource.building_id
  building_ids[_] == building_id
  input.user.project_id == input.resource.project_id
}

# 访客只能查看被授权的项目资源
allow {
  input.user.role == "viewer"
  input.user.project_id == input.resource.project_id
  input.action == "read"
}

实施步骤

第一阶段：基础认证
- 部署Keycloak(已在本地服务器中验证完成)
- 集成现有用户系统
- 实现基本登录功能
第二阶段：授权基础
- 部署OPA
- 实现基本RBAC模型
- API网关集成
第三阶段：高级功能
- 多租户隔离
- 细粒度权限控制
- 审计日志
第四阶段：平台化
- 权限管理界面
- 自助服务功能
- 动态策略更新

与现有系统集成

门户网站：通过OIDC或OAuth2集成Keycloak，前端使用JWT令牌访问后端API
数字孪生系统：实现基于资源的访问控制，资源权限通过OPA评估
AWS服务：配置Keycloak与AWS IAM的联合身份，实现无缝衔接
API网关：作为所有服务的统一入口，集成认证和授权功能
零散服务：通过SDK或中间件方式集成权限验证

此设计方案利用Keycloak强大的认证能力和OPA灵活的授权策略，适应现有的分布式架构，同时满足未来的扩展需求。

用户与权限设计 ​

权限方案比较 ​

AWS IAM ​

RuoYi-Admin + OPA ​

Keycloak + OPA ​

方案选择与设计 ​

架构图 ​

实现方案 ​

权限模型示例 ​

角色定义 ​

OPA策略示例 ​

实施步骤 ​

与现有系统集成 ​