我们有一个ADFS 2.0实例设置。 我们将其用于第三方networking应用程序单点login。 一切都与现有的应用程序，包括SAML 2.0的应用程序，包括IWA传递，当用户被redirect到我们的ADFS服务器时，美妙地运作。
我刚刚使用SAML 2.0为另一个应用程序App2configuration了第二个依赖方信任。 我们正在使用所有默认的ADFS设置，包括端点。 在这个应用程序的SAMLconfiguration页面上，我已经告诉它我们的SAML端点是“ https://adfs.mydomain.com/adfs/ls/ ”。 一切工作正常，除了用户提示input凭据; ADFS不使用IWA进行这些login。
我正在使用IE9从本地域join的工作站进行testing。 内部DNS指向我们的本地域join的ADFS服务器，外部DNS指向我们的DMZ ADFS代理。 “* .mydomain.com”位于GPO的IE的“受信任的站点”区域中，并被应用。 IWA在IE中启用。 每当我closures它时，IE会清除它的caching/ cookies /历史logging。 这两个应用程序都使用SP启动的login，并将其断言发送到我们末端的相同端点URL。
如果我尝试在干净的会话上login到App2，则会显示一个ADFSlogin页面。 如果我input凭据，我login到应用程序，可以继续。
如果我尝试在干净的会话上login到App1，我立即redirect到ADFS，IWA通过，并且login到应用程序并继续。
如果我在login到App1后尝试在同一个会话中login到App2，则我被redirect到ADFS，使用由App1发起的现有ADFSlogin会话，然后立即redirect到App2的断言使用者服务URL并给出一个错误页面。
我最好的猜测是我在RPTconfiguration中缺less一些东西。 SP给我的所有信息都是使用POST绑定的消费者服务端点URL。 我不得不猜测索赔规则。 SP不使用encryption。
App2客户服务一直很困难。 他们的技术支持是海外的，所以我只能在当地时间的午夜时分接受一次回应。 他们的大部分回复都是标准的“从KB复制和粘贴”。 他们更喜欢IdP发起的login，但是说他们支持SP启动 – 这似乎是真实的，因为SSO在login到ADFSlogin页面之后在干净的会话上工作。
有人知道我错过了什么吗？
authentication方法可以configuration和请求。 SAML和WS-Fed使用相同的标识符。
在WS-Fed中请求转到whr =，在SAML中转到authentication上下文类。 在SAML中，可以指定“比较”（确切的，最小的等等，但是您必须同意订单）。 ADFS确实（在这个时候）不注意比较属性。
政策通常可以定义为特定的应用程序（RP / SP）使用特定的级别。 有时可以根据源地址等进行不同的configuration