連接 Okta
如果你的公司跑在 Okta（或另一個 SAML 身分提供者）上，FortressFlag 可以把登入完全交給它，並讓你的目錄決定誰有帳戶、擁有什麼角色。這份指南以能讓你全程保持登入的順序連接這三層：先 SSO，再佈建，再群組對應角色，最後（在一切都能運作之後）才是政策開關。
你在 FortressFlag 這邊需要是 Owner，在另一邊需要是 Okta 管理員。FortressFlag 用 SAML 登入、用 SCIM 2.0 佈建。（不支援 OIDC。）
1. 連接 SSO
Section titled “1. 連接 SSO”在管理 → 驗證裡設定 SSO 連線：貼上你的身分提供者的 metadata，FortressFlag 會回給你 Okta 的 SAML 應用程式設定所要求的兩個值：服務提供者的實體 ID（它的 metadata URL）和 ACS URL。
用這些值在 Okta 建立一個 SAML 應用程式，把自己指派給它，然後測試登入：你的組織的登入畫面會在密碼表單旁多出一條單一登入的路徑。此時 SSO 能用但不是必要的：密碼登入仍然有效，而這正是測試期間你想停留的地方。
2. 開啟佈建（SCIM）
Section titled “2. 開啟佈建（SCIM）”同樣在管理 → 驗證底下，鑄造一個 SCIM 權杖。和 SDK 金鑰一樣，它只顯示一次：直接把它複製到 Okta 的佈建設定裡作為 bearer token，並把 Okta 指向你的 FortressFlag SCIM 端點（你的 FortressFlag 位址上的 /scim/v2 路徑）。
佈建開啟後，Okta 會隨著人們加入和離開你的目錄，建立和移除 FortressFlag 帳戶：
- 被佈建的人一開始是沒有任何專案存取的 Viewer：預設安全；你從那裡開始授權（或讓群組對應來做，見下一節）。
- 解除佈建會移除他們的存取並把他們登出：在你的目錄裡離職，就是在這裡離職，工作階段也包括在內。
- 佈建所做的變更會出現在稽核紀錄裡，歸屬於佈建權杖：你的目錄的動作，如實記錄。
- 一道護欄：佈建永遠無法移除你的組織的最後一位 Owner。
一個你的法務團隊會問的備註：由佈建建立的人從來沒看過註冊表單，所以由一位管理員代表他們接受服務條款。儀表板會提示這件事，而這次接受和其他接受一樣會被記錄。
3. 把群組對應到角色
Section titled “3. 把群組對應到角色”透過 SCIM 推送你的 Okta 群組，然後管理 → 驗證裡的群組對應面板讓你指定這個群組 ⇒ 這個角色：eng-leads ⇒ Admin，engineering ⇒ Developer。從此以後，目錄成員身分決定 FortressFlag 角色：
- 一個人若在好幾個已對應的群組裡，得到最高的已對應角色。
- 已對應成員的角色在儀表板裡顯示為由你的身分提供者管理：那裡的角色控制項會被停用，因為你的目錄只會把它覆寫回去。
- 未對應的群組不做任何事，而對應永遠不會把人降到 Viewer 以下。
4. 要求 SSO：在一切都能運作之後
Section titled “4. 要求 SSO：在一切都能運作之後”回到管理 → 驗證，把組織的政策切換為 SSO。從這裡開始，所有人的密碼登入都關閉了：身分提供者是唯一的門。
最後才扳這個開關，而且先讀這段：一旦 SSO 成為必要，撤銷它也需要一次能用的 SSO 登入。如果你的身分提供者在 SSO 為必要時壞了（憑證過期、應用程式被刪），沒有人能登入，包括你，而復原是一場支援對話，不是一個設定頁面。所以：確認 SSO 登入能用，確認第二個人也進得來，然後再要求它。（儀表板也不會讓你在連線存在之前要求 SSO，或在 SSO 為必要時刪除連線，這些護欄指向同一個方向。）