AD FS 故障排除 - Fiddler - WS 联合身份验证
步骤 1 和 2
这是我们踪迹的开始。 在此框架中，我们可以看到以下内容：
请求：
- HTTP GET 到我们的信赖方 (https://sql1.contoso.com/SampApp)
响应：
- 响应是 HTTP 302（重定向）。 Response 标头中的 Transport 数据显示要重定向到的位置 (https://sts.contoso.com/adfs/ls)
- 重定向 URL 包含 wa=wsignin 1.0，这告诉我们 RP 应用程序已经为我们构建了一个 WS 联合身份验证登录请求，并将其发送到 AD FS 的 /adfs/ls/ 终结点。 这称为重定向绑定。
步骤 3 和 4
请求：
- HTTP GET 到我们的 AD FS 服务器 (sts.contoso.com)
响应：
- 响应是提示输入凭据。 这表明我们正在使用表单身份验证
- 单击 Response 中的 WebView，你便可以看到凭据提示。
步骤 5 和 6
请求：
- 使用我们的用户名和密码的 HTTP POST。
- 我们提供凭据。 通过查看请求中的原始数据，我们便可以看到凭据
响应：
- 找到响应，然后将创建并返回由 MSIAuth 加密的 cookie. 这用于验证客户端生成的 SAML 断言。 这也称为“身份验证 Cookie”，仅当 AD FS 是 IDP 时才会出现。
步骤 7 和 8
请求：
- 现在我们已经验证了身份，我们对 AD FS 服务器执行另一个 HTTP GET，并展示了我们的身份验证令牌
响应：
- 响应是 HTTP OK，这意味着 AD FS 已根据提供的凭据对用户进行了身份验证
- 此外，我们还为客户端设置了 3 个 Cookie
- MSISAuthenticated 包含对客户端进行身份验证时的 Base64 编码时间戳值。
- AD FS 无限循环检测机制使用 MSISLoopDetectionCookie 来停止最终在联合身份验证服务器无限重定向循环中的客户端。 Cookie 数据是 Base64 编码的时间戳。
- MSISSignout 用于跟踪 IDP 和 SSO 会话访问的所有 RP. 调用 WS 联合身份验证注销时，将使用此 cookie。 你可以使用 Base64 解码器查看此 cookie 的内容。
步骤 9 和 10
请求：
- HTTP POST
响应：
- 响应为 Found
步骤 11 和 12
请求：
- HTTP GET
响应：
- 响应为 OK