用户、身份与团队

Aras Innovator 把“登录账号”和“授权主体”分成两层：

• User 保存登录名、账号状态和人员联系信息；
• Identity 表示权限、生命周期和工作流中使用的个人、组织或角色。

理解这层分离，是正确设计 Permission、TOC、Can Add、Lifecycle 和 Workflow 的前提。

适用版本与资料基线

• User、Alias Identity、Group Identity 与成员嵌套的概念跨版本相对稳定。
• 创建与检查步骤以 Aras Innovator R31、2024 年 12 月版官方培训资料为界面基线。
• 现代认证可能使用 OAuth、Windows Authentication 或外部身份提供程序；R35/R39 的运行时变化不改变 User 与 Identity 的基本职责分工。
• 菜单翻译、认证插件和 User Visibility Policy 会随 Release、应用包和环境配置变化。

最小心智模型

例如，用户“张琳”的 Alias Identity 属于 Mechanical Engineers， 该组又属于 Engineering。 如果 Permission 分别向两个组授予 Get 与 Update，张琳的有效权限会累积这两项权利。

设计时优先把业务规则授予 Mechanical Engineers 这类角色/组， 而不是直接授予张琳的 Alias。 人员变更时，只需调整成员关系。

核心机制

User：谁可以登录

User 是账号记录，常用字段如下：

字段	作用	配置提醒
Login Name	唯一登录标识	与外部身份提供程序映射时须保持一致
Logon Enabled	是否允许该账号登录	离职或停用通常取消勾选，不删除历史主体
Default Vault	用户文件操作的默认 Vault	必填性与默认值以目标配置为准
Starting Page	登录后的起始页面	可能被用户偏好或 CUI 覆盖
Manager	人员信息中的上级引用	R31 培训基线中不自动产生审批权限
Email / Telephone	联系信息	常被通知和人员查询使用

R31 培训练习通过 Administration > Users 创建 User， 并强调 Login Name、Default Vault 与启用登录等信息。

User 不是 Permission 中的授权主体

配置 Permission、Workflow Assignment 或 Transition Role 时选择的是 Identity。 不要因为表单上能找到 User，就把 User 与其 Alias Identity 当作同一个 Item。

Alias Identity：唯一代表某个 User

创建 User 时，平台会生成与之关联的 Alias Identity。 其 Is Alias 为真，并以一对一方式代表该用户。

Alias 的典型用途包括：

• 作为组 Identity 的成员；
• 在确有个人专属要求时直接授权；
• 记录工作流分配、历史或拥有关系中的个人主体；
• 参与 Identity Membership 分析。

Alias 不应再包含其他 Identity 成员。 组织结构应由非 Alias 的 Group Identity 表达。

Group Identity：组织与角色

Group Identity 可表示部门、岗位、职责或授权集合，例如：

Company
└── Engineering
    ├── Mechanical Engineers
    │   ├── 张琳（Alias）
    │   └── 王涛（Alias）
    └── Engineering Managers
        └── 陈洁（Alias）

成员通过 Identity 的 Members 关系维护。 一个 Group Identity 可以包含 Alias，也可以包含其他 Group Identity。

有效身份会沿成员结构累积，因此同一个用户可以同时具有：

• 个人 Alias；
• 所属部门；
• 职能角色；
• 项目角色；
• 系统内置身份。

R31 培训资料把 Members 关系中的 From Date 和 End Date 标为 deprecated。 不要用这些字段设计新的临时授权流程；目标版本如需时效授权，应采用经支持的治理方案。

动态身份

系统提供会根据当前 Item 计算成员的特殊 Identity：

Identity	运行时含义	常见对应属性
Creator	当前 Item 的创建者	created_by_id
Owner	当前 Item 的拥有者	owned_by_id
Manager	当前 Item 的管理者	managed_by_id

这些名称表达的是当前 Item 上的动态上下文， 不等同于 User 表单上的 Manager 字段，也不等同于名称恰好相同的普通部门组。

在 Permission 中使用 Owner 的价值是： 同一套 Permission 可以让每条记录的 owned_by_id 对应人员拥有 Update， 不需要为每个人创建独立权限定义。

World、Administrators 与 root

主体	安全含义
World	所有有效身份共同拥有的基础身份；授予权利前要按“全体用户”评估
Administrators	管理员组，可被授予广泛管理能力，但仍受标准 Permission 约束
root / Super User	绕过标准权限的特殊维护主体，应严控使用与审计

“属于 Administrators”不等于自动绕过每条 Item 的 Permission。 测试权限时既要使用普通用户，也要避免只用 root 得出结论。

Team 与 Team Role

Team 解决“同一种 Item，在不同项目中由不同人员担任同一角色”的问题。

一个 Team 由以下部分组成：

• Team 实例，例如 Project Aurora Team；
• 成员 Identity；
• 每个成员在该 Team 中的 Team Role；
• 业务 Item 上用于选择 Team 的 team_id。

Permission、Lifecycle 或 Workflow 可以引用 Team Role。 运行时则根据当前 Item 的 team_id 找到具体人员。

R31 培训基线提供标准角色 Team Manager、Team Member 和 Team Guest； 成员角色留空时表示通用 Team 角色。 不要把这些名称直接解释成固定的 Get/Update/Delete 权限， 真正权利仍由 Permission、Transition 或 Assignment 配置决定。

身份在哪里生效

配置位置	Identity 控制的内容
ItemType > Can Add	谁能创建该类型的新 Item
ItemType > TOC Access	谁能看到该 ItemType 的标准导航入口
Permission > Access	谁能发现、读取、更新、删除或变更访问
CUI 配置	命令、按钮或界面对哪些身份显示/移除
Lifecycle Transition > Role	谁能执行该状态转换
Workflow Activity > Assignment	谁收到并处理活动任务
Team Role	在当前 Item 所选 Team 中动态解析执行者

这些入口彼此独立。 某用户能看到 TOC，不代表他有 Get；有 Get 也不代表有 Can Add； 有 Update 也不自动获得 Promote 某条 Transition 的资格。

操作：建立最小身份结构

1. 先设计角色，再创建用户

在配置界面前先列出业务角色矩阵：

角色	人员来源	需要的能力
文档作者	工程部门成员	创建、编辑草稿
文档审核人	质量角色成员	读取、处理审核任务
发布管理员	受控小组	执行发布 Transition

将组织归属和业务职责分开建组，避免只有一棵与组织架构完全相同的树。

2. 创建 Group Identity

以 R31 界面为基线：

1. 打开 Administration > Identities。
2. 新建 Identity，填写稳定、可审计的名称。
3. 保存后在 Members 关系中加入已有 Alias 或下级 Group。
4. 重新检查嵌套方向，确认不会把上级组错误加入下级组。
5. 记录该组的业务 Owner 与成员维护流程。

3. 创建或启用 User

1. 打开 Administration > Users。
2. 新建 User，填写 Login Name、姓名、Email 和 Default Vault 等必需信息。
3. 根据目标认证方式配置账号，并启用 Logon Enabled。
4. 保存后确认对应 Alias Identity 已生成。
5. 将 Alias 加入规划好的 Group Identity。

4. 配置 Team

当授权依赖具体项目或业务上下文时：

1. 创建 Team 实例。
2. 添加成员 Identity，并为每个成员选择 Team Role。
3. 在 Permission、Lifecycle 或 Workflow 中引用 Team Role。
4. 确保目标 ItemType 的表单能正确设置 team_id。
5. 用两个不同 Team 的相同用户验证角色差异。

验证

Identity Membership 报告

R31 培训基线可在 Identities 搜索结果中使用 Identity Membership 报告， 查看 Alias Membership 或 Identity Structure。

报告适合回答：

• 某个用户为何获得某项权限；
• 某个组最终包含哪些人员；
• 嵌套方向是否错误；
• 调整成员后哪些授权可能受影响。

最小权限测试

每个角色至少准备一个非管理员测试用户，并验证：

1. 用户能否以预期认证方式登录。
2. TOC 只显示应见入口。
3. 有 Can Add 才能创建。
4. 有 Get 才能打开已有 Item。
5. 有 Update 才能保存修改。
6. 只有 Transition Role 成员能 Promote。
7. Workflow 活动只进入预期人员的 InBasket。
8. 移出 Group 后重新登录，权限确实消失。

权限缓存、会话和身份令牌可能让当前会话继续表现为旧成员关系。 成员调整后应使用新会话验证。

停用人员

人员离职或账号不再使用时：

1. 取消 User 的 Logon Enabled。
2. 结束或转交未完成工作流任务。
3. 调整业务 Item 的 Owner/Manager/Team。
4. 从不再适用的 Group 移除 Alias。
5. 保留 User、Alias 和历史引用用于审计。

删除历史 User 或 Alias 可能破坏可追溯性，通常不是首选。

密码与外部认证

R31 培训基线中，Identity 可配置 Maximum Password Age、Password History Length 等本地密码策略， 并可通过 Variables 设置密码组成或账户锁定策略。

这些设置只应在使用相应本地认证机制时评估。 若环境使用外部身份提供程序，密码复杂度、MFA 和锁定通常由外部系统承担， 仍需确认 Innovator User 的 Login Name、Logon Enabled 与映射规则。

不要记录“数据库以 MD5 存密码”

密码存储和认证协议属于版本与安全配置细节。 业务文档不应要求开发者读取、生成或比较数据库密码表示， 更不应把“散列”称为“加密”。使用官方登录、OAuth 或支持的认证集成。

R31 培训列出的变量名包括：

• User_pwd_symbols_min_number；
• User_pwd_digits_min_number；
• AccountLockoutThreshold_triesNum；
• AccountLockoutDuration_minutes。

这些名称仅作为 R31 配置基线。 使用前应在目标 Release 的 Variables 和官方安全文档中确认存在、取值含义与组合要求。

版本差异

范围	稳定内容	必须重新确认的内容
R31	User、Alias、Group、动态身份、Team 基本模型	菜单、字段、报表入口和密码变量
R35	同一身份模型继续服务于平台授权	OAuth、Windows Authentication 与 User Visibility 配置
R39	运行时升级到 .NET 10 不改变身份建模原则	目标 Release 的认证组件、补丁和安全指南

不要从运行时版本推断认证行为，也不要从 R31 培训界面推断 R39 的按钮位置。

风险与最佳实践

• 优先向 Group 或角色授权，避免大量 Alias 直授。
• 组织组与业务角色组分开管理，名称表达职责而非具体人员。
• 控制组嵌套深度，定期导出 Membership 报告复核。
• 不要向 World 授予敏感 Item 的宽泛 Get、Update 或 Delete。
• 不要假定 Administrators 会绕过 Permission。
• root 只用于受控维护，禁止作为日常开发或验收账号。
• User 停用优先于删除，并同步处置未完成任务与 Owner。
• Team Role 的能力必须由配置验证，不能凭角色名称猜测。
• 对所有高权限组建立 Owner、审批流程和定期复核。

相关主题

• Permission 权限
• Lifecycle 生命周期
• Workflow 工作流
• 平台架构与请求边界
• TOC 目录

官方资料

• Users and Identities in Aras Innovator
• Aras Innovator Platform 文档库
• Aras Innovator 31 — Configurable Job Scheduling
• 《Aras Innovator Configuring Solutions Student Guide》（Revision: December 2024，Unit 2）