1. 课程导入与全景认知
ThingWorx 作为工业物联网平台，其权限体系并不是一张简单的“用户—角色—权限”表，而是由组织（Organization）、用户组（User Group）、用户（User）、角色（Role）、权限（Permission）以及可见性（Visibility）共同构成的多层授权结构。当平台从单租户走向多租户时，这套结构会进一步叠加租户隔离边界，使“谁能看到什么、谁能改什么、数据归属谁”成为必须显式设计的问题。本课程的目标，是让学员能够读懂 ThingWorx 的授权链路，并能独立完成多租户场景下的权限规划、配置与排障。
一、先建立术语坐标系
在动手配置之前，必须先把几个高频术语的含义固定下来，否则后续讨论很容易混淆：
- Organization（组织）：ThingWorx 中承载用户与实体的顶层容器，通常对应一个租户或一个业务单元。组织是隔离的第一道边界。
- User Group（用户组）：组织内的用户集合，用于批量授权。用户组可以嵌套，权限沿组链继承。
- User（用户）：实际登录主体，必须归属于至少一个组织，可同时属于多个用户组。
- Role（角色）：权限的集合载体，如 Administrator、Developer、Operator、Viewer 等，角色决定“能做什么”。
- Permission（权限）：对具体实体（Thing、ThingTemplate、DataShape、Mashup、Service 等）的读、写、执行、删除等操作许可。
- Visibility（可见性）：控制实体在导航、搜索、列表中的可见范围，与权限共同决定“看得到”和“改得动”。
- Tenant（租户）：多租户治理中的逻辑隔离单元，通常一个租户对应一个 Organization，并拥有独立的用户、实体与数据空间。
二、整体知识地图
本课程 30 个章节围绕四条主线展开：权限模型基础 → 多租户隔离机制 → 治理与运维 → 实战与排障。下图给出全景知识地图，帮助你在学习每一节时都能定位到整体中的位置。
三、权限判定的基本链路
理解 ThingWorx 权限，关键是理解一次访问请求的判定顺序。当用户尝试打开一个 Mashup 或调用一个 Service 时，平台会依次检查：用户是否属于该实体所在组织 → 用户所在用户组是否被授予该实体的权限 → 用户角色是否包含所需操作 → 实体可见性是否允许其出现在当前上下文。任一环节不通过，请求即被拒绝。这个顺序决定了排障时的检查方向：先看组织归属，再看组授权，最后看角色与可见性。
需要特别注意的是，ThingWorx 的权限是叠加而非覆盖的。如果用户同时属于多个用户组，只要其中一个组授予了某权限，该权限即生效；但如果某处显式拒绝了权限，拒绝通常优先。这一规则在多租户环境中尤其重要，因为跨租户的共享资源往往需要额外的显式授权。
四、多租户治理的核心问题
多租户治理要回答三个问题：数据归谁、谁能访问、资源如何分配。在 ThingWorx 中，最自然的做法是“一租户一组织”，即每个租户拥有独立的 Organization，其下的 Thing、Mashup、DataShape 等实体默认不跨组织可见。这样做的优点是隔离清晰、审计简单；代价是共享资源需要额外设计，例如公共模板、公共字典等。
实际项目中常见的折中方案是：核心模板与公共组件放在平台级组织，租户组织通过显式授权引用。此时必须严格控制平台级组织的授权范围，避免一个租户的误操作影响其他租户。下表给出三种典型隔离策略的对比，供规划时参考。
| 隔离策略 | 组织划分 | 优点 | 风险点 |
|---|---|---|---|
| 完全独立 | 一租户一组织，无共享 | 隔离最强，审计最清晰 | 公共资源重复建设，维护成本高 |
| 平台共享 + 租户独立 | 平台组织 + 租户组织 | 公共组件复用，租户数据隔离 | 平台组织授权过宽会引发越权 |
| 混合分组 | 按业务线划分组织，租户为用户组 | 适合租户数量多、业务相近的场景 | 租户间边界变弱，需靠用户组精细控制 |
五、学习建议与检查清单
本课程强调“能配置、能判断、能排障”。建议在学习每一节时，都对照以下检查清单自问：
- 这个权限点属于哪个组织？跨组织了吗？
- 授权是给用户、用户组还是角色？继承链是否清晰？
- 可见性与权限是否一致？是否存在“看得到但改不动”或“改得动但看不到”的异常？
- 如果拒绝访问，应该按什么顺序排查？
- 这个配置在多租户环境下会不会影响其他租户？
接下来，课程将从 Organization 与 User Group 的具体配置开始，逐步展开到角色映射、实体授权、多租户隔离与治理审计。你在本节建立的知识地图和判定链路，将贯穿后续所有章节。