我找到了一篇很好的文章,它展示了ASP.Net身份框架的演变:http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity
然而,我感兴趣的是Windows Identity Framework (WIF)如何适应新的ASP.Net身份框架。它们是另一组相互竞争的微软实现吗?
此外,如果开发人员对支持SAML身份验证( WIF支持的身份验证)、Active Directory身份验证和表单身份验证感兴趣,您会选择哪种身份验证?
发布于 2014-05-28 23:38:40
感谢nzpcmad帮助我提出正确的问题。
经过更多的研究,如果我理解正确的话,使用新的ASP.Net标识的最大好处是它构建在OWIN模型之上。
微软正在开发一个名为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身份is。我认为问题是: OWIN和non-OWIN。
因此,我想回答我的问题:更面向未来和更灵活的选择是使用OWIN安全组件,并通过简单的配置或其他方法,允许在OWIN联合身份组件和OWIN WS- ASP.Net组件之间进行切换。
发布于 2014-06-02 02:39:11
ASP.NET Identity在后台使用WIF。WIF不仅是WS-Fed,在处理主体/身份时,它现在是.NET框架的核心。基本上,命名空间System.IdentityModel现在是WIF和.NET 4.5的一部分。
ASP.NET Identity的目标是提供具有持久性和其他一些漂亮功能的开箱即用的身份验证机制,从而取代传统使用的成员提供者,这些提供者以非常丑陋的方式几乎做了同样的事情(毕竟,它已经有10多年的历史了)。
我个人从不在项目中使用WIF,而是在持久化、邮件等方面使用自己的用户逻辑,并且我直接使用SessionAuthenticationModule、ClaimsAuthenticationManager、ClaimsAuthorizationManager等最重要的ASP.NET类进行操作。WIF是关于CBAC (基于声明的访问控制)的。
现在,当谈到OWIN或not-OWIN时,我会说- go for OWIN (或者更准确地说- go for Katana)。ASP.NET将使用新的vNext技术完全重写,片断将在其中扮演主要角色。你越早习惯使用Katana中间件,对你来说过渡就越容易。
请记住,所有模块(FormsAuthenticationModule、RoleManagerModule、SessionAuthenticationModule、WSFederationModule等)与OWIN/Katana不兼容,因为通过IHttpModule扩展ASP.NET的概念正在被中间件哲学所取代。
查看这个“隐藏”的存储库,其中MVC、WebAPI、SignalR被合并到新的vNext MVC中:
发布于 2014-05-27 03:22:44
首先,WIF支持WS-Fed而不是SAML (尽管它确实使用SAML令牌)。AFAIK,标识不支持SAML。
身份主要是基于数据库的。WIF通常与基于AD的ADFS一起使用。ADFS支持SAML。
WIF将身份验证/授权外包给STS (如ADFS),因此FBA决策是STS决策,而不是WIF决策。
WIF支持联合,因此您可以连接到其他STS、Azure Active Directory等。
正如您所说,它们是两组“相互竞争”的Microsoft实现。
如果你正在考虑更大的前景,AD支持和未来的校对,听起来WIF是更好的选择。
https://stackoverflow.com/questions/23831961
复制相似问题