Permission 与数据访问控制
Aras Innovator 的标准数据授权由 Permission 与 Identity 共同表达。 Permission 回答“哪些身份可以对已有 Item 做什么”， 而 Can Add、TOC Access、Lifecycle Transition 和 Workflow Assignment 分别控制其他入口。
安全配置的目标不是让按钮看起来正确，而是让服务器对直接请求也作出正确决定。
适用版本与资料基线
- 标准 Permission、Identity、
permission_id、状态权限和私有权限的概念跨版本相对稳定。 - 字段、菜单与训练步骤以 Aras Innovator R31、2024 年 12 月版官方培训资料为基线。
- R35/R39 现代服务器运行时分别为 .NET 8.0.1 与 .NET 10，但运行时升级不会把客户端可见性变成安全边界。
- MAC、DAC、User Visibility Policy 等高级安全能力受 Release、License 和配置影响，本文只说明边界，不替代其专项指南。
最小心智模型
一次访问决定至少涉及四个问题：
以“设计文档”为例：
Document Authors有 Get、Update；Document Reviewers有 Get；World没有任何权利；- 进入 Released 状态后，Lifecycle State 切换为只读 Permission。
用户在作者组和审核组中的权利会累积， 但 Item 任意时刻只引用一个当前 Permission。
核心机制
认证与授权
| 概念 | 问题 | 常见组件 |
|---|---|---|
| Authentication | 请求者是谁 | OAuth、本地登录、Windows/外部身份提供程序 |
| Authorization | 请求者可以做什么 | Identity、Permission、Lifecycle、Team |
认证成功不代表可以读取全部数据。 API 获取到令牌也不代表绕过 Permission；请求仍应以该用户的有效身份执行。
Permission 是可复用定义
Permission Item 包含多行 Access， 每行选择一个 Identity 并授予一组权利。 同一个 Permission 可以被许多业务 Item 共用。
Item 的 permission_id 指向当前生效的 Permission。 同一时刻不是“多个 Permission 叠加”， 而是当前 Permission 内各有效 Identity 的授权行进行累积判断。
ItemType 的 Permissions 关系用于列出该类型允许使用的 Permission， 并应指定一个默认 Permission，供新 Item 初始化。
标准权利
| 权利 | 作用 | 不代表什么 |
|---|---|---|
| Can Discover | 可以知道 Item 存在 | 不能打开完整 Item |
| Get | 可以读取并打开 Item | 不自动允许修改 |
| Update | 可以修改 Item | 不自动允许 Promote 或删除 |
| Delete | 可以删除 Item | 不替代业务保留策略 |
| Can Change Access | 可以切换允许的 Permission 或创建私有权限 | 不能选择 ItemType 未允许的任意 Permission |
| Show Permission Warnings | 在发现受限结果时显示相应提示 | 不授予数据读取权 |
Get 包含发现 Item 所需的能力。 只有 Can Discover 而没有 Get 时，用户可以在支持的界面中看到有限标识， 但不能打开完整表单。
Can Discover 与 Enforce Discovery
Can Discover 的受控发现行为需要目标 ItemType 启用 Enforce Discovery。 以 R31 基线理解：
| Can Discover | Get | 预期结果 |
|---|---|---|
| 否 | 否 | Item 从结果中省略 |
| 是 | 否 | 可见有限搜索信息，但不能打开表单 |
| 任意 | 是 | 可读取完整 Item |
在关系网格中，受限 Item 可能显示为 Restricted 占位信息， 具体呈现受客户端和 Release 影响。 安全验收应检查实际数据是否泄露，而不是只检查占位文字。
默认 Permission 与状态权限
新建 Item 通常使用 ItemType 上标记为默认的 Permission。 当 Item 进入配置了 State Permission 的生命周期状态时， 平台将该 Permission 应用于 Item。
如果后续状态没有配置 State Permission， 不能理解为“自动恢复 ItemType 默认值”；R31 培训基线中会继续沿用当前 Permission， 直到另一个状态显式设置新的 State Permission。
State Permission 必须位于 ItemType 允许的 Permissions 集合中。 因此生命周期设计与权限设计必须一起评审。
Can Change Access
拥有 Can Change Access 的用户可以通过 Item 的 Permissions 操作切换访问定义。 可选范围由 ItemType 的 Permissions 关系限制。
这项权利影响谁可以再次授权别人，通常比普通 Update 更敏感。 不要把它默认授予所有编辑者。
私有权限
Private Permission 是为单条 Item 创建的专属 Permission，适合少量例外授权。
R31 基线下需要同时满足：
- ItemType 启用 Allow Private Permissions；
- 当前用户通过现有 Permission 具有 Can Change Access。
创建私有权限后，该 Permission 只服务于当前 Item。 若再切换回共享 Permission，平台会删除该私有 Permission。
私有权限不是默认设计工具
大量私有 Permission 会增加审计、成员变更和故障排查成本。 可由角色、Team 或生命周期表达的规则，应优先使用可复用配置。
Team 权限
Team Role 可以出现在 Permission Access 中。 运行时根据业务 Item 的 team_id 解析该 Team 中具有相应角色的成员。
例如同一套 Permission 可以定义：
| Identity / Team Role | Get | Update | Delete |
|---|---|---|---|
| Team Manager | 是 | 是 | 按业务决定 |
| Team Member | 是 | 是 | 否 |
| Team Guest | 是 | 否 | 否 |
表中的权利只是设计示例，不是平台内置固定含义。 每个环境都必须在 Permission 中显式配置。
Administrators 与 root
Administrators 仍受标准 Permission 约束。 只有 root / Super User 绕过标准访问检查。
因此：
- 用管理员能打开 Item，不能证明普通角色配置正确；
- 用 root 测试失败路径没有意义；
- root 凭据必须受到比普通管理员更严格的控制。
与其他访问入口的边界
Can Add
Can Add 位于 ItemType 上，控制谁可以创建该类型的新 Item。 它与已有 Item 的 Update 权限不同。
常见正确组合是：
- 作者角色有 Can Add；
- 新 Item 的默认 Permission 让 Creator/Owner 或作者组可以 Update；
- 其他只读角色只有 Get。
TOC Access
TOC Access 控制标准导航入口是否显示。 它不是数据权限：
- 有 TOC Access 但无 Get，仍不应读到 Item；
- 无 TOC Access 但有 Get，可能通过关系、收藏或其他入口访问 Item；
- 隐藏 TOC 不能修复 API 越权。
表单只读与 CUI
只读字段、隐藏页签和移除按钮用于界面体验， 不能替代 Update、Delete、Can Change Access 或 Transition Role。
攻击者或集成程序不需要点击界面按钮即可发送请求， 所以必须用服务器端权限完成最终约束。
Lifecycle 与 Workflow
- Lifecycle Transition 的 Role 决定谁能执行某条 Promote 路径；
- State Permission 决定进入状态后 Item 的数据权利；
- Workflow Assignment 决定谁处理活动；
- Activity 配置的 Promote 仍必须符合生命周期状态和转换设计。
有 Workflow 任务不自动授予底层 Item 的 Get/Update。 任务执行人必须同时拥有完成工作所需的数据权限。
高级安全模型的边界
R31 培训资料把平台安全控制概括为：
- 标准 Permission：基于角色/身份的访问；
- MAC：基于属性与策略的强制访问控制；
- DAC：基于对象关系/域的访问控制。
MAC、DAC 的可用性、License、建模方式和优先级应由目标版本专项文档确认。 不要在未启用这些组件的环境中引用其 ItemType 或假设标准 Permission 自动具有同等语义。
User Visibility Policy 还会影响哪些身份能看到 User 信息， 它与业务 Item Permission 是相关但不同的安全主题。
操作：配置标准 Permission
1. 先写访问矩阵
不要直接在界面上试勾选。 先用表格明确：
| 生命周期状态 | 身份 | Discover | Get | Update | Delete | Change Access |
|---|---|---|---|---|---|---|
| Draft | Authors | 是 | 是 | 是 | 否 | 否 |
| Draft | Reviewers | 是 | 是 | 否 | 否 | 否 |
| Released | Authors | 是 | 是 | 否 | 否 | 否 |
| Released | World | 按政策 | 按政策 | 否 | 否 | 否 |
每个“是”都应有业务理由，每个敏感状态都应包含负向测试。
2. 创建 Permission
以 R31 界面为基线：
- 打开
Administration > Permissions。 - 创建 Permission，并使用能反映对象与状态的名称。
- 在 Access 关系中添加 Group、动态 Identity 或 Team Role。
- 勾选最小必要权利。
- 保存并记录配置 Owner。
3. 关联 ItemType
- 打开目标 ItemType。
- 在 Permissions 关系中加入所有允许使用的 Permission。
- 只标记一个预期的默认 Permission。
- 如使用 Can Discover，核对 Enforce Discovery。
- 如需私有权限，显式评估 Allow Private Permissions。
- 分别配置 Can Add 与 TOC Access。
4. 配置状态权限
- 在 ItemType 的 Permissions 关系中先加入状态要使用的 Permission。
- 打开 Life Cycle Map。
- 为需要切换权限的 State 选择 State Permission。
- 明确未配置状态应沿用哪个当前 Permission。
- 测试正向 Promote 与回退路径。
验证方法
建立测试身份
至少准备：
- 仅 Discover 用户；
- 只读用户；
- 编辑用户；
- 无权用户；
- 一个用于维护的管理员，但不使用 root 代替业务测试。
每次修改成员或 Permission 后，使用新会话重新登录。
正向与负向用例
| 用例 | 预期 |
|---|---|
| 无权用户搜索 | Item 不出现，或按 Discovery 规则显示受限结果 |
| Discover-only 用户打开 Item | 被拒绝 |
| Get-only 用户保存修改 | 被拒绝 |
| Update 用户直接请求修改 | 允许，且触发正常业务规则 |
| 无 Can Add 用户新建 | 被拒绝 |
| 无 Transition Role 用户 Promote | 被拒绝 |
| 无 Can Change Access 用户切换 Permission | 被拒绝 |
验证必须同时覆盖标准 UI 与系统实际使用的集成入口。 不要尝试用非官方内部端点“证明”安全。
排查“为什么他能看到”
按以下顺序检查：
- 当前 Item 的
permission_id是什么； - 用户的 Alias 属于哪些嵌套 Identity；
- Permission 中哪些 Access 行匹配；
- 当前 Item 的 Owner、Creator、Manager 或 Team 是谁；
- 生命周期是否已切换 Permission；
- 用户是否通过其他组累积了 Get；
- 是否正在用 Administrators 或 root；
- 是否启用了 MAC、DAC 或 User Visibility 等附加策略。
版本差异
| 基线 | 本文采用的事实 | 目标环境需复核 |
|---|---|---|
| R31 | 标准权利、Enforce Discovery、私有权限、状态权限与 Team 教学 | 菜单、字段标签、变量与高级安全 License |
| R35 | .NET 8.0.1 运行时不改变服务器授权原则 | 认证、MAC/DAC 与安全指南版本 |
| R39 | .NET 10 运行时不改变“UI 不是安全边界” | Release Notes、补丁与产品组件兼容性 |
风险与最佳实践
- 默认拒绝，再按业务角色授予最小权利。
- Permission 使用 Group、动态身份或 Team Role，减少 Alias 直授。
- World 仅用于明确允许全体用户的访问。
- Can Change Access 与 Delete 作为高风险权利单独审批。
- 状态权限必须覆盖正向、退回、取消和重新打开路径。
- 不要用隐藏按钮、只读字段或 TOC Access 代替 Permission。
- 不要只用管理员测试；每条规则都要有无权用户负向用例。
- 定期复核组嵌套、私有权限、高权限 Team 与失效账号。
- 高级 MAC/DAC 策略必须单独设计、文档化并按官方指南验证。
相关主题
官方资料
- Aras Innovator Platform 文档库
- Aras Innovator 31 — Domain Access Control Guide
- Users and Identities in Aras Innovator
- 《Aras Innovator Configuring Solutions Student Guide》（Revision: December 2024，Unit 9）