连接 Okta
如果你的公司运行在 Okta（或另一个 SAML 身份提供商）上，FortressFlag 可以把登录完全交给它——并让你的目录决定谁拥有账户、持有什么角色。本指南按照能让你全程保持登录状态的顺序连接这三层：先 SSO，然后预配，然后群组到角色的映射，最后——在一切都正常之后——策略开关。
在 FortressFlag 这一侧你需要是 Owner，在另一侧需要是 Okta 管理员。FortressFlag 用 SAML 做登录，用 SCIM 2.0 做预配。（不支持 OIDC。）
1. 连接 SSO
Section titled “1. 连接 SSO”在管理 → 身份验证里设置 SSO 连接：粘贴你的身份提供商的元数据，FortressFlag 会返回给你 Okta 的 SAML 应用设置所要求的两个值——服务提供商的实体 ID（它的元数据 URL）和 ACS URL。
用这些值在 Okta 里创建一个 SAML 应用，把你自己分配给它，然后测试登录：你的组织的登录界面会在密码表单旁边多出一条单点登录路径。此时 SSO 能用但还不是必需的——密码登录仍然有效，而这正是你在测试期间想要停留的状态。
2. 开启预配（SCIM）
Section titled “2. 开启预配（SCIM）”同样在管理 → 身份验证下，签发一个 SCIM 令牌。像 SDK 密钥一样，它只显示一次——把它直接复制到 Okta 的预配配置里作为 bearer 令牌，并把 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 必需期间删除连接——这些护栏指向同一个方向。）