ClaimsAuthenticationManager vs. IAuthenticationFilter vs. OWIN Forms Authentication

Question

.NET 4.5, MVC 5: ClaimsAuthenticationManager, IAuthenticationFilter, OWIN Forms Authentication, and ClaimsPrincipals are all new since I last touched my site's authentication functions. I've found a lack of clarity in all the docs that say this or that is the right way. I can't even tell which features are mutually exclusive.

This document says the old ASP.NET FormsAuthenticationModule doesn't support Claims, but the new OWIN doesn't support cookieless. Yet, I get the feeling that OWIN is intended to be the go-forward feature?

1. Does the product roadmap say which method is the go-forward for web-apps?
2. Is ClaimsAuthenticationManager synonymous with OWIN Forms Authentication for web apps?
3. Are the ClaimsAuthenticationManager and a global IAuthenticationFilter mutually exclusive?

A push in the right direction would be appreciated, my brain is fried on this.

Answer 1

IAuthenticationFilter

Previously in MVC, IAuthorizationFilter was a common place to perform custom authentication. The reasoning for this filter can be seen in the scenario where an application has two authorization specifications, and only one authentication specification. Two options - adding the authentication specification to a single arbitrary authorization routine, and creating all three of these specifications as distinct IAuthorizationFilter - both mean we don't ensure that authentication occurs first.

IAuthenticationFilter was originally added to the MVC assembly to address this, then relocated for use by WebAPI as well. A good related article can be found here; ASP.NET Web API Security Filters.

Strictly speaking, IAuthenticationFilter and OWIN Authentication are not mutually exclusive, but OWIN Authentication will happen first and can get in the way of any intent to use both.

OWIN Forms Authentication

OWIN forms authentication is a confusing phrase that I got from reading an ill-phrased article (linked above). It represents two non-dependent solution components:

The "Forms" aspect of the solution still operates the same as it did for Forms Authentication previously. It's a consequence of authorization failure (such as that occurring from an [Authorize] attribute or a web.config <authorization> element) paired with a redirect to a logon-handler form. (Your choice of technology will determine where you configure that redirect URL. For OWIN, you'll configure it in CookieAuthenticationOptions.)

The "OWIN" aspect is more relevant to the confusion that prompted my OP. I won't go into much detail on OWIN broadly, as it's meant to do a lot more than authentication; entirely decoupling ASP.NET from IIS (via OWIN), it results in lots of pros and cons, but MVC6 is built exclusively on OWIN so it's here to stay.

Specific to Authentication, current modules like the ASP.NET external authentication providers (Facebook/Google social login) depend on OWIN. If you write ASP.NET web authentication the "normal" way you'll be using OWIN. This is a benefit to authentication via OWIN.

Previously, social login occurred in a more cobbled-together fashion as redirection and a MessageHandler called OAuthWebSecurity. OWIN provides a mechanism both to redirect and process the authentication provider callback; read Creating Custom OAuth Middleware for MVC 5 for more information.

ClaimsAuthenticationManager

ClaimsAuthenticationManager isn't really what it sounds like. It really a tail-end aspect of an authentication process that has already been performed by the Windows Identity Foundation (WIF). It is meant to transform the Claim produced by that process to meet your custom needs. For example, the Claims list may include a username, from which you might look up from a database frequently-accessed roles or rights, and add these to the Claims list for performance reasons.

It is applicable anywhere WIF is used. Relative to current ASP.NET web applications, that will mean OWIN.

Summary

Yeah. You'll probably be using OWIN, WIF, and cookies in your modern ASP.NET web app. Just something to accept if you use the 'boxed materials', along with the death of WebForms and VB.NET in this release.

So, since you'll probably be doing OWIN authentication, here's an excellent series on the topic; What’s this Owin Stuff About?

Answer 2

OWIN is more of a grander scope of minimizing the stack for serving web pages and minimizing the stack is the new wave of the future(ala node.js). "OWIN authenication middleware" is what you are referring to and Brock Allen states it best here:

http://brockallen.com/2013/10/24/a-primer-on-owin-cookie-authentication-middleware-for-the-asp-net-developer/

With .NET 4.5.1, for ASP.NET applications, all the underlying code that handles “Individual User Accounts” (as well as the templates in Visual Studio 2013) is new. This means for cookie based authentication we no longer use Forms authentication and for external identity providers we no longer use DotNetOpenAuth.

The replacement is a framework called OWIN authentication middleware and it’s targeting the OWIN API. I don’t plan to motivate OWIN here (this a good article on the subject), but in short it’s an abstraction API for the web host. Many frameworks such as Web API and SignalR (as well as other non-Microsoft frameworks) are coded to this abstraction so they do not require any particular web host (such as IIS).