我们设置了一个 ADFS 2.0 实例。我们将其用于 3rd 方网络应用单点登录。一切都与现有的应用程序完美配合，App1 与 SAML 2.0，包括当用户被重定向到我们的 ADFS 服务器时的 IWA 传递。
我刚刚使用 SAML 2.0 为另一个应用程序 App2 配置了第二个信赖方信任。我们使用所有默认 ADFS 设置，包括端点。在这个应用程序的 SAML 配置页面上，我告诉它我们的 SAML 端点是“ https://adfs.mydomain.com/adfs/ls/ ”。一切正常，除了提示用户输入凭据；ADFS 未对这些登录使用 IWA。
我正在使用 IE9 从本地加入域的工作站进行测试。内部 DNS 指向我们本地加入域的 ADFS 服务器，外部 DNS 指向我们的 DMZ ADFS 代理。“*.mydomain.com”位于 IE 的受信任站点区域中，由 GPO 应用。在 IE 中启用了 IWA。IE 每次关闭它时都会清除它的缓存/cookies/历史记录。两个应用程序都使用 SP 发起的登录，并且都将它们的断言发送到我们端的同一个端点 URL。
如果我尝试在干净的会话上登录 App2，我会看到一个 ADFS 登录页面。如果我输入凭据，我将登录到应用程序并可以继续。
如果我尝试在干净会话上登录 App1，我会立即重定向到 ADFS，通过 IWA，我已登录到应用程序并可以继续。
如果我在登录 App1 后尝试在同一个会话中登录 App2，我被重定向到 ADFS，使用由 App1 发起的现有 ADFS 登录会话，然后我立即被重定向到 App2 的断言消费者服务 URL并给出一个错误页面。
我最好的猜测是我在 RPT 配置中遗漏了一些东西。SP 给我的只是他们使用 POST 绑定的消费者服务端点 URL。我不得不猜测索赔规则。SP 不使用加密。
App2 客户服务一直......很困难。他们的技术支持在海外，所以我每天只能在当地时间午夜左右收到一次回复。他们的大部分回复都是标准的“从知识库复制和粘贴”。他们更喜欢 IdP 启动的登录，但表示他们支持 SP 启动 - 这似乎是真的，因为 SSO 在 ADFS 登录页面上登录后确实可以在干净的会话上工作。
有人知道我错过了什么吗？
可以配置和请求身份验证方法。在 SAML 和 WS-Fed 中使用相同的标识符。
WS-Fed 中的请求转到 whr=，而在 SAML 中，它转到 Authentication Context Class。在 SAML 中，可以指定“比较”（精确、最小等，但您必须就顺序达成一致）。ADFS 确实（此时）不注意比较属性。
通常可以定义策略以使用特定应用程序 (RP/SP) 的特定级别。有时它可以根据源地址等进行不同的配置。