Story Details for news

Future Versions of SecurityGuard

Date Posted:
3/13/2014 5:46:25 PM
Date Updated:
3/13/2014 5:46:25 PM
5/1 votes
Programming Language:
membership, system.web.providers, microsoft.aspnet.identity, simplemembership
Demo site:
Home Page:

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.


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.


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.


    Posted By: stimpy77
    On: 3/25/2014 1:40:09 PM
    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 think this is a really flawed conclusion. The majority of application developers will probably not rely solely on social networks to manage users, but will continue to have their own user management along with tie-in support for third party OAuth-based authentication. The reality is that, while semantics have changed, the fundamental feature set has not. Where before a MembershipProvider was a God object that did it all, responsibilities are broken down to UserManager<T> which manages user-related functions at a high level, UserStore<T> which manages the database storage concerns of new user creation, password authentication, roles lookup, etc. I believe there are even helper wrappers in ASP.NET Identity that wrap MembershipProvider and IIdentity classes to work with the new Identity system.

    Because of the drastic overhaul of separating components and semantics out to facilitate a much larger--or granular, take your pick--set of features, accomodating a user management system for Identity to fit in the prior role of MembershipProvider is totally achievable, but only given constraints of assumed behavior, and the implementation would be completely incompatible programmatically at the API level. The use cases and front-end feature set, however, are perfectly compatible at the functional level.

    Ultimately, the .NET ecosystem will need to come up with a user management system built upon Identity based upon legacy assumptions, and SecurityGuard will need to migrate to the new system, otherwise a similar system, identical in function to the old SecurityGuard, will need to come in and take its place in the ecosystem.

    Posted By: King Wilder
    On: 3/25/2014 3:13:27 PM
    @stimpy77 - I had a feeling I would get some grief with that comment, but it really isn't a conclusion.  It's just a comment saying that there's a push to make authentication easier and not require registering, by using social media API's.  

    I'm trying to point out that since it's a different model from previous membership providers, the future of where SecurityGuard fits in, is murky.  I'm not saying it would be impossible to integrate Identity into SecurityGuard, I'm saying that I need to figure out if it's done, how to do it in a way that can easily be ready to change in the future.

    It would take quite a bit of work and I want to make sure that I'm not wasting my time on something that may be obsolete if a new membership/authentication model comes out by the time the new version of SecurityGuard is released.  I know I'm going to get crap for that comment too.

    I really like SecurityGuard and I would like to be able to make it work with many different versions of membership providers, but the reality is, I work and it takes time.  SecurityGuard is a side-line project that I enjoy and I'm proud of, but it will take lots of research into Identity in order to make an education assessment of what is needed to integrate it into SecurityGuard.

    As I'm thinking at this moment, if I were to try and integrate Identity into SecurityGuard, I would add it to it, not replace the current functionality.  This way the old and new membership systems could be used side-by-side.  Just a thought.

    I'm open to contributors.

    BTW, I really appreciate your comments.


User Name: