我发现这篇很好的文章展示了ASP.Net身份框架的演变： http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity
但是，我对Windows身份框架（WIF）如何适应新的ASP.Net Identity Framework感兴趣。它们是另一组竞争的Microsoft实现吗？
此外，如果开发人员有兴趣支持SAML身份验证（WIF支持），Active Directory身份验证和表单身份验证，您会选择哪个？
答案 0 :(得分：11)
ASP.NET Identity在后台使用WIF。 WIF不仅仅是WS-Fed，它现在是处理Principal / Identity的.NET框架的核心。基本上命名空间System.IdentityModel现在是WIF和.NET 4.5的一部分。
ASP.NET身份的目标是提供具有持久性和其他一些漂亮功能的开箱即用的身份验证机制，从而取代传统上使用的成员资格提供程序，这些服务提供程序几乎一样，非常难看（毕竟，它已超过10年了。）
我个人从不在项目中使用ASP.NET Identity，而是在持久性，邮件等方面使用我自己的用户逻辑，并且我直接使用最重要的WIF类操作，例如SessionAuthenticationModule，ClaimsAuthenticationManager，ClaimsAuthorizationManager等。这使我能够编写自己的基于声明的自定义抽象。 WIF就是CBAC（基于声明的访问控制）。
现在谈到OWIN或者不是OWIN，我要说 - 去OWIN（或者更确切地说 - 去Katana）。 ASP.NET将完全用新的vNext技术重写，Katana将在那里发挥重要作用。您越早习惯使用Katana中间件，就越容易为您过渡。
请记住，所有模块（FormsAuthenticationModule，RoleManagerModule，SessionAuthenticationModule，WSFederationModule，...）都与OWIN / Katana不兼容，因为通过IHttpModule的ASP.NET扩展概念正在被中间件哲学所取代。
看看这个＆＃34;隐藏＆＃34;将MVC，WebAPI，SignalR合并到新的vNext MVC中的存储库：
答案 1 :(得分：9)
首先，WIF支持WS-Fed而不是SAML（尽管它确实使用SAML令牌）。 AFAIK，Identity不支持SAML。
身份主要基于数据库。 WIF通常与基于AD的ADFS结合使用。 ADFS支持SAML。
WIF将认证/授权外包给STS（如ADFS），因此FBA决定是STS而非WIF决定。
WIF支持联盟，因此您可以挂钩到其他STS，Azure Active Directory等。
正如你所说，他们是两套竞争对手。 Microsoft实现。
如果您正在查看更大的图片，AD支持和未来验证，听起来WIF是更好的选择。
答案 2 :(得分：0)
感谢nzpcmad帮我提出正确的问题。
经过更多的研究，如果我理解这一点，使用新的ASP.Net标识的最大好处是它建立在OWIN模型之上。
Microsoft正在开发一个名为Microsoft.Owin.Security.WsFederation的基于OWIN的WS-Federation组件。它仍然处于测试阶段，但我认为它实际上建立在WIF上，因为WIF类都是从.Net 4.5迁移到核心框架。可在此处找到更多信息：http://www.cloudidentity.com/blog/2014/02/20/ws-federation-in-microsoft-owin-componentsa-quick-start/和此处http://blogs.msdn.com/b/webdev/archive/2014/02/21/using-claims-in-your-web-app-is-easier-with-the-new-owin-security-components.aspx。
所以我不认为问题是：ASP.Net Identity与WIF。我认为问题是：OWIN与非OWIN。
所以我想回答我的问题：更具前瞻性和灵活性的选择是使用OWIN安全组件，通过简单的配置或其他方式，允许在OWIN ASP.Net Identity组件和OWIN WS-Federation之间切换成分