关于IdP发起的SAML RequestLogout在Office 365中失效的技术问询

我之前帮同行排查过类似的Office 365 SAML注销问题，结合你的开发场景，给你几个针对性的排查方向，应该能帮你定位问题：

• 签名位置与算法严格匹配：Office 365对SAML注销请求的签名逻辑要求很细致，要确认两个点：一是签名是嵌入在<samlp:LogoutRequest>元素内部作为子元素，而非外层包裹整个请求；二是签名算法必须和元数据中指定的一致——微软当前仅支持http://www.w3.org/2001/04/xmldsig-more#rsa-sha256，SHA1已经被完全禁用，别搞错了。

• NameID必须与登录时完全一致：注销请求里的<NameID>元素，不管是格式（比如urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress）还是具体值，都要和登录流程中发送给Office 365的完全匹配。比如登录用的是用户的UPN（user@tenant.onmicrosoft.com），注销时就不能换成用户的别名或者其他邮箱，哪怕两者指向同一个用户也不行。

• Destination和Issuer属性不能出错：

  • <samlp:LogoutRequest>的Destination属性必须严格对应元数据中的注销端点，微软的标准端点通常是类似https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0的地址；
  • Issuer的实体ID要和登录请求中使用的完全一致，大小写、末尾的斜杠这类细节都不能差。

• XML规范化方法要正确：签名时使用的Canonicalization方法必须是http://www.w3.org/2001/10/xml-exc-c14n#（独占规范化），不要使用包含注释的变体。Office 365对XML的格式校验非常严格，哪怕多一个空格、换行或者注释，都会导致签名验证失败。

• 提交方式与参数规范：IdP发起的注销请求必须用HTTP POST方法提交，POST参数名固定为SAMLRequest；如果是嵌入式签名，要确保签名元素正确嵌入到XML中；如果是分离式签名，要同时带上Signature和SigAlg参数，且SigAlg的值要和签名算法一致。

• 查看Azure AD的详细错误日志：让租户管理员登录Azure门户，进入「Enterprise Applications」找到你的应用，然后查看「Sign-ins」日志里的失败注销记录——日志里会有具体的错误代码和原因描述，比如“签名验证失败”“NameID不匹配”等，这是最快定位问题的方式。

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