Web安全
计算机网络
物理层
数据链路层
网络层
运输层(传输层)
应用层
基础漏洞
01前端基础【HTML】
02前端基础【CSS】
03后端基础【PHP速通】
04后端基础【PHP面向对象】
05MySQL基础操作
06前后端联动【代码练习】
07SQL注入概述
07SQL 注入类型
08SQL注入 Labs
08SQL注入速查表
09XSS
09XSS【概述版】
09XSS Labs
10跨站请求伪造【CSRF】
11服务器端请求伪造【SSRF】
12XML 外部实体注入【XXE】
13代码执行漏洞
14命令执行漏洞
15文件包含漏洞
16文件上传漏洞
17反序列化漏洞
18业务逻辑漏洞
19未授权访问漏洞集合
20跨源资源共享【CORS】
21SSTI模板注入
22并发漏洞
23点击劫持【Clickjacking 】
24请求走私
25路径遍历
26访问控制
27身份验证漏洞
28WebSocket
29Web缓存中毒
30HTTP 主机头攻击
31信息泄露漏洞
32原型污染
33NoSQL注入
小程序
小程序抓包
SessionKey
Appsecret与access_token
openid
数据库
MySQL
Oracle
MongoDB
Redis
PostgreSQL
SQL server
中间件
Nginx
Apache HTTP Server
IIS
Tomcat
框架
ThinkPHP
Spring
Spring Boot
Django
访问控制
身份认证(Authentication)
授权(Authorization)
单点登录(SSO)
零信任(ZTA)
分布式身份(DID)
-
+
首页
单点登录(SSO)
单点登录(Single Sign-On,简称 SSO)是身份认证领域的核心解决方案,旨在解决 “多系统重复登录” 的痛点(用户只需在统一认证中心完成一次身份验证,即可免登录访问所有相互信任的关联系统。)。 ## 定义 SSO 并非单一技术,而是一种**基于 “信任联盟” 的身份认证架构方案**,其核心逻辑是: - 建立一个 “统一认证中心(Identity Provider,简称 IdP)”,所有信任该中心的系统(Service Provider,简称 SP)不再单独维护用户账号和认证逻辑; - 用户首次访问某 SP 时,需跳转至 IdP 完成身份验证;验证通过后,IdP 向 SP 发放 “身份凭证”,SP 基于该凭证确认用户身份,无需再次登录; - 后续用户访问其他信任 IdP 的 SP 时,IdP 直接复用已有的 “全局会话”,无需用户重复输入凭证,实现 “一次登录,多系统通行”。 > 关键特征 **统一身份源**:所有 SP 共享 IdP 的用户身份数据(如账号、部门、角色),避免 “多系统账号不一致”(如 OA 用手机号、CRM 用工号); **跨系统会话共享**:IdP 维护 “全局会话”(用户登录状态),SP 维护 “局部会话”(用户在该系统的访问状态),全局会话有效时,SP 可直接创建局部会话; **信任机制**:SP 与 IdP 之间通过预配置的 “信任关系”(如数字签名、密钥)确保身份凭证不被篡改或伪造; **无感知体验**:用户仅需首次登录时输入凭证,后续访问其他 SP 时完全免交互,大幅提升操作效率。 > 差异 | 对比维度 | 普通登录(多系统独立认证) | SSO(统一认证) | | ------------ | ------------------------------------------ | ------------------------------------- | | 认证中心 | 每个系统自建认证模块(如 OA 有独立登录页) | 统一 IdP,所有 SP 依赖 IdP 认证 | | 用户账号 | 多系统可能需单独注册(或账号不一致) | 仅需 IdP 维护一套账号,多 SP 共享 | | 登录体验 | 访问每个系统需重复输入账号密码 | 一次登录,免登录访问所有信任 SP | | 身份数据管理 | 多系统重复存储用户数据,易不一致 | 集中存储在 IdP,SP 按需获取,数据统一 | | 安全管控 | 每个系统独立配置安全策略(如密码复杂度) | 统一在 IdP 配置安全策略(如 MFA) | ## 工作原理 SSO 的核心是 “**全局会话 + 身份凭证**” 的协同,其完整工作流程可分为 “首次登录某 SP” 和 “访问其他 SP 免登” 两个阶段,以下以 “企业员工访问 OA(SP1)和 CRM(SP2)” 为例解析: > 第一阶段:用户首次访问SP1(OA系统) **发起请求**:用户在浏览器输入 OA 地址,OA 检测到用户未创建 “局部会话”(无 OA 的登录 Cookie),判定用户未登录; 跳转至 IdP:OA 生成一个 “随机状态码(State)”(用于防 CSRF 攻击),将用户重定向至 IdP 的登录页,携带参数: - `service`:目标 SP 的标识(如`https://oa.company.com`),告知 IdP “为哪个 SP 生成凭证”; - `state`:OA 生成的随机码,后续需验证; **用户身份验证**:IdP 检测到用户未创建 “全局会话”(无 IdP 的登录 Cookie),展示登录页,要求用户输入凭证(如账号密码 + MFA); **创建全局会话**:IdP 验证凭证有效后,在服务器端创建 “全局会话”(记录用户 ID、登录时间、过期时间),并向用户浏览器写入 IdP 的 “全局会话 Cookie”(用于标识全局会话); **生成身份凭证**:IdP 生成 “服务票据(Service Ticket,简称 ST)”—— 这是 SP 可验证的短期身份凭证(通常有效期 10 秒内,避免泄露后被滥用); 重定向回 SP1:IdP 将用户重定向至 OA 的 “凭证验证接口”,携带参数: - `ticket`:生成的 ST; - `state`:OA 之前传递的随机码; **SP1 验证凭证**:OA 收到 ST 后,通过 “后端接口” 向 IdP 发送验证请求(携带 ST 和 SP1 的标识);IdP 验证 ST 有效(未过期、属于该 SP)后,返回用户的身份信息(如用户 ID=123,角色 = 销售); **创建局部会话**:OA 验证通过后,在服务器端创建 “局部会话”,并向用户浏览器写入 OA 的 “局部会话 Cookie”;同时,向用户返回 OA 的首页,首次登录完成。 > 第二阶段:用户访问SP2(CRM系统) **发起请求**:用户在浏览器输入 CRM 地址,CRM 检测到无 “局部会话”,判定用户未登录; **跳转至 IdP**:CRM 生成 state 参数,重定向至 IdP 的登录页,携带`service=https://crm.company.com`; **IdP 检测全局会话**:IdP 读取用户浏览器的 “全局会话 Cookie”,查询到服务器端存在有效的全局会话,判定用户已登录,无需再次展示登录页; **生成新的 ST**:IdP 为 CRM 生成新的 ST(与 OA 的 ST 不同,每个 SP 的 ST 独立); **重定向回 SP2**:IdP 将用户重定向至 CRM 的凭证验证接口,携带`ticket`和`state`; **SP2 验证凭证与创建局部会话**:CRM 向 IdP 验证 ST 有效后,获取用户身份信息,创建 “局部会话”,返回 CRM 首页; **免登完成**:用户无需输入任何凭证,直接进入 CRM 系统,实现跨系统免登。 > 相关概念 **全局会话(Global Session)**:由 IdP 维护的用户登录状态,存储在 IdP 服务器端(如 Redis),包含用户 ID、登录时间、过期时间(通常 2 小时),通过 IdP 的 Cookie 标识; **局部会话(Local Session)**:由 SP 维护的用户在该系统的访问状态,存储在 SP 服务器端,仅在当前 SP 有效,通过 SP 的 Cookie 标识; **服务票据(ST)**:IdP 发放给 SP 的短期身份凭证,仅用于单次验证(验证后立即失效),避免长期凭证泄露风险; **信任关系**:SP 与 IdP 之间的 “约定”,通常通过以下方式确保安全: - 预共享密钥:SP 和 IdP 使用相同的密钥对 ST 进行签名 / 验签; - 数字证书:IdP 使用私钥签名身份信息,SP 使用 IdP 的公钥验签; - 白名单:IdP 仅向已注册的 SP 发放 ST,防止非法 SP 获取凭证。 ## 主流SSO协议对比 SSO 的落地依赖标准化协议(解决 “SP 与 IdP 如何通信”)和核心组件(解决 “功能落地”),不同协议适用于不同场景(如互联网、企业级、开源)。 SSO 协议的核心是定义 “SP 与 IdP 的通信格式” 和 “身份凭证的结构”,目前主流协议有 OIDC、SAML 2.0、CAS,三者的差异决定了适用场景。 | 协议类型 | 核心特点 | 数据格式 | 适用场景 | 典型案例 | | ---------------------------------------------- | ------------------------------------------- | --------------- | --------------------------------------------------- | ------------------------------------- | | OIDC(OpenID Connect) | 基于 OAuth 2.0 扩展,轻量级,支持 JSON 格式 | JSON | 互联网场景(APP、小程序、Web 服务)、移动终端 | 微信登录、谷歌登录、阿里云 SSO | | SAML 2.0(Security Assertion Markup Language) | 企业级标准,安全性高,支持复杂身份属性传递 | XML | 企业内部系统(ERP、SAP)、跨组织认证(政府 / 金融) | 微软 AD FS、IBM SSO、企业 CRM/OA 集成 | | CAS(Central Authentication Service) | 开源框架,轻量级,专注 SSO 认证,无授权能力 | 自定义 XML/JSON | 小型企业、教育机构、开源系统 | 高校图书馆系统、开源 ERP(如 Odoo) | ## 核心技术组件 无论采用哪种协议,SSO 的落地都需要以下核心组件支撑: > 身份提供商(Identity provider,IdP) SSO 的核心,负责用户认证、全局会话管理、凭证发放,需具备: - 用户管理模块:存储 / 查询用户账号、密码哈希、属性(如部门); - 认证模块:支持密码、MFA、生物识别等认证方式; - 凭证生成模块:发放 ST、ID Token 等凭证; - 信任管理模块:管理 SP 的注册信息(如 SP 标识、公钥)。 > 服务提供商(service provider,SP) 依赖 IdP 认证的业务系统,需具备: - 跳转模块:检测到未登录时,重定向至 IdP; - 凭证验证模块:向 IdP 验证 ST/ID Token 的有效性; - 局部会话模块:维护用户在该 SP 的访问状态; > 身份源(Identity source) 为 IdP 提供用户数据的系统,如: - LDAP/AD 域:企业内部常用的身份存储(如微软 AD 域); - 数据库:小型系统常用的用户数据存储; - 第三方身份源:如互联网场景的微信 / QQ 用户体系; > 安全组件 确保 SSO 流程安全,包括: - 加密模块:对传输的凭证(如 ST)进行加密; - 签名模块:对身份信息(如 ID Token、SAML 断言)进行数字签名; - 防攻击模块:防御 CSRF、XSS、重放攻击(如 state 参数、ST 短期有效)。 ## 分类 根据 “部署模式” 和 “信任范围”,SSO 可分为不同类型,适用于不同场景。 > 按部署模式划分 **集中式SSO** - 特点:仅部署一个 IdP,所有 SP 直接与该 IdP 建立信任关系; - 优势:架构简单、维护成本低、身份数据完全统一; - 劣势:IdP 单点故障会导致所有 SP 无法认证; - 适用场景:中小型企业(内部系统数量≤50)、单一组织架构的机构(如学校、医院)。 **分布式SSO(联邦SSO)** - 特点:部署多个 IdP,IdP 之间建立 “联邦信任”(如 A 公司的 IdP 信任 B 公司的 IdP),用户可通过任一 IdP 认证访问所有联邦内的 SP; - 核心技术:SAML 2.0(支持跨 IdP 信任)、OIDC Federation; - 优势:无单点故障、支持跨组织协作; - 劣势:架构复杂、信任关系管理成本高; - 适用场景:大型企业(多子公司、多地域)、跨组织协作(如供应链系统:供应商通过自身 IdP 访问核心企业的 SP)。 > 按信任范围划分 **内部SSO** - 信任范围:仅企业 / 组织内部的 SP 信任 IdP; - 典型场景:企业内部 OA、CRM、ERP、云存储系统的统一登录; - 特点:用户身份数据存储在内部 IdP,不对外暴露。 **跨域SSO** - 信任范围:不同域名的 SP 信任同一 IdP(如`oa.company.com`和`crm.company.com`属于不同子域名); - 核心挑战:浏览器的 “同源策略” 限制跨域 Cookie 访问,需通过 “后端接口验证凭证” 或 “共享域名 Cookie” 解决; - 典型场景:同一品牌下的多 Web 服务(如阿里系的淘宝`taobao.com`和支付宝`alipay.com`)。 **跨组织SSO(联邦SSO)** - 信任范围:不同组织的 SP 和 IdP 之间建立信任(如 A 公司的 SP 信任 B 公司的 IdP); - 典型场景:政府部门间系统(如税务局 IdP 认证后可访问工商局 SP)、供应链协作(供应商 IdP 认证后可访问核心企业的采购 SP); - 核心要求:需符合行业标准协议(如 SAML 2.0),确保跨组织身份安全传递。 ## 主要风险挑战 **IdP 单点故障风险** 风险:若 IdP 宕机(如服务器故障、网络中断),所有依赖 IdP 的 SP 将无法完成认证,导致业务中断; 应对方案: - 部署 IdP 集群(多节点负载均衡),确保高可用(可用性目标 99.99%); - 部分关键 SP 配置 “离线认证备份方案”(如本地缓存短期身份凭证)。 **安全依赖风险** 风险:IdP 成为 “单点攻击目标”—— 若 IdP 被攻破(如黑客获取用户凭证库),所有 SP 的安全防线将全面崩溃; 应对方案: - 强化 IdP 安全:采用加密存储密码(如 bcrypt 哈希)、部署 WAF 防御 Web 攻击、定期安全渗透测试; - 最小权限原则:IdP 向 SP 传递的身份信息仅包含 “必要字段”(如仅传用户 ID,不传手机号 / 邮箱); - 实时监控:监控 IdP 的异常操作(如批量获取凭证、高频验证请求),触发告警。 **跨域与兼容性问题** 风险: - 浏览器同源策略限制跨域 Cookie 访问,可能导致全局会话无法识别; - 老旧系统(如基于 COBOL 的遗留系统)难以集成 SSO 客户端; 应对方案: - 跨域问题:使用 “后端验证凭证”(SP 通过 API 向 IdP 验证,不依赖 Cookie)或 “父域名共享 Cookie”; - 兼容性问题:为老旧系统开发 “SSO 代理”(代理接收 IdP 凭证,转换为老旧系统的登录格式)。 **合规与隐私风险** 风险:若 IdP 存储用户敏感信息(如身份证号、银行卡号),跨组织传递时可能违反数据隐私法规(如 GDPR、《个人信息保护法》); 应对方案: - 数据脱敏:向 SP 传递身份信息时脱敏(如身份证号显示为 “110101********1234”); - 合规审计:确保 SSO 流程符合行业法规(如金融行业需满足 PCI DSS),保留完整的认证日志; - 用户授权:跨组织传递身份信息前,需获取用户明确同意(如 “是否允许将您的姓名和部门信息共享给供应商系统”)。
毛林
2025年10月11日 11:37
转发文档
收藏文档
上一篇
下一篇
手机扫码
复制链接
手机扫一扫转发分享
复制链接
Markdown文件
PDF文档(打印)
分享
链接
类型
密码
更新密码