4. 参与者与角色体系
在 Windchill 中，权限并不是直接授予某个具体用户的，而是通过“参与者（Participant）”这一中间层来承载。理解参与者与角色的关系，是做好权限治理的第一步。很多权限失控的根源，不是权限项本身配错了，而是参与者被滥用——把用户直接塞进权限列表、把角色当成万能钥匙、或者让一个角色承担了互相冲突的职责。
参与者类型：谁可以被授权
Windchill 的参与者是权限授予的对象，常见类型包括以下几类：
- 用户（User）：具体自然人账号，如
zhangsan。直接对用户授权最直观，但最难维护，人员变动时容易留下权限残留。 - 组（Group）：一组用户的集合，如
Design_Team。组是批量授权的主要载体，成员通过加入组间接获得权限。 - 角色（Role）：与业务职责绑定的抽象身份，如
DESIGNER、REVIEWER、APPROVER。角色本身不绑定具体人，而是通过“角色—用户/组”的映射获得成员。 - 组织（Organization）：如
R&D_Org，用于跨项目、跨库的粗粒度授权。 - 动态参与者：如“文档创建者”“当前审批人”“团队负责人”等由系统在运行时解析的身份，常用于生命周期模板中。
这五类参与者的维护成本与授权精度是相反的：用户最精确但最脆弱，组织最省事但最粗放。治理的目标不是只用某一种，而是让它们各司其职。
角色定义：把职责翻译成权限集合
角色定义的核心，是把“业务上谁该做什么”翻译成“系统里谁对什么对象有什么权限”。一个可用的角色定义至少应包含四个要素：角色名称、适用对象类型、权限集合、以及成员来源。
以某制造企业的产品数据管理为例，可以定义如下角色（示例参数，非实测结果）：
| 角色 | 适用对象 | 核心权限 | 成员来源 |
|---|---|---|---|
| DESIGNER | CAD 文档、部件 | 创建、修改、检入/检出、读取 | Design_Team 组 |
| REVIEWER | 文档、部件 | 读取、添加批注、发起评审 | Review_Pool 组 |
| APPROVER | 文档、变更单 | 读取、审批、驳回 | 由生命周期动态解析 |
| LIB_ADMIN | 库、文件夹 | 创建文件夹、设置访问控制、删除 | Admin_Group 组 |
这里有一个关键判断：角色应围绕“职责边界”划分，而不是围绕“人”划分。如果出现“张三专用角色”这种命名，说明角色定义已经退化成用户别名，失去了抽象价值。
角色分配策略：从人到角色的映射
角色分配解决的是“谁拥有这个角色”。Windchill 中常见的分配策略有三种：
- 静态分配：直接把用户或组加入角色成员列表。适合稳定、长期、职责明确的岗位，如库管理员。
- 基于团队（Team）的分配：通过上下文团队模板，在创建项目或产品库时自动带入角色成员。适合项目型协作，人员随项目走。
- 动态分配：由生命周期或工作流在运行时解析，如“当前审批人”“文档所有者”。适合审批链、会签等场景，避免提前写死人员。
实际落地时，推荐“组为主、动态为辅、用户为例外”的组合。具体来说：日常设计人员通过组获得 DESIGNER 角色；审批人通过生命周期动态解析；只有极少数临时或特殊场景才直接对用户授权，并且必须登记到期时间。
最小权限原则的落地方法
最小权限原则（Least Privilege）听起来简单，落地时却常被“图省事”打败。下面给出一套可操作的落地检查方法，核心是三个动作：收敛、隔离、复核。
收敛：把散落的用户级授权收回到组或角色。可以在访问控制列表（ACL）中排查直接以用户为主体的条目，将其替换为对应角色。例如，原本给 zhangsan 单独授予的“修改”权限，应改为通过 Design_Team 组继承 DESIGNER 角色获得。
隔离：把互相冲突的职责拆到不同角色。典型冲突是“创建者”与“审批者”由同一人担任。治理做法是让 APPROVER 角色与 DESIGNER 角色成员不重叠，或在生命周期中设置“审批人不得为创建者”的约束。
复核：定期导出角色成员与权限清单，逐条确认“是否仍然需要”。建议每季度做一次，重点关注离职人员、跨部门临时授权、以及长期未使用的角色成员。
配置示例：角色与访问控制的关系
下面是一段简化的访问控制策略示意，用于说明角色如何参与权限判定。实际 Windchill 中通过策略管理器和访问控制规则配置，此处以伪配置表达逻辑关系：
对象类型: WTDocument
访问控制规则:
规则1: 参与者=DESIGNER, 权限=READ|MODIFY|CHECKIN|CHECKOUT
规则2: 参与者=REVIEWER, 权限=READ|ADD_NOTE
规则3: 参与者=APPROVER, 权限=READ|APPROVE
规则4: 参与者=动态(创建者), 权限=READ|MODIFY
规则5: 参与者=ALL, 权限=READ (仅已发布状态)
这段配置体现了两个治理要点：第一，权限按角色分层，DESIGNER 拥有写权限，REVIEWER 和 APPROVER 只有读与特定操作权限；第二，通过动态参与者让创建者保留修改权，但审批权独立出去，避免职责重叠。
常见误区与判断依据
在参与者与角色治理中，最常见的三个误区是：
- 角色即权限：认为定义了角色就完成了授权。实际上角色只是容器，必须绑定到具体对象和上下文才生效。
- 组即角色：把组名直接当角色用，导致组既承担人员管理又承担权限管理，职责混乱。
- 一次配置永久有效：人员、组织、流程都会变，权限配置必须定期复核，否则会逐渐偏离最小权限。
判断一套角色体系是否健康，可以看三个信号：新增人员时是否只需调整组成员而无需改权限；人员离职时是否能通过移除组成员一次性回收权限；审批链中是否存在创建者与审批者同人的情况。如果这三个问题都能干净地回答，说明参与者与角色体系已经具备了基本的治理能力。
回到治理本身，参与者与角色体系的价值不在于“配得多漂亮”，而在于它能否在人员流动、组织调整、流程变更时保持稳定。一个健康的体系，应该让权限跟着职责走，而不是跟着人走。当新增一个设计人员时，你只需要把他加入 Design_Team 组；当他转岗或离职时，你只需要把他移出组。角色定义、访问控制规则、生命周期状态都不需要改动——这才是参与者与角色体系真正要达成的目标。