Web应用后端API全局用户授权规则实现方案咨询

一、重新适配ABAC落地思路 #

你之前尝试ABAC未满足需求，大概率是没把属性匹配和规则引擎的灵活性结合到位。针对你的示例规则user(*) has edit to org(*) if user.id == org.owner，可以这样落地：

• 定义核心属性：用户侧保留id，组织侧保留owner（组织所有者ID）
• 抽象授权决策API：设计POST /auth/check接口，请求体结构如下：

  {
    "subject": {"type": "user", "id": "u_123", "attributes": {"id": "u_123"}},
    "action": "edit",
    "resource": {"type": "org", "id": "org_456", "attributes": {"owner": "u_123"}}
  }
  

• 规则引擎层：将授权规则配置为可解析的表达式（比如Groovy或自定义QL语法），示例规则可存储为subject.attributes.id == resource.attributes.owner。决策时引擎直接计算表达式结果，返回allow或deny。

二、分层扩展的架构设计 #

要实现长期可扩展，建议拆分三层API：

• 规则配置层：提供GET /auth/rules、POST /auth/rules、PUT /auth/rules/{id}接口，支持新增、修改、查询授权规则。每个规则包含规则ID、描述、主体类型、动作、资源类型、匹配表达式、生效状态。
• 决策执行层：核心是POST /auth/check接口，同时支持批量权限检查（请求体改为数组形式），返回每个请求的独立决策结果。
• 属性获取层：设计GET /auth/attributes/{type}/{id}接口，用于从业务服务拉取主体/资源的属性（比如根据组织ID获取所有者ID），决策时自动调用该层补全属性数据。

三、RBAC+ABAC混合简化方案 #

如果纯ABAC复杂度较高，可以用RBAC做基础权限判断，ABAC做细粒度补充：

• 先通过RBAC校验用户是否持有org_edit角色
• 再通过ABAC规则校验用户是否为目标组织的所有者
• 接口设计上，POST /auth/check可同时接收角色和条件参数：

  {
    "userId": "u_123",
    "action": "edit",
    "resourceType": "org",
    "resourceId": "org_456",
    "requiredRoles": ["org_edit"],
    "additionalConditions": ["user.id == org.owner"]
  }
  

四、性能优化建议 #

• 缓存决策结果：对相同的「主体-动作-资源」组合，缓存5-10分钟，避免重复计算
• 预加载核心属性：将用户、组织的高频属性缓存到授权服务本地，减少跨服务调用开销

内容的提问来源于stack exchange，提问作者Azeroth