組織
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、快取、匯出和日誌進行跨租戶拒絕路徑測試。不要單獨使用組織層次結構作為證據。
行政保障
- 支援多個所有者；唯一的所有者不能離開。
- 只有所有者才能提升其他所有者或刪除組織。
- 刪除和會員資格刪除可能會影響相關存取。首先清點共享、單位、團隊、活動會話和擁有的資源。
- 如果您的政策需要，保留外部審計記錄；目前的角色清單不是歷史審計追蹤。