"ASP.Net Identity"与"Windows Identity Foundation"相比如何？

Question

我发现这篇很好的文章展示了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身份验证和表单身份验证,您会选择哪个？

Answer 1

ASP.NET Identity在后台使用WIF.WIF不仅仅是WS-Fed,它现在是处理Principal/Identity的.NET框架的核心.基本上命名空间System.IdentityModel现在是WIF和.NET 4.5的一部分.

ASP.NET Identity的目标是提供具有持久性和其他一些漂亮功能的开箱即用的身份验证机制,从而取代传统上使用的成员资格提供程序,它们非常难看(毕竟,它结束了) 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扩展概念正在被中间件哲学所取代.

看看这个"隐藏"的存储库,其中MVC,WebAPI,SignalR被合并到新的vNext MVC中:

vNext MVC存储库

Answer 2

首先,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是更好的选择.

Answer 3

感谢 nzpcmad 帮助我提出正确的问题。

经过更多研究，如果我正确理解了这一点，那么使用新的 ASP.Net Identity 的最大优势是它构建在 OWIN 模型之上。

Microsoft 正在开发一个基于 OWIN 的 WS-Federation 组件，称为 Microsoft.Owin.Security.WsFederation。它仍处于测试阶段，但我认为它实际上是基于 WIF 构建的，因为从 .Net 4.5 开始，WIF 类已全部移至核心框架中。更多信息可以在这里找到：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组件之间切换。