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 this relates to lack of exposure to alternative ways of thinking or projects of sufficient scale to warrant significant investigation.
I’ve been a .net net developer for a number of years (and before that php and asp classic) and typically when developing applications I shy away from using the built in .net SqlMembershipProvider primarily because it often seems significantly over complicated for my needs, and secondarily because I can only imagine such a complex data model will likely have a performance hit.
Typically I use a custom membership and roles provider operating on a fairly simple user -> user roles <- roles type schema. I maintain the standard membership provider features such as account recovery, profile details, failed login account locking, secret questions, etc depending on the needs of the associated application such as an AD secured application has few additional features, a public facing application will usually have them all. It also means should any tasks that come up which require stored procs to chew through user data they’re easy to write and perform very well. Straight SQL commands, good indexing and a simple data model resulting in a high performance, scalable solution which should needs change I have full control to change as necessary which I considering invaluable.
Based on your experiences would you say this is an outdated approach? Have you ever had any scalability problems with the built in provider? What approach do you generally take and in what scenarios?
Thanks
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.