Future Versions of SecurityGuard

What's in store for SecurityGuard?

I've been getting lots of requests for versions of SecurityGuard that work with either the SimpleMembership providers, or the new Microsoft Identity framework.  Apart from being rather busy on client projects that have taken me away from investigating these new frameworks, I was relatively naive about their capabilities and processes.

But I recently had time to do some research on both new frameworks and I'll describe my findings here.

SimpleMembershipProviders

When I first research this provider I wasn't sure if this was better than any existing version, or not.  Now I'm convinced, that overall, it's not. 

The Good

• User control - SimpleMembership refactored and streamlined the way User information was stored and allowed you the developer to have more control over the data that was stored for the user.  This was done by using the EntityFramework code-first model and simply requiring a User class with an Id and UserName.  The rest of the properties would be up to you.  This is a nice step forward from the ProfileBase pattern in previous versions.  Personally though, I rarely used the Profile class for custom user properties.  I usually created a new UserAccount class for that information and included it along with the other entities from the repository.
  
  
• Azure friendly - SimpleMembership also asserted itself as being more Windows Azure friendly.  I can't really make an argument there since I haven't used Windows Azure enough to make qualified assertions.  So I'll accept their statement.
  
  
• EF and Linq - like the previous version of the ASP.NET Membership system, System.Web.Providers, it got rid of the plethora of database Views and Stored Procedures and used the Entity Framework and Linq instead.  For me, this was a definite plus!  It was a lot easier to manage and migrate if necessary.
  
  
• External Logins - it created a framework that allowed you to plug in external accounts like Facebook, Google and others for your users to use to login with.  This, I believe, is where authentication is moving to, so there will be a single-sign-on that you can use for all your sites, and devices.

The Bad

• Extend with base class - unless you are going to use the SimpleMember system as is, you would need to create your own class that inherits from the ExtendedMembership base class. While this isn't horrendous, it does mean that you have to implement or override many members, whether you use them or not.  Then you have to remember which methods are not implemented and which are. 
  
  
• Initialize Database - the default behavior for SimpleMembership to work is to add this line to the Global.asax file:
  WebSecurity.InitializeDatabaseFile("SecurityDemo.sdf", "Users", "UserID", "Username", true);
  I say the default behavior, because you can still use SimpleMembership without executing this line of code.  If you replace the DbContext that is used with SimpleMembership with the context that runs the rest of your application, then you can get access to all your application's entities, as well as those for the SimpleMembership provider.  Personally I would do it this way, if I were to use SimpleMembership. 
  
  Otherwise, you would need to use the InitializeDatabaseFile method to initialize the DbContext and then you would have another DbContext (or some other context) that manages the entities for your application.  I don't like this from a usability stand point.
  
  
• It's already outdated.

Microsoft.AspNet.Identity

This seems to be the Authentication scheme Microsoft will be pushing for the near future.  Notice I said Authentication and not Membership.  This framework is more about authentication than membership.  Meaning it doesn't care who you are, it just matters that you are able to authenticate from a reliable source.  Identity has changed the entire high-level thought process for user authentication, since as they mention, logins are getting more social.

More and more applications are plugging in API's to Facebook, Google, Twitter, etc., that allows you to login into a site or app using your social credentials.  This is good!  You no longer are required to register in order to gain access to a site or app.

Identity has logic built-in that allows developers to plug in these various authentication API's.  But like the SimpleMembership Provider, Identity has it's own set of Good and Bad.  I won't go into all of them, instead I will provide a list of related articles by smarter people than I, who have offered up their information about Identity.

What I will say is that while Identity is fine, there are some small issues, like Password Hashing that make me stay away.  But you can read up on those issues.  If you want to use the Identity provider, you can certainly do it, but if you are thinking of making a large public application that will make use of memberships for your customers, I would think twice and read the other articles first.

So what happens with SecurityGuard?

At the moment, nothing. After reading many blogs and articles on both the SimpleMembership providers and Microsoft's Identity, I've decided that SecurityGuard really doesn't fit with either of those.  The reason is that both systems are moving away from the old membership thought process where you store membership information in your own database, to user authentication which is now going to be done through social credentials.

I built SecurityGuard initially for me.  I was building one client web application after another and they all needed membership and a way to manage that membership.  So I decided to build SecurityGuard so I could easily plug this UI into my MVC applications and instantly have a way to manage the membership.

Then I realized I could go one-step further to make it even easier by creating a NuGet package, and when I did that, also initially for me, I realized that it worked so well, that maybe others might find it useful.

With the old Membership provider model, SecurityGuard fit in perfectly, but now with this new paradigm, where applications are concentrating more on authentication than membership, SecurityGuard doesn't really have a place to live in this world.

This doesn't mean that I'll be removing SecurityGuard, it just means that at the moment, I don't see how it will fit into the latest implementations of authentication.

More Reading

Here are some links for more reading on the SimpleMembership provider and the Microsoft.AspNet.Identity framework and stuff on why the current Password Hashing is not good enough.

http://blogs.msdn.com/b/rickandy/archive/2012/08/15/initializesimplemembership-attribute-and-simplemembership-exceptions.aspx
http://weblogs.asp.net/jgalloway/archive/2012/08/29/simplemembership-membership-providers-universal-providers-and-the-new-asp-net-4-5-web-forms-and-asp-net-mvc-4-templates.aspx
http://igambin.blogspot.com/2012/08/simplemembershipprovider-huh.html
http://brockallen.com/2013/10/20/the-good-the-bad-and-the-ugly-of-asp-net-identity/
http://www.troyhunt.com/2012/06/our-password-hashing-has-no-clothes.html
http://www.asp.net/identity/overview/extensibility/overview-of-custom-storage-providers-for-aspnet-identity