Window Identity Foundation cookie 工作流程

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 但依赖方应用程序如何接收令牌/声明信息（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信息给依赖方（见附件）

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