企业
通过 SAML 与 OIDC 实现单点登录
把 Ciao 纳入你已经在运行的身份控制体系——SAML 或 OIDC、可选的多因素认证、即时创建账号,以及在它们该被强制执行的地方——你的身份提供商上——强制执行的会话策略。
Ciao 支持通过 SAML 与 OIDC 实现单点登录,并配有可选的多因素认证与基于角色的访问控制。与那些创建一个平行身份孤岛的基于密码的工具不同,SSO 把 Ciao 放在你现有的身份提供商背后——因此新成员通过你的目录获得访问权限,会话与重新认证策略遵循你的 IdP 规则,离职人员在你的 IdP 停用其账号的那一刻就会失去访问权限。
发布日期 2026-07-03 · 最近更新 2026-07-03
为什么 SSO 通常是第一项企业要求
任何自己保存密码的工具,都是你的离职流程可能遗漏的工具。对于一个已登录用户可以提示改动生产软件的平台而言,这种风险比一个仪表盘产品更为尖锐:一个孤儿账号,不仅是一个数据暴露的问题,也是一个变更控制的问题。安全评审把 SSO 排在需求清单前列是有道理的。
SSO 把 Ciao 的身份验证,移到你已经在治理的身份提供商背后。访问评审集中在一个地方进行,多因素认证策略被一致地执行,你的审计员已经接受的“新增-变动-离职”流程,可以扩展到覆盖 AI 辅助开发,而不需要再对账一个平行的账号库。
对于实际做事的人而言,还有一个更安静的好处:少一个密码,少一次登录仪式,访问权限在第一天就出现,因为目录——而不是一个工单队列——才是那个真相来源。让安全路径同时也是便利路径的控制措施,才是人们真正会遵守的控制措施,而 SSO 正是身份技术栈里最清晰的例子。
Ciao 提供什么
以下身份能力是企业级平台的一部分,每一项都可以在接入或评估过程中被验证:
- SAML 与 OIDC — 通过两种主流协议实现 SSO,因此 Ciao 能配合你今天正在运行的 IdP,而不需要指定某个特定供应商。
- 可选的多因素认证 — 多因素认证可以通过你的 IdP 策略强制执行,Ciao 一侧也提供可选的多因素认证,作为身份设置的一部分。
- 基于角色的访问控制 — SSO 与 RBAC 搭配使用,因此身份验证回答“你是谁”,角色回答“你可以做什么”——横跨工作区与项目。
- 即时创建账号 — 账号可以在用户首次通过你的 IdP 成功登录时创建,因此接入不依赖手动创建账号。
- 留有审计记录的管理员操作 — 身份与访问的变更属于管理员操作,管理员操作会被记录进只增不减的审计日志。
设置是如何进行的
1. 选择协议
根据你的 IdP 团队的偏好,选择 SAML 或 OIDC。两者都不是“次要”选项——选择你的身份工具管理得最好的那一个。
2. 在你的 IdP 中创建应用
像注册任何 SSO 应用一样,在你的身份提供商中注册 Ciao,并分配应该拥有访问权限的用户或用户组。
3. 交换配置信息
在接入过程中,你的 IdP 和 Ciao 之间会交换元数据、端点和证书,企业团队会与你的身份工程师一起完成这个过程。
4. 用一个试点小组进行测试
在扩大访问范围之前,用一个小的用户组验证登录、即时创建账号和角色分配是否符合预期。
5. 全面推广并审阅
把分配范围扩展到全体人员,然后在审计日志中确认访问事件和管理员操作是否按你评审所期望的方式被记录。
即时创建账号能解决什么,不能解决什么
即时创建账号会在用户第一次通过你的 IdP 登录时创建一个 Ciao 账号。这消除了接入时的手动步骤,也防止了预先创建但闲置未用的账号。JIT 做不到的是账号停用:一个再也不会登录的用户,依然需要在 IdP 那一端被移除访问权限,而生命周期自动化更适合由 SCIM 来处理。大多数企业级部署,会同时使用 SSO 加 JIT 来处理入职,以及 SCIM 来处理完整的生命周期——SCIM 页面涵盖了这一半的内容。
在评估过程中,请明确测试 JIT 路径:在 IdP 中分配一个测试用户,登录一次,并确认账号是否带着你映射规则所设定的角色到达。这个五分钟的测试,比任何架构图都能告诉你更多信息。
会话策略与多因素认证
会话时长、重新认证频率与二次验证规则,应该属于身份提供商这一层——你的安全团队已经在那里调优它们——SSO 意味着 Ciao 的会话会遵循你的 IdP 在登录时强制执行的策略。多因素认证也以同样的方式运作:在治理 Ciao 访问权限的 IdP 策略中强制执行它,同时平台一侧也提供可选的多因素认证。对审核人员而言,实际的结果是一个单一的策略面可供审计,而不是逐个工具漂移的会话设置。
当你的策略发生变化时——更短的会话时长、更严格的二次验证规则——你只需在 IdP 那一处修改一次,对 Ciao 的访问权限就会随之而变,不需要在平台侧再做一次平行的设置审计。
验证说明
身份方面的声明很容易验证:在评估过程中配置一次测试连接,亲眼看着登录、即时创建账号和角色映射针对你自己的 IdP 发生。安全资料包可通过联系页面按需索取,以书面形式记录身份架构,NDA 下的 SOC 2 Type II 报告则涵盖了背后经审计的访问管理控制措施。
能力一览
| 能力 | 机制 | 说明 |
|---|---|---|
| 单点登录 | SAML 或 OIDC | 适用于符合标准的身份提供商 |
| 多因素认证 | IdP 策略,加上 Ciao 上可选的多因素认证 | 在你的团队已经治理多因素认证的地方强制执行 |
| 创建账号 | 首次登录时即时创建 | 与 SCIM 搭配可覆盖完整生命周期 |
| 授权 | 基于角色的访问控制 | 工作区与项目层级的范围限定 |
| 证据 | 只增不减的审计日志 | 管理员操作被记录以供审阅 |
常见问题
支持哪些身份提供商?
任何实现了 SAML 或 OIDC 的身份提供商——企业通常运行的 IdP,例如 Okta、Microsoft Entra ID 和 Google Workspace,都支持这些协议。配置会在接入过程中与你的身份团队一起完成。
我们能要求所有用户只能通过 SSO 登录吗?
把 SSO 作为唯一登录路径,是一个在接入过程中处理的身份配置问题——请向企业团队提出,你的设置会被针对这项要求进行确认,而不是被想当然地假设。
员工离职时会发生什么?
在 IdP 处将其停用,他们就无法再对 Ciao 进行身份验证。如果配置了 SCIM 供给,停用操作也会作为一个生命周期事件传播,相关的管理员操作会被记录进只增不减的审计日志。
JIT 和 SCIM 有什么区别?
JIT 在用户首次登录时创建账号;它只处理入职这一件事。SCIM 会持续地从你的 IdP 推送创建、更新和停用事件,覆盖整个生命周期。大多数企业级部署会把两者结合起来使用。
SSO 是包含在内的,还是一项附加服务?
通过 SAML 与 OIDC 实现的 SSO,是 Ciao 企业能力集的一部分。严肃的生产项目起价为每年 10,000 美元——请与销售团队确认计划范围,以便身份要求从一开始就写入协议。