📚 课程目录第4章单点登录（SSO）与统一身份管理

4、单点登录（SSO）与统一身份管理：LDAP/AD集成、OAuth2.0与SAML协议、集中式密码策略落地

说到弱口令，很多人第一反应就是「让用户改个复杂密码」。但我在实际项目中见过太多这样的情况：改了密码，过两周又改回123456。为什么？因为用户要记的密码太多了。

你想想看，一个普通员工，可能要登录OA、邮箱、VPN、代码仓库、运维平台……每个系统一套密码。记不住怎么办？要么写便签上，要么所有系统用同一个密码。这就是弱口令的温床。

所以，真正治本的办法是什么？单点登录（SSO）。让用户只记住一个密码，其他系统全部自动登录。密码少了，复杂度就能提上去，用户也不会抱怨。

核心思路：统一身份管理 + 集中认证 = 密码策略可落地。用户只面对一个认证入口，安全团队只管控一个密码策略点。

4.1 LDAP/AD集成：企业目录服务的基石

LDAP（轻量级目录访问协议）和微软的Active Directory（AD），说白了就是企业的「通讯录+认证中心」。所有用户信息、组织架构、密码哈希，都存这里面。

我习惯把LDAP/AD比作「大管家」。各个业务系统不需要自己管用户，只需要问大管家：「这个人是谁？密码对不对？」大管家统一回答。

4.1.1 集成方式与密码策略

LDAP/AD集成通常分两步：

认证绑定：业务系统通过LDAP协议连接到目录服务器，验证用户身份。
属性同步：获取用户组、角色等信息，用于授权。

密码策略可以在AD侧统一配置：

密码长度最小值（我建议至少12位）
密码复杂性要求（大写+小写+数字+特殊字符）
密码历史记录（记住最近10个密码，防止循环使用）
账户锁定阈值（5次失败锁定30分钟）

我曾经遇到一个坑：某公司把AD密码策略设得很严，但忘了配置「密码最长使用期限」。结果一个员工的密码用了3年没改，泄露了都不知道。记住，密码过期策略一定要开，90天是个不错的起点。

4.1.2 LDAP集成配置示例（Java + Spring Security）

@Configuration
@EnableWebSecurity
public class LdapSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth
            .ldapAuthentication()
                .userDnPatterns("uid={0},ou=people")
                .groupSearchBase("ou=groups")
                .contextSource()
                    .url("ldap://ldap.company.com:389/dc=company,dc=com")
                    .managerDn("cn=admin,dc=company,dc=com")
                    .managerPassword("your-strong-password");
    }
}

嗯，这里要注意：managerPassword绝对不能硬编码。我一般用Vault或K8s Secret管理。

4.2 OAuth2.0与SAML协议：现代SSO的两大支柱

LDAP/AD解决了「统一存密码」的问题，但现代应用场景更复杂：有Web应用、有移动端、有第三方服务。这时候就需要OAuth2.0和SAML上场了。

特性	OAuth2.0	SAML 2.0
主要用途	授权 + 身份委托	企业级单点登录
数据格式	JSON（轻量）	XML（重量）
适用场景	API授权、移动端、第三方登录	企业内部Web应用、跨域SSO
密码暴露风险	低（使用Token）	低（使用断言）
我个人的选择	对外服务、微服务架构	传统企业、政府内网

4.2.1 OAuth2.0的密码策略落地

OAuth2.0本身不直接管密码，但它依赖的授权服务器（如Keycloak、Okta）可以集中管理密码策略。我在项目中常用的做法：

授权服务器强制密码复杂度
启用多因素认证（MFA）
Token有效期设短（我习惯Access Token 15分钟，Refresh Token 7天）
禁止隐式授权模式（Implicit Grant），改用授权码模式（Authorization Code + PKCE）

一个小技巧：OAuth2.0的Client Secret一定要轮换。我见过有人把Secret写死在GitHub仓库里，结果被爬虫扫到，整个API被滥用。建议每90天轮换一次，用自动化脚本完成。

4.2.2 SAML协议与ADFS集成

SAML在企业环境里很常见，尤其是微软的ADFS（Active Directory Federation Services）。它的核心是「断言」——身份提供者（IdP）告诉服务提供者（SP）：「这个用户已经认证过了，这是他的属性。」

配置SAML时，密码策略完全由IdP侧控制。也就是说，你只要把AD的密码策略设好，所有接入SAML的应用自动继承。这就是集中式管理的威力。

<!-- SAML断言示例（简化） -->
<saml:Assertion>
  <saml:Subject>
    <saml:NameID>zhangsan@company.com</saml:NameID>
    <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>
  </saml:Subject>
  <saml:AttributeStatement>
    <saml:Attribute Name="memberOf">
      <saml:AttributeValue>CN=VPN_Users,OU=Groups,DC=company,DC=com</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

4.3 集中式密码策略落地：从理论到实践

前面讲了协议和集成，但最终要落到一个问题上：怎么让密码策略真正被执行？

我见过太多公司，安全部门写了一份几十页的密码策略文档，结果没人看，没人执行。为什么？因为没有技术手段强制落地。

4.3.1 策略落地的三个层次

策略定义层：在IdP（如AD、Keycloak）中配置密码规则
策略执行层：所有接入SSO的应用强制走IdP认证，绕过者阻断
策略审计层：定期扫描弱口令、检查密码过期情况、审计登录日志

我的经验：第三层往往被忽略。你设了密码策略，但用户可以通过「忘记密码」功能绕过吗？你的SSO系统有没有后门账号？这些都要审计。我曾经在一个客户那里发现，他们的AD里有个10年没改密码的「管理员」账号，密码还是Admin123。这就是审计缺失的后果。

4.3.2 集中式密码策略清单

策略项	推荐值	说明
密码最小长度	12位	8位在GPU暴力破解下已经不安全
密码复杂度	大写+小写+数字+特殊字符	至少包含3类
密码历史	记住最近10个	防止循环使用旧密码
密码最长使用期	90天	敏感系统可缩短到60天
账户锁定阈值	5次失败	锁定30分钟或需管理员解锁
MFA强制	所有管理员 + 远程访问	建议全员启用

4.3.3 落地检查清单

所有业务系统是否已接入SSO？有没有「漏网之鱼」？
SSO系统本身的管理员账号是否启用了MFA？
密码重置流程是否安全？（我曾经见过密码重置链接直接发到旧邮箱的……）
是否有定期密码审计脚本？
离职员工的账号是否及时禁用？

注意：集中式管理意味着单点故障。如果SSO系统挂了，所有业务都登不进去。所以一定要做高可用部署，至少双节点+负载均衡。另外，准备一个「紧急逃生账号」——物理隔离、高强度密码、双人保管，用于SSO故障时的应急恢复。

4.4 本章知识体系图

下面这张图展示了SSO与统一身份管理的核心架构和流程：

4.5 总结与建议

单点登录不是银弹，但它确实是弱口令治理中最有效的手段之一。我个人总结了几条原则：

能集中就别分散：所有系统接入同一个身份源，密码策略才能统一落地
协议选型看场景：内部用SAML，对外用OAuth2.0，移动端用OIDC
别忘了审计：策略设了不等于执行了，定期检查才能发现问题
做好容灾：SSO挂了就是全网瘫痪，高可用和逃生通道必须准备

嗯，这一章的内容就到这里。记住，统一身份管理不是技术问题，而是管理问题。技术只是工具，真正落地靠的是流程和执行力。