Window Identity Foundation cookies 工作流程

Question

谁能解释一下 WIF 中两个应用程序（STS 和依赖方）之间的索赔转移流程是怎样的？我知道通过 cookie 进行声明转移，但无法理解 cookie 信息如何在两个域之间传输。

我有现有的 STS (WIF) 实施应用程序，我已经创建了新的依赖方（新网站）并与预期工作的现有 STS 集成。

当我尝试打开依赖方应用程序时，我在浏览器控制台上注意到了以下步骤

1. https://onlineaccount.abc.com（状态 302）
2. https://security.abc.com/?wa=wsignin1.0&wtrealm=https%3a%2f%.....(status302)
3. https://security.abc.com/Login.aspx?ReturnUrl=%2f%3fw...(status200)

提交登录表单后

4. https://security.abc.com/Login.aspx?ReturnUrl=%2f%3...（状态 302 和已创建的表单身份验证 cookie）
5. https://security.abc.com/?wa=wsignin1...（状态 302 并与依赖方 url 一起创建了普通 cookie）
6. https://onlineaccount.abc.com/（状态 302 并已创建 (i) 在表单数据中发送 SAML 令牌并创建 FedAuth cookie 作为响应）
7. https://onlineaccount.abc.com/（状态 200）

根据上述步骤，我了解到依赖方应用程序设置了 FedAuth cookie，但依赖方应用程序如何接收 token/claim 信息（SAML 令牌信息）？？

Answer 1

深入研究浏览器（特别是 IE）后，我得到了答案，STS 应用程序如何向依赖方共享数据...

用简单的 Word 回答 - STS 应用程序使用安全令牌向依赖方应用程序提交隐藏表单。

1. http://security.STS.Web/Login.aspx?ReturnUrl=%2f%3...
   在此请求中，STS 服务器简单地创建表单身份验证 cookie
2. http://security.STS.Web/?wa=wsignin1...
   在这个请求中
   1. STS 服务器简单创建带有依赖方名称的简单 cookie。
   2.STS服务器会提交一份隐藏表单，其中包含依赖方的token信息（见下方附件）

3. http:/// (http://localhost:52255/) 在此请求中，依赖方将接收令牌信息（由 STS 应用程序提交）并创建 FedAuth cookie 并重定向到依赖方默认页面
4. http://localhost:52255/Default.aspx