验证后如何将客户端重定向到网站？

Question

我必须在由两家不同公司托管的两个现有互联网应用程序之间实施一个简单的单点登录 (SSO) 解决方案。

应该怎么做：

1. 用户使用他的用户名和密码登录到应用程序 A。
2. 用户最终单击应用程序 A 中的按钮以启动应用程序 B。
3. 此按钮实际上是指向安装在应用程序 A 和应用程序 B 之间的“外观”（ASP.NET 页面）的链接。
4. facade 检索令牌（由调用者包含在 URL 中）并使用此令牌调用应用程序 A 的 Web 服务以获取用户的电子邮件。此电子邮件包含在回复中。
5. Facade 然后从本地检索用户的用户名/密码 数据库并将它们发布到应用程序 B 的登录页面。
6. Facade 然后将调用者重定向到应用程序 B。

问题是，我不知道如何实现最后一步。对帖子的响应（第 5 步）是欢迎页面和 cookie。我尝试将此响应（HttpWebResponse）复制到门面的Response，但是虽然用户可以看到欢迎页面内容，但没有重定向...

HttpWebResponse applicationBResponse = PostApplicationB();
var reader = new treamReader(applicationBResponse.GetResponseStream());
string temp = reader.ReadToEnd();
reader.Close(); 
Response.Write(temp);

知道我应该如何实现这个重定向吗？

Answer 1

这个方案唯一可行的方法是你去掉门面。相反，应用程序 A 应该检索用户的名称和密码，并将其呈现到包含在表单中的隐藏字段中的页面。该页面应以 javascript 的 sn-p 结束，以将表单提交给应用程序 B。应用程序 B 将使用欢迎页面以及任何会话 cookie 直接回复浏览器。

如果您使用外观，cookie 将不会传播，最终用户浏览器将无法访问该站点。即使您修改外观以传递 cookie，它们也会位于错误的域中。

另外，我必须评论一下，从安全角度来看，这是非常糟糕的设计。

Answer 2

这是使用 Windows Identity Foundation 实现所谓的被动联合的完美用例。身份联合是拥有一个集中服务或应用程序来负责管理用户身份验证用户凭据的概念。然后，依赖应用程序可以与身份服务建立信任关系，这样它们就不再关心用户的身份验证方式。这种方法的一个好处是，如果您出于某种原因决定更改身份验证机制，例如从密码转移到客户端证书，那么您的任何应用程序都根本不需要更改。只要他们信任的身份服务表明用户良好，他们就可以像往常一样继续运输。

通过使用 WIF，您尝试编写的几乎所有管道代码都会为您处理，并且可能会立即解决您的大多数场景。它支持多种不同的协议，具有高度的灵活性和可配置性，并且如果您有默认场景未涵盖的自定义需求，它可以轻松扩展。

如果您正在寻找一个好的开源身份服务，请查看Thinktecture's Identity Server v3。您可以在几分钟内启动并运行，并且可以轻松定制以适合您的组织和您的需求。我们在我们的组织中使用 Identity Server 来处理 Web 和 WPF 应用程序的 SSO，并取得了巨大成功。

有关身份联合的良好入门，请查看 MSDN 上的 A Guide to Claims Based Identity and Access Control。