为什么 ADFS 没有通过集成 Windows 身份验证传递凭据?

为什么 ADFS 没有通过集成 Windows 身份验证传递凭据?

我们设置了一个 ADFS 2.0 实例。我们将其用于第三方 Web 应用单点登录。现有应用 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”通过 GPO 位于 IE 中的受信任站点区域并已应用。IE 中启用了 IWA。每次我关闭 IE 时,IE 都会清除其缓存/cookie/历史记录。这两个应用程序都使用 SP 发起的登录,并且都将其断言发送到我们这边的同一端点 URL。

如果我尝试在干净的会话中登录 App2,系统会显示 ADFS 登录页面。如果我输入凭据,系统会登录到应用程序并继续操作。

如果我尝试在干净的会话中登录到 App1,我会立即被重定向到 ADFS,IWA 会通过,然后我会登录到应用程序并继续操作。

如果我在登录 App1 后尝试在同一会话中登录 App2,我将被重定向到 ADFS,使用由 App1 发起的现有 ADFS 登录会话,然后我立即被重定向到 App2 的断言消费者服务 URL 并给出一个错误页面。

我最好的猜测是,我在 RPT 配置中遗漏了某些内容。SP 给我的只是使用 POST 绑定的消费者服务端点 URL。我不得不猜测声明规则。SP 不使用加密。

App2 客户服务一直很……困难。他们的技术支持在海外,所以我每天只能在当地时间午夜左右收到一次回复。他们的大多数回复都是标准的“从 KB 复制粘贴”。他们更喜欢 IdP 发起的登录,但表示他们支持 SP 发起的登录 - 这似乎是真的,因为在 ADFS 登录页面登录后,SSO 确实可以在干净的会话中工作。

有人知道我错过了什么吗?

答案1

可以配置和请求身份验证方法。SAML 和 WS-Fed 中使用相同的标识符。

在 WS-Fed 中请求转到 whr=,在 SAML 中请求转到身份验证上下文类。在 SAML 中可以指定“比较”(精确、最小等,但您必须同意顺序)。ADFS(目前)不关注比较属性。

通常可以定义策略以针对特定应用程序(RP/SP)使用特定级别。有时可以根据源地址等进行不同的配置。

相关内容