Django应用对接MS Azure如何实现SAML SSO替代OAuth认证

完全可行，我先后给两个生产环境的Django项目做过Azure AD侧从MSAL（OAuth/OIDC）到SAML2的认证切换，整个流程没有不可逾越的障碍，只要把认证层的逻辑替换掉，你原来写的业务侧权限、会话、用户匹配逻辑几乎可以全量复用，上线后的稳定性和之前MSAL方案没有差异。

不建议直接裸写pysaml2的底层逻辑，Django生态已经有成熟的封装，能省掉非常多重复踩坑的工作，我自己落地的流程是这样的：

• 先配Azure AD侧，再写代码。进Azure AD企业应用列表新建一个非画廊应用，单点登录协议选SAML，填三个核心参数：标识符（实体ID） 填你应用的全局唯一标识（一般用你服务的域名就行，比如https://yourapp.com/saml/metadata/）、回复URL（ACS地址） 填你服务用来接收SAML断言的路径，比如https://yourapp.com/saml/acs/、登录URL 填你自己服务的登录入口。配置完直接下载Azure AD生成的联合元数据XML文件，别手动抄IdP登录地址、签名证书、NameID格式这些参数，手动抄十有八九会错，元数据文件里会带全所有IdP侧的配置信息。
• 装依赖用django-saml2-auth，这个库底层就是封装的pysaml2，已经把ACS路由处理、断言签名校验、会话初始化这些通用逻辑写完了，比自己从零搭pysaml2省至少80%的工作量。装完把刚才下的Azure AD元数据文件放到项目配置目录，在settings.py里配SAML核心参数：
  • 你自己应用（SP端）的实体ID、ACS路径，必须和Azure AD侧填的内容完全一致，差一个斜杠都会报错
  • 强制打开WANT_RESPONSE_SIGNED、WANT_ASSERTIONS_SIGNED两个签名校验开关，Azure AD默认会对响应和断言全签名，关了会有安全风险
  • 做好属性映射：SAML返回的用户字段是带命名空间的，和你之前MSAL拿到的字段名不一样，比如邮箱对应http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress，Azure AD用户唯一ID对应http://schemas.microsoft.com/identity/claims/objectidentifier，显示名对应http://schemas.microsoft.com/identity/claims/displayname，把这些字段映射到你本地User表的对应字段，用户匹配逻辑和之前MSAL保持一致，避免切换后重复创建用户。
• 做流程衔接：把原来指向MSAL登录的入口跳转到SAML登录路由，认证成功后的用户信息拉取、本地会话创建、角色权限赋值逻辑直接复用原来的代码就行，不用改。如果要做单点登出，就多配一个SLO路由填到Azure AD的SAML配置里，登出时会同时清掉本地会话和Azure AD侧的会话。

• 绝对不要硬编码Azure AD的IdP参数，包括签名证书、登录/登出端点。Azure AD会定期自动轮换签名证书，你硬编码的话哪天证书轮换了全量用户都会登不上，直接用元数据文件做配置，库会自动读取最新的证书和端点信息，不用手动更新。
• 服务器一定要开NTP时间同步。SAML断言的时间戳校验非常严格，服务端时间和Azure AD时间差超过5分钟就会抛断言无效的错误，这个问题排查起来特别隐蔽，很多人第一次对接会卡在这里半天找不到原因。
• 签名算法强制选SHA256，别用默认的SHA1，Azure AD现在已经对SHA1签名做了兼容限制，用SHA1大概率会出签名校验失败的问题。
• 如果你之前用MSAL的时候拉了Azure AD的用户组、应用角色做权限控制，一定要在Azure AD的SAML声明配置里把组、角色声明加进去，不然SAML断言里不会带这些字段，上线后所有用户的权限都会异常。
• 测试的时候别只测SP发起的登录流程，一定要测IdP发起的登录——也就是用户直接在Azure AD「我的应用」面板里点你的应用图标跳转的场景，很多人配的时候只测了自己服务点登录跳Azure的流程，IdP发起的场景因为ACS配置不对直接500。
• 上线前一定要留个不走SAML的超级管理员本地登录入口，加个IP白名单限制只允许办公网访问就行，别把所有登录入口都切到SAML，万一配置出错你连后台都进不去改参数。

我自己上次做切换，连配置带测试加灰度上线总共花了不到1个工作日，跑了快3年没出过认证层面的故障，完全可以放心落地。

内容的提问来源于stack exchange，提问作者Galeej