步骤 1 和步骤 2
这是我们跟踪的开始。 在此帧中，我们将看到以下内容：
请求：
- HTTP GET 到我们的信赖方 (
https://sql1.contoso.com/SampApp)
响应：
- 响应是 HTTP 302 （重定向）。 响应头中的传输数据显示要重定向到的位置 (
https://sts.contoso.com/adfs/ls) - 重定向 URL 包含 wa=wsignin 1.0，它告诉我们 RP 应用程序已为我们生成 WS-Federation 登录请求，并将其发送到 AD FS 的 /adfs/ls/ 终结点。 这称为重定向绑定。
步骤 3 和步骤 4
请求：
- 向我们的 AD FS 服务器（sts.contoso.com）发起 HTTP GET 请求。
响应：
- 响应是提示输入凭据。 这表示我们使用的是表单身份验证
- 单击响应中的 Web 视图，即可看到凭据提示。
步骤 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
响应：
- 响应为“已找到”
步骤 11 和 12
请求：
- HTTP GET
响应：
- 响应正常