SqlMembershipProvider vs a custom solutions

Question

I work in a small team of developers and there is no consensus on the best approach to do a number of core tasks, one being membership providers. Now I cannot be sure if thi

Answer 1

Unless you've specifically identified compelling reasons not to, I'd suggest you start with the SQLMembershipProvider, and tweak it as necessary.

We've found that the built-in provider gave us all the basics with practically no work on our part. There are so many elements to developing a good security structure, and it's easy to forget one of them, or simply to get lazy and not implement one the "right" way when you're rolling your own. Things like salted passwords and password resets via email come to mind.

Of course, the SQLMembershipProvider is no magic bullet. We've had a few circumstances where we needed to do something more complicated with authentication. But we were able to resolve these just by extending the SQLMembershipProvider, rather than replacing it. See my answer at What is a good way to extend .Net Membership to track user logins for more details.

We have not noticed any significant performance issues stemming from the SQLMembershipProvider, so I think playing the performance card is unwarranted. After all, how much time do your users typically spend logging in to your system? If all your pages load quickly, there's no real justification for writing all your own code under the (possibly mistaken) idea that you'll be improving performance. It's that dreaded "premature optimization" we keep reading about.

The Roles framework was far too simplistic for our needs, so we don't use it at all. But it hasn't gotten in the way, either.

And, as Hogan points out, you're far more likely to find developers that are already familiar with the way the built-in provider works, which means they'll spend less time trying to figure out your architecture and (hopefully) more time getting real work done.