authentication and authorizing in ASP.NET MVC 5

Question

Asp.net MVC 5 seems to have left behind using the AuthorizeAttribute class where you could create a custom authorize attribute by implementing the AuthorizeAttribute class, override its methods and hiding the SiteRole property incase you wanted to bake in your own roles. All the examples I have seen either suggest using OWIN or the identity framework. Are these the only two ways to do authentication and authorization in the new ASP.Net framework?. Will I miss out on anything if I do it the old fashioned way? I dont want to have the framework create all the user and role tables for me. What if I want to add an existing user and role table to a new application?

I also really don't see a need for social integration in every application as yet and don't think I will need it immediately as well. Is there any article that explains starting off with a bare minimum by using a custom authorize attribute and then goes on to add the new authentication features. I want something that basically explains all the clutter in a newly created project with No Authentication or Individual User Authentication selected.

Answer 1

You can still customize the AuthorizeAttribute in MVC 5 using ASP.NET Identity. There is an example of doing this in the SimpleSecurity Project. Here is a customized AuthorizedAttribute you can use for controllers and here is customized AuthorizeAttribute you can use for Web API's. The concept behind these custom AuthorizeAttributes is to decouple your security model from your application model which is discussed here. The one for the Web API's also supports basic authentication.

The security pipeline has changed with the introduction of OWIN and I did run into some issues with the behavior of AuthorizeAttribute for Web API's, which is discussed here.

You will also find examples in the SimpleSecurity project on porting of the old membership provider called SimpleMembership to MVC 5. Some of the issues with the upgrade process are discussed here. I did get it to work though so you could go with the old membership provider implementation. But my recommendation would be to go with the ASP.NET Identity as this is the way going forward that Microsoft will be supporting, it is a more flexible architecture, and it eliminates many of the issues found in the old membership provider implementations.