截至 2021 年，英国政府拥有大约 121 个独立的单点登录解决方案，这充分说明了为什么 SSO 不仅仅是一项便利功能。SSO 是联合身份整合：它通过可信的 Identity Provider 实现集中身份验证，同时各个应用保留对经身份验证的用户有权执行的操作的控制权。
您可能会在日常工作中遇到这个问题。员工需要使用电子邮件、云端应用、物业管理系统、内部 WiFi 和管理门户。每个服务都有自己的登录名、密码策略和账户所有者。当有人入职、变更角色或离职时，管理员必须更新多个系统，而用户则必须记住哪些凭据属于哪些服务。
这就是企业寻找 SSO 详解的实际原因。问题不仅在于如何减少登录界面的数量。而在于如何在不削弱应用程序级权限或引入更具危险性的集中式目标的前提下，构建可靠的身份控制平面。
为什么碎片化的身份管理会导致真实的访问问题
英国政府的经验提供了一个有价值的起点。一项 2021 GOV.UK 服务标准审查估计，中央政府拥有大约 121 种不同的 SSO 解决方案，因为服务团队构建了独立的身份验证系统，而不是使用统一的政府级共享身份平台。因此，使用多项公共服务的人员可能会拥有多套登录信息，并且可能不知道特定交易需要哪种账户。（英国政府身份验证和数字身份审查）
这并不是说政府系统有着独特的复杂性。大型企业、医疗机构、酒店集团、物业运营商和公共部门网络都面临着同样的模式。每个应用程序都可能创建一个身份孤岛，而每个孤岛都可能形成自己的密码规则、找回流程、组模型和离职解绑工作流。
身份验证与授权是不同的工作
身份验证解决的是“你是谁？”的问题。授权解决的是“你在此处可以访问什么？”的问题。SSO 通过受信任的身份提供者统合了第一个问题。目标应用程序仍然决定该身份是否可以查看记录、管理系统、加入网络网段或使用特定功能。
一个实用的思维模型如下所示：
用户
|
| 进行一次身份验证
v
身份提供商
|
| 发送可信的身份信息
v
应用程序或网络
|
| 应用本地权限
v
已授权会话
这种区别在人员入职、转岗和离职流程中至关重要。当员工离职时，可以禁用其中心身份，但每个连接的服务仍需要明确的授权模型和可靠的方式来移除权限。
实用规则：将 SSO 视为集中控制身份的一种方式，而不是替代应用程序权限的工具。
在规划 有线与无线部署 时，同样适用这一原则。网络接入是身份资产的一部分，因此团队应该决定哪些目录组可以获得哪些网络角色，而不是将接入权限绑定到共享密码上。
对于员工 WiFi 和感知身份的访问，Purple 的基于身份的网络连接 展示了如何将网络策略连接到个人身份，而非通用凭据。其结果是建立起个人、其目录状态与所获得访问权限之间更清晰的关联。
单点登录在企业联合身份中的工作原理
在企业联合体系中，身份提供者、依赖方和已签名的身份消息分别执行不同的工作。身份提供者对用户进行身份验证，而应用程序或网络服务等依赖方则验证生成的身份信息。
身份验证可以使用密码、多因素身份验证、设备状态或另一种经批准的方法。然后，提供者针对所请求的服务颁发已签名的断言或令牌。服务对该消息进行验证并创建自己的会话，因此凭据始终保留在身份提供者端。
联合流程
- 用户请求服务。 他们打开一个应用程序、管理门户或受保护的网络服务。
- 服务检查是否存在现有会话。 如果没有会话，它会将用户重定向到身份提供商。
- 身份提供商对用户进行认证。 它应用已配置的控制措施，例如 MFA 或条件访问。
- 身份提供商发布已签名的消息。 集成通常使用 SAML 断言或 OpenID Connect 令牌。
- 服务验证消息。 它检查发布者、签名、受众、到期时间和相关声明。
- 应用程序创建自己的会话。 它将已验证的身份映射到本地权限，并记录认证事件。
验证能够保护信任关系。英国国家网络安全中心建议，通过不可信网络接收到的 SAML 断言必须对照预期的证书颁发机构进行检查。未经过验证的断言可能会通过受信任的身份提供商连接提供一条账户劫持路径。（NCSC 身份与访问管理指南）
有效的身份核查仅授予经身份验证的身份，而非目标服务中的所有权限。应用应仅接收授权所需的断言，然后应用其自身的角色和资源规则。这种分离还允许相同的联合模式支持员工应用、管理门户和感知身份的网络服务。
企业环境中的 SAML、OIDC 与 OAuth
一旦明确了联合身份模型，协议选择就会变得更加容易。SAML 和 OpenID Connect 是企业级 SSO 的常用标准，而 OAuth 则主要是用于授权委派 API 访问权限的框架。将 OAuth 与身份验证混淆，可能会导致团队构建出一个无法满足其安全要求的身份流。
| 标准 | 实际作用 | 典型适用场景 |
|---|---|---|
| SAML | 交换已签名的身份断言 | 成熟的企业级应用及基于浏览器的应用程序 |
| OpenID Connect | 使用令牌添加身份层 | 现代 SaaS、Web 及面向移动端的服务 |
| OAuth | 委托对受保护资源的访问权限 | 代表用户或服务进行 API 访问 |
SAML 经常出现在成熟的企业级软件中，因为它使用的是成熟的浏览器联合模型。对于针对 JSON、REST 和基于令牌的交互设计的现代服务，OIDC 通常更为自然。正确的选择取决于应用程序支持的内容以及服务如何验证身份信息。
服务必须验证的内容
无论采用何种标准，依赖方在创建会话之前都必须验证接收到的身份材料。核心检查包括：
- 签发者：确认消息来自于预期的身份提供商。
- 签名：验证消息是否由受信任的密钥或证书签名。
- 受众：检查消息的目的地是否为本服务。
- 有效期：拒绝过期的断言或令牌。
- 声明：仅使用相关且经过验证的身份与组信息。
身份提供商可以集中管理多因素身份验证（MFA）、条件访问、密码禁止和组成员身份等策略。然后，应用程序会接收其进行自身授权决策所需的断言（claims），而不是保留用户身份验证流程的完整副本。
在集成 Microsoft Entra ID、Okta 或 Google Workspace 等平台时，这种分离非常有效。提供商负责处理身份验证策略，而连接的应用程序仍然负责其访问模型和会话控制。对于评估 基于 RADIUS 访问的 Okta 集成 的网络运营商，相同的原则同样适用：身份验证和网络授权必须协同工作，但它们并不是同一个控制措施。
SSO 引入的风险集中度问题
单个受损的身份提供商账户可能会同时打开多个连接的服务。SSO 减少了密码泛滥，但同时也将信任集中在身份提供商身上，使其成为一个高价值的控制平面。因此，组织需要评估联合身份验证如何影响其受损范围和恢复选项。NCSC 关于选择身份验证方法的指南 强调了这种信任集中是一种需要深思熟虑进行评估的风险。
SSO 能够整合登录事件。防钓鱼保护、设备信任和最小权限访问必须源于围绕联合体系结构构建的控制措施。强大的设计可以保护提供商、其创建的会话以及恢复访问权限的复原流程。
围绕提供商构建多层防御
控制措施应涵盖常规登录以及账户恢复期间使用的较隐蔽路径：
- 针对特权用户的强 MFA：在环境支持的情况下使用防钓鱼方法，尤其是针对管理员。
- 条件访问：在授予访问权限之前，评估设备状态、位置、会话风险和其他可用信号。
- 独立的管理员身份：将特权管理与日常普通活动分开。
- 身份验证监控：调查不可能的移动、令牌重放迹象、重复失败和意外的特权提升。
- 恢复保护：将服务台重置和紧急账户视为敏感的身份操作，并实施审批和监控。
NCSC 建议将企业 SSO 与强大的用户及设备身份验证（包括 MFA 或条件访问）相结合。它还建议针对 SaaS 使用 SSO，因为集中式控制措施能使用户和组管理保持更高一致性，并防止凭据被同步到每个应用程序中。其 关于身份与认证的云安全原则 阐述了这一方法。
SSO 减少了您必须管理的凭据数量。它使得管理连接服务的凭据和会话需要受到强有力的保护。
网络团队应将员工身份与访客身份区分开来。员工联合体系可以支持最小权限接入和及时撤销权限。访客身份验证绝不能仅仅因为两种流程都使用 Captive Portal 或无线基础架构，就继承员工目录的权限。
无密码 WiFi 与基于目录的网络访问
连接 WiFi 的员工不应使用在其离职后仍然有效的共享密码。基于目录的设计始于通过组织的身份提供商进行身份验证，然后将经过验证的身份或组映射到网络角色。因此，无线服务可以应用与其他地方相同的雇佣和访问决策，而不是维护单独的 WiFi 密码列表。
Purple 通过与 Microsoft Entra ID、Google Workspace 和 Okta 进行集成，为企业 WiFi 提供对此模型的支持。其 无密码 WiFi 方案 避免了共享凭据和本地 RADIUS 管理。目录更改可触发配置或撤销。员工的组身份决定网络访问权限，而禁用离职人员的目录账户即可取消该访问权限，无需等待任何人去更改通用密码。
将联合控制应用于网络
身份提供商、网络策略和监控机制应在访问决策上保持一致。将目录组映射到不同的网络角色，以便员工、外包人员和管理员默认不会获得相同的访问权限。保持断言或令牌的生存期较短，以限制过期身份材料的有效性。要求在身份提供商端启用 MFA，因为无线 SSO 并不会仅仅因为使用了 SSO 就自动变成 MFA。
记录成功和失败的身份验证事件，并将每个身份决策与最终的网络授权相关联。请在到期前测试证书轮转，因为联合信任失效可能会中断原本正常的 WiFi 访问。
多租户场所需要独立的边界。住宅区、学生宿舍、酒店和混合用途场所可以向住户或访客提供简便的接入，同时隔离租户流量和员工系统。iPSK 可以支持旧设备，而员工 SSO 则提供独立的员工身份路径。
访客 WiFi 还会涉及有关同意、保留和客户画像的决策。这篇 针对场所的访客数据指南 在网络设计之外提供了有价值的参考，同时 Purple 将基于身份的身份验证与无线访问体验无缝连接。
英国企业和场所的可衡量成效
一个实用的 SSO 业务方案始于组织不再需要管理的凭据。英国工程技术学会（Institution of Engineering and Technology）于 2024 年 4 月对 2,000 名 16 岁及以上的英国居民 进行的一项调查发现，只有 20% 的人能够正确识别安全密码。同一项调查还指出，五分之一 的人在多个网站或设备上重复使用密码，21% 的人使用重要日期，20% 的人使用宠物名字。调查还发现，38% 的人认为用数字替换字母可以提高密码安全性，65% 的人认为永远不应写下密码，77% 的人认为频繁更改密码可以提高安全性。(来源：IET 密码安全调查)
这些发现展示了要求用户为每个应用程序和网络创建并记住单独凭据的局限性。尽管网络钓鱼和账户妥协仍然是现实存在的风险，但集中化身份管理改变了企业应用控制的位置，并提升了管理员的响应速度。
对于运营方而言，成效非常切合实际：
- 更少的未托管凭据：用户需要创建、记住和重复使用的独立应用程序密码更少。
- 一致的策略：身份提供商可以在所有连接的服务中应用 MFA、条件访问和密码限制。
- 更快的撤销：只要连接的服务能够正确处理生命周期变更，禁用组织身份即可成为中央访问权限撤销操作。
- 更清晰的审计轨迹：日志可以将个人的身份与身份验证和网络授权决策关联起来。
- 减少重复的管理工作：团队可以集中维护身份策略，而无需在每个服务中重新创建相同的控制措施。
其价值远不止于减少登录提示。医疗机构可以按角色分配访问权限，酒店集团可以区分员工和宾客服务，物业运营商可以更清晰地维护租户和员工的权限归属。在每种情况下，可衡量的结果都是更小的凭据资产规模、更可靠的离职处理流程，以及关于谁获得了应用程序或网络角色访问权限的更强有力凭证。
在不引入新风险的情况下实施 SSO
安全的推广应始于身份模型，而非登录按钮。在适用应用场景中选择 SAML 或 OIDC，而不是将密码复制到应用或网络平台中。将 Identity Provider 确立为身份验证权威机构，然后让每个已连接的服务在创建会话之前验证签发者、签名、受众、到期时间和断言。
使用运营核查清单
- 从权威组开始： 通过由正确的业务或 IT 团队拥有的目录组提供访问权限。
- 定义变更规则： 角色变更不仅应当添加新权限，还应当移除旧权限。
- 集中处理离职人员： 禁用组织身份，并验证连接的应用和网络角色是否得到正确响应。
- 保护应急访问： 将紧急账户与日常管理分开，密切监控并测试其恢复流程。
- 区分员工与访客： 员工 SSO 可以支持最小权限访问与权限撤销。访客认证绝不能继承员工权限。
- 测试信任变更： 在生产环境中投入使用前，验证证书轮换、令牌过期、会话终止以及提供商宕机情况。
- 审查监控： 确认认证事件、管理操作和网络授权决策均可用于调查。
场馆可能还需要支持多个网络厂商，而不是替换其现有的无线资产。Purple 旨在配合 Meraki、Aruba、Ruckus、Mist 和 UniFi 工作，其公开的部署模型所需时间以周计算，而非以月计算。请将这些功能视为实施层面的考量因素，而非架构审查的替代方案。如需更广泛地了解技术提供商如何描述安全防护措施，AdManage.ai 的信任与控制 提供了一个有价值的参考对比点。
核心决策在于，企业是否能够针对每一个已连接的服务明确说明：由谁对用户进行身份验证、信任哪些断言 (claims)、如何分配权限以及身份发生变更时会发生什么。SSO 只是身份与访问管理计划中的一个层级。它并不能替代 MFA、条件访问、身份验证监控、恢复控制或生命周期治理。
Purple 将员工身份与无密码 WiFi、基于目录的网络角色以及独立的访客访问连接起来，支持与 Microsoft Entra ID、Google Workspace 和 Okta 集成。请访问 Purple，评估其基于身份的网络模型如何融入您现有的无线环境和 SSO 推广计划。
