从Windows注销经过身份验证的ADFS，并以身份验证的不同用户身份登录

Question

我们将加强Intranet Web应用程序的身份验证和授权系统。在阅读了ADFS，STS，基于声明的身份验证，asp.net身份之后的几天。仍然不确定这些东西是如何协同工作的。

我们大部分的内联网web应用程序使用Windows集成身份验证，我们使用Windows组AzMan的或做作用的基础授权。我们有很少的应用程序（供应商应用程序）使用它自己的用户数据库和表单基础认证。

我们希望为我们的Web应用程序添加以下功能。

1. 对于Windows身份验证的应用程序，我们要让用户登出以不同的使用者/注册。因此，当用户A使用他/她的计算机访问应用程序时，它将自动登录（默认的Windows集成身份验证）。当他/她注销时，它将重定向到表单以允许输入其他用户凭证。

2. 我们希望允许用户登录到系统使用系统B的用户名/密码。 例如对于Windows身份验证的应用程序，我们希望允许用户登录使用的形式基本应用程序（供应商应用程序）的证书申请通过签证

我不知道是否能ADFS解决这两个问题。

从我的理解，ADFS的主要目的是允许访问互联网从内部应用程序，它需要SSL。

我们的应用程序都是在Intranet，我们不想要管理的SSL证书。

但是，通过使用ADFS，或许我可以在我的应用程序能够在Windows和窗体身份验证，所以然后让使用注销并重新引导他登录形式，它就像他访问外部公司网络。它应该解决的问题1.

对于问题2，如果我能创造什么自定义STS使用形式基本验证appliaction的用户数据库发布的安全令牌。然后我可以使用基于声明的身份验证，并允许一个应用程序可以使用ADFS和我的STS。它应该解决我的问题2.

我的方向是否正确？还是我复杂的问题？

Answer 1

如果没有SSL，ADFS将无法正常工作。

此外，所有的RP都必须使用SSL。

在内部，用户将使用WIA无缝登录。当他们注销时，他们将会再次无缝登录。

此外，ADFS v3.0及更低版本只能对AD进行身份验证。

Answer 2

虽然您希望使用ADFS，但问题在于它是否是一个好主意并且值得付出麻烦。让用户退出机器并使用其他帐户登录可能更合适，因此您可以使用集成Windows身份验证（IWA）。编写自己的安全基础架构充满了危险。

如果你真的觉得这些都是很难的要求，这是值得的麻烦，以下可能工作。

编写一个基于Katana和enable Integrated Windows Authentication的ASP.NET Web应用程序。这将确保首次完全未经身份验证的请求进入时，应用程序将挑战浏览器。随后的请求将在HttpContext.User和Thread.CurrentPrincipal中填充一个WindowsPrincipal。

现在，写一块OWIN middleware，检查是否存在验证Cookie。如果cookie不存在，它会检查Thread.CurrentPrincipal并将声明序列化为安全cookie。

如果安全Cookie存在，它会用根据Cookie中的声明创建的新的ClaimsPrincipal覆盖WindowsPrincipal的Thread.CurrentPrincipal。

现在，当用户第一次导航到Web应用程序时，他/她将使用IWA自动登录并创建Cookie。现在，提供一个注销操作，删除身份验证cookie并向用户显示用户名和密码对话框。

在该操作的POST处理程序中，使用WIF到ADFS中的talk to the username endpoint（使用WS-Trust协议）并尝试使用所提供的凭证对用户进行身份验证。如果成功，请使用返回的令牌中的声明来创建新的身份验证Cookie。