How does the “ASP.Net Identity” compare with “Wind

问题:

I found this nice article that shows the evolution of the ASP.Net identity frameworks: http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity

However, I'm interested in how the Windows Identity Framework (WIF) fits into the picture with the new ASP.Net Identity Framework. Are they yet another set of competing Microsoft implementations?

Furthermore, if a developer is interested in supporting SAML authentication (which WIF supports), Active Directory authentication, and Forms Authentication, which would you choose?

回答1:

Firstly, WIF supports WS-Fed not SAML (although it does use SAML tokens). AFAIK, Identity doesn't support SAML.

Identity is predominantly DB based. WIF normally is used in conjunction with ADFS which is AD based. ADFS supports SAML.

WIF outsources authentication / authorization to a STS (like ADFS) so the FBA decision is a STS one not a WIF one.

WIF supports federation so you can hook into other STS, Azure Active Directory etc.

As you say, they are two sets of "competing" Microsoft implementations.

If you are looking at the bigger picture, AD support and future proofing, it sounds like WIF is the better option.

回答2:

ASP.NET Identity is using WIF in the background. WIF is not only WS-Fed, it is now core of .NET framework when it comes to dealing with Principal/Identity. Basically namespace System.IdentityModel is now part of both WIF and .NET 4.5.

Goal of ASP.NET Identity is to provide out-of-the-box authentication mechanism with persistence and some other nifty features and thus replace traditionally used Membership providers which pretty much did the same, on very ugly way (after all, it is over 10 years old).

I personally am never using ASP.NET Identity on the project, but rather do my own user logic when it comes to persistence, mailing etc, and I operate directly with most important WIF classes such as SessionAuthenticationModule, ClaimsAuthenticationManager, ClaimsAuthorizationManager, etc. This gives me ability to write my own custom claims-based abstraction. WIF is all about CBAC (Claims Based Access Control).

Now when it comes to OWIN or not-OWIN, I'd say - go for OWIN (or to be more precise - go for Katana). ASP.NET will be entirely rewritten with new vNext technology, and Katana will play major role there. The sooner you get used to work with Katana middleware, the easier will be transition for you.

Keep in mind that all modules (FormsAuthenticationModule, RoleManagerModule, SessionAuthenticationModule, WSFederationModule,...) are not compatible with OWIN/Katana as concept of ASP.NET extension via IHttpModule is being replaced with Middleware philosophy.

Check out this "hidden" repository where MVC, WebAPI, SignalR are merged into new vNext MVC:

vNext MVC Repository

回答3:

Thanks nzpcmad for helping me ask the right questions.

After more research, if I understand this all correctly, the biggest advantage of using the new ASP.Net Identity is that it is built on top of the OWIN model.

Microsoft is working on an OWIN-based WS-Federation component called Microsoft.Owin.Security.WsFederation. It is still in beta, but I think it is actually built on WIF, since the WIF classes were all moved into the core framework as of .Net 4.5. More information can be found here: http://www.cloudidentity.com/blog/2014/02/20/ws-federation-in-microsoft-owin-componentsa-quick-start/ and here 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.

So I don't think the question is: ASP.Net Identity versus WIF. I think the question is: OWIN versus non-OWIN.

So I think to answer my question: the more future-proof and flexible choice is to use OWIN security components, and through simple configuration or other means, allow switching between the OWIN ASP.Net Identity component and the OWIN WS-Federation component.