组织
OpenFactory 的组织 API 存储组织成员身份以及可选的组、单位和团队。它还提供共享对话/变体的目标。
organization
├── members: owner | admin | member
├── groups: organization-level sharing collections
└── units
├── unit members
└── teams
└── team members该层次结构是授权输入。角色标签并不能证明每个构建、VM、下载或部署端点都强制执行预期策略。有关每个角色当前管理的路由，请参阅角色和权限范围。
核心对象
- **组织：**顶级成员资格和管理边界。一个用户可以属于多个组织。
- **组：**用作共享目标的组织成员的命名集合；它不是一个行政等级制度。
- 单位： 类似部门的容器，具有自己的成员资格和存储的工作流角色。
- 团队： 具有自己的成员资格和存储的工作流角色的单元的子级。
用户必须是组织成员才能添加到组织下面。
安全设置顺序
1、创建组织；创造者成为所有者。 2. 在依赖组织进行持久运营之前添加第二个负责任的所有者。 3. 邀请用户使用他们的确切电子邮件地址并分配所需的最低组织角色。 4. 仅当单位或团队的范围改变实际工作流程时才添加单位或团队。 5. 使用每个代表角色测试一项允许的操作和一项拒绝的操作。 6. 在角色删除和会话刷新后检查共享和成员资格行为。
邀请会过期，并且必须由电子邮件与邀请匹配的帐户接受。不要在票证或公共日志中传输邀请令牌。
上下文和所有权
组织选择可能会影响可见的协作数据，但单个资源仍然具有所有者和共享规则。不要仅仅因为两个用户属于同一组织就推断对私有构建或工件的访问权限。在支持的情况下使用显式共享并单独测试下载/VM 操作。
隔离证据
组织和共享路由对其范围内的操作执行成员资格检查和同一组织验证。 “租户隔离”是一个更广泛的系统属性，需要跨对话、构建、工件、虚拟机、API、缓存、导出和日志进行跨租户拒绝路径测试。不要单独使用组织层次结构作为证据。
行政保障
- 支持多个所有者；唯一的所有者不能离开。
- 只有所有者才能提升其他所有者或删除组织。
- 删除和成员资格删除可能会影响相关访问。首先清点共享、单位、团队、活动会话和拥有的资源。
- 如果您的政策需要，保留外部审计记录；当前的角色列表不是历史审计跟踪。