ADFS 2.0不处理SAML AuthnRequest中的“扩展”标记 - 抛出异常MSIS7015

Question

我们目前安装了ADFS 2.0并安装了修补程序2汇总，并且作为使用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”正确在namspaces下面“ 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，那么一切都会顺利进行。事实上，我可以保留'Extensions'容器并简单地编辑供应商名称空间元素，并且ADFS成功。

现在，我想我有3个问题：

1. 为什么参考号未记录到ADFS日志？这真的有助于我早期的调试工作
2. ADFS的SAML处理程序无法处理Extensions元素中定义的自定义元素是否是一个已知问题，如果是这样，是否有办法添加支持（或者至少在处理它时不会崩溃）？我的供应商已提出更改生成的SAML AuthnRequest以省略该标记，但表示可能需要一些时间' - 我们都知道这意味着什么......
3. 有人认为安装ADFS修补程序汇总3会解决这种情况吗？我在文档中没有看到任何表示肯定的内容。

感谢您的反馈。

Answer 1

当遇到MSIS7015 ADFS错误时，最好的启动方法是启用ADFS跟踪。以admin身份登录ADFS服务器并运行以下命令。如果您有一台非常繁忙的ADFS服务器，那么在服务器不忙时可能会这样做。

C:\Windows\System32\> wevtutil sl “AD FS Tracing/Debug” /L:5
C:\Windows\System32\> eventvwr.msc

在Event Viewer中选择“Application and Services Logs”，右键单击并选择“View - Show Analytics and Debug Logs” 转到AD FS跟踪 - 调试，右键单击并选择“启用日志”以启动跟踪调试。

处理ADFS登录/注销步骤，完成后，转到事件查看器mmc找到子树AD FS跟踪 - 调试，右键单击并选择“禁用日志”以停止跟踪调试。

查找EventID 49 - 传入的AuthRequest - 并且没有使用CAPs值发送验证值。例如，在我的情况下，我收到了以下值：IsPassive = 'False'，ForceAuthn = 'False '

就我而言，为了解决这个问题，我需要做的就是为不同的端点创建传入的声明转换器规则。

一旦CAP转换为小写真假，验证就开始工作了。