【发布时间】：2015-08-12 08:20:22
【问题描述】：
我们目前安装了带有修补程序 2 汇总的 ADFS 2.0，并且作为多个使用 SAML 身份验证的外部依赖方的身份提供者正常工作。本周我们尝试添加一个新的依赖方，但是，当客户端提出来自新方的身份验证请求时，ADFS 只会返回一个带有参考号的错误页面，并且不会提示客户端输入凭据。
我检查了服务器 ADFS 2.0 事件日志中的参考号，但它不存在（搜索相关 id 列）。我启用了 ADFS 跟踪日志，重新执行了身份验证尝试并显示了此消息：
Failed to process the Web request because the request is not valid. Cannot get protocol message from HTTP query. The following errors occurred when trying to parse incoming HTTP request:
Microsoft.IdentityServer.Protocols.Saml.HttpSamlMessageException: MSIS7015: This request does not contain the expected protocol message or incorrect protocol parameters were found according to the HTTP SAML protocol bindings.
at Microsoft.IdentityServer.Web.HttpSamlMessageFactory.CreateMessage(HttpContext httpContext)
at Microsoft.IdentityServer.Web.FederationPassiveContext.EnsureCurrent(HttpContext context)
由于消息表明请求格式不正确，我继续通过 xmlsectool 运行请求，并根据 SAML 协议 XSD (http://docs.oasis-open.org/security/saml/v2.0/saml-schema-protocol-2.0.xsd) 对其进行了验证，结果返回干净：
C:\Users\ebennett\Desktop\xmlsectool-1.2.0>xmlsectool.bat --validateSchema --inFile metaauth_kld_request.xml --schemaDirectory . --verbose
INFO XmlSecTool - Reading XML document from file 'metaauth_kld_request.xml'
DEBUG XmlSecTool - Building DOM parser
DEBUG XmlSecTool - Parsing XML input stream
INFO XmlSecTool - XML document parsed and is well-formed.
DEBUG XmlSecTool - Building W3 XML Schema from file/directory 'C:\Users\ebennett\Desktop\xmlsectool-1.2.0\.'
DEBUG XmlSecTool - Schema validating XML document
INFO XmlSecTool - XML document is schema valid
所以，我认为 ADFS 并未完全符合 SAML 规范。为了验证，我手动检查了提交的 AuthnRequest，发现我们的供应商正在使用 'Extensions' 元素来嵌入他们的自定义属性（根据 SAML 规范，这是有效的）（注意：正确命名空间下面的“ns33”“ urn:oasis:names:tc:SAML:2.0:protocol" 请求中的其他位置）
<ns33:Extensions>
<vendor_ns:fedId xmlns:vendor_ns="urn:vendor.name.here" name="fedId" value="http://idmfederation.vendorname.org"/>
</ns33:Extensions>
如果我从 AuthnRequest 中删除前一个元素并将其重新提交到 ADFS，一切都会顺利进行。而且，事实上，我可以离开“扩展”容器并简单地编辑掉供应商命名空间元素，ADFS 就成功了。
现在，我想我有 3 个问题：
- 为什么参考号没有记录到 ADFS 日志中？这确实有助于我早期的调试工作
- ADFS 的 SAML 处理程序无法处理 Extensions 元素中定义的自定义元素，这是一个已知问题吗？如果是，是否有办法添加支持（或至少在处理时不会崩溃）？我的供应商提出更改生成的 SAML AuthnRequest 以省略该标记，但表示“可能需要一些时间”——我们都知道这意味着什么......
- 有人认为安装 ADFS 修补程序汇总 3 可以解决这种情况吗？我在文档中没有看到任何表示肯定的内容。
感谢您的反馈。
【问题讨论】：
-
回复：#2 - ADFS 符合 SAML 2.0 IDP Lite 和 SP Lite。但是，我希望 ADFS 并非旨在处理自定义扩展，无论版本如何。基本上，仅仅因为规范中允许某个扩展，并不意味着每个供应商都必须支持它才能合规。
-
啊，我以前不知道“Lite”操作模式。感谢您提供的信息-我认为这将为我提供一个专注于调查的方向。是的，我不希望 ADFS 会对供应商扩展做任何有用的事情——但我曾预计它不会在给出这些额外信息时崩溃。毕竟，ADFS 确实接受 Extensions 容器作为 AuthnRequest 的一部分而不会崩溃……为什么不优雅地忽略容器的内容呢？再次感谢您的意见。