我们将加强Intranet网络应用程序的身份验证和授权系统。几天后阅读有关ADFS，STS，基于声明的身份验证，asp.net身份。仍然不确定这些东西是如何协同工作的。
我们的大多数Intranet Web应用程序都使用Windows集成身份验证，我们使用Windows组或AzMan进行角色基本授权。我们很少有应用程序（供应商应用程序）使用它自己的用户数据库并形成基本身份验证
我们希望在Web应用程序中添加以下功能。
对于Windows身份验证应用程序，我们希望让用户以不同的用户身份注销/登录。因此，当用户A使用他/她的计算机访问应用程序时，它将自动登录（默认的Windows集成身份验证）。当他/她注销时，它将重定向到表单以允许输入其他用户凭证。
我们希望允许用户使用系统B用户名/密码登录系统A. 例如对于Windows身份验证应用程序，我们希望允许用户使用via visa的表单基础应用程序（供应商应用程序）的凭证登录到应用程序
我不知道ADFS是否可以解决这两个问题。
据我了解，ADFS的主要目的是允许从Internet访问内部应用程序，它需要SSL。
我们的应用程序都在Intranet中，我们不想管理ssl证书。
但是通过使用ADFS，也许我可以在我的应用程序上同时启用Windows和表单身份验证，然后让我们使用注销并将其重定向到登录表单，就像他访问公司网络外部一样。它应该解决问题1.
对于问题2，如果我可以使用表单基本身份验证应用程序的用户数据库创建自定义STS以发出安全令牌，该怎么办？然后我可以使用基于声明的身份验证，并允许一个应用程序可以使用ADFS和我的STS。它应该解决我的问题2。
我的指示是否正确？或者我是否使问题复杂化？
答案 0 :(得分：0)
如果没有SSL，ADFS将无法运行。
此外，所有RP都必须使用SSL。
在内部，用户将使用WIA无缝登录。当他们退出时，他们将再次无缝登录。
此外，ADFS v3.0及更低版本只能对AD进行身份验证。
答案 1 :(得分：0)
虽然你想要的是使用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中的声明创建的新WindowsPrincipal覆盖Thread.CurrentPrincipal中的ClaimsPrincipal。
现在，当用户第一次导航到Web应用程序时，他/她将使用IWA自动登录，并且将创建cookie。现在，提供一个注销操作，删除身份验证cookie并向用户显示用户名和密码对话框。
在该操作的POST处理程序中，使用WIF到ADFS中的talk to the username endpoint（使用WS-Trust协议）并尝试使用提供的凭据对用户进行身份验证。如果成功，请使用返回令牌中的声明来创建新的身份验证cookie。