I've got an upcoming project that is going to be dealing with 70,000+ users (education). I was wondering if the ASP.NET SqlMembership Provider has been used at such large capacities? Assuming the hardware is there, is there anything special that needs to be done to make it work smoothly? We're doing all the obvious things like separating boxes for databases and applications, but is there anything code wise that I need to watch out for?
I know one site that, owner of this site wrote a brilliant article about asp.net performance(http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx)
On this article there is one subject that author describes a patch about profile provider for higher performance. Please read that section.
Inbuilt SqlMembershipProvider is very reliable and workable. They tightly integrate with FormsAuthentication and Login Controls. So authentication is reliable and it is also quick to implement.
Only problem I see is the complexity of the Database table structure, they are quite tidy and not so straight at first. So you can basically write your own MembershipProvider that will talk to your own users table with more simplistic design and implementation. Also Managing Members on admin is also painful due to table design but in a way it is fairly possible to do so. For these reasons we wrote our own MembershipProvider based on Sql. It's working amazingly and we've had good experience of the same.
If you have a small website or project
you can straight go on with inbuilt
SqlMembershipProvider but for a large
project like yours I'd recommend
writing your own MembershipProvider.
Related
I support a legacy webforms application with SQL backend and have been trying to upgrade it bit by bit
I have upgraded to .NET 4.6 (highest the hosting provider allows), added some jQuery, EF 6 goodness, refactoring in general and attempting to switch to code first from database first edmx, my next plan is to start creating new features using some kind of front end library like Vue.
But...
My problem at the moment is Membership.
It is used throughout the code and statements like
new Guid(Membership.GetUser().ProviderUserKey.ToString())
are literally too many to bear.
And the database has 10 tables and 9 views for it.
vw_aspnet_Applications
vw_aspnet_MembershipUsers
vw_aspnet_Profiles
etc..
The application is using it for authentication and for keeping track of which user is doing what.
Is there a way to upgrade that to a modern solution without much hassle?
I can take the effort out of my own time but I'd prefer a solution that is not overkill.
the amount of users is probably less than 20 so the alternative doesn't have to be complex.
It just has to support most of what Membership is doing.
I've played with Auth0 for a bit in my own time but it seems to be not suited for this.
There is MS Identity as well but I'd prefer to take advice before going into a rabbit hole.
Thanks!
Definitely no simple upgrade. Here's what we did in our case.
Created ASP.NET Identity tables. We made it similar to Membershipusers table and later migrated the whole table.
Added ApplicationUser, ApplicationRole,ApplicationUserManager , ApplicationSignInManager, ApplicationDbContext
Implements Autofac for DI defined at Startup.cs.
Worked on Login/Signup Controller classes.
Finally migrated the whole Membership DB to new aspnetusers table.
Application was initially designed using NOPCommerce (asp.net webforms) and its was relieve to replace Membership.GetUser().ProviderUserKey.ToString() to User.Identity.GetUserId()
Hassle free ? Do you mean easy path (or) scalable path ?
Design is more an opinion rather than objective. It's mostly based on the facts one know about the problem statement. Based on your's i would recommend the following.
Separate all the membership related code into a library (if not already done)
Now write interfaces that will abstract the actual authentication mechanism from the member ship related code in your project. That way your code doesn't need to be changed for any authentication related mechanism. This wouldn't also require change of database schema.
Now for real authentication use something like Auth0 (https://auth0.com/blog/add-auth-to-native-desktop-csharp-apps-with-jwt/) something like this will be easy to implement. But i don't know if your's is a commercial project / how the licensing will work. I know there is a free version for auth0, but i request you to check it out.
I know there's tons of questions about .NET based CMS out there, but I have some specifics things I'm looking for.
1) Be able to leverage our application's existing authentication (We have our own implementation of of System.Web.Security.MembershipProvider as well as MembershipUser)
2) Be able to restrict who can view certain pages/segments based on our custom roles, in addition to restrictions on who can edit them.
Maybe most of them support this, but I haven't had much luck finding which ones specifically satisfy these requirements.
(Being lightweight is also a plus, I've read about Orchard and N2)
I don't know how much this will help you but here goes. We did a search last year for .NET content management systems and I wasn't super thrilled. There are a ton of commercial systems that are really expensive and appear to be crap.
I checked out N2 first. It seemed really clean, but it was way too barebones for our purposes. We would have had to do a ton of custom development to meet our needs. It's really a CMS framework instead of a CMS product.
Umbraco was the other system we took a serious look at. It has a lot more features built in and it's a fairly nice system as long as you don't mind a little XSLT. It does use the standard membership provider framework, so that's in your favor. I don't really know whether the roles will do what you want though. But since it's free you can play with it to see if it meets your needs.
As for Orchard, I don't know much about it. It wasn't around when we were looking, but it seems interesting. I couldn't tell in a reasonable amount of time how it handles membership and roles on the back end. It does seem like it's geared towards smaller sites, so it might be a little limiting in that respect.
We've been using Telerik's Sitefinity product with custom forms authentication. You can use forms authentication out of the box or you can customise it. It does make use of the provider model too.
More information on custom authentication can be found here.
I would suggest looking into AxCMS (at AxCMS.net). It is complete, pluggable and has extensive documentation. Specific documentation about their implementation of Membership and Security is available at : http://help.axcms.net/en_help_concepts_security.AxCMS
Microsoft's Scott Gu recommends it here at http://weblogs.asp.net/scottgu/archive/2006/02/02/437220.aspx
EPiServer is a commercial ASP.NET based CMS. It is essentially a set of .NET assemblies that you reference and build into your ASP.NET application to turn it into a first class CMS.
It makes use of standard ASP.NET features like the provider model so you can swap bits out.
Through a lot of sticking my head in the sand, reinventing the wheel and general stubbornness, I've managed to go all this time (years) avoiding learning the built-in ASP.Net support for web application authentication, users and roles. Part of the reason is that rolling my own originally seemed like less work than getting my head around all the different layers of optional abstraction provided by the ASP.Net security framework and as such I came up with a nice library that worked fine for me.
I'm now trying to go back to using as much of the built in functionality of ASP.Net (MVC2/3, not WebForms) as possible, as I've found that the more non-standard functionality you build into an application, the harder it is for other developers to pick up your code and work with it.
The web is thick with half-tutorials, badly explained articles and information that excludes important beneath-the-hood information about the ASP.Net security framework.
Are there any good tutorials that rip the lid off ASP.Net security and show you how to use it and how it all works without trying to push you through wizards and specific provider models without understanding all of the options and their pros and cons?
This is a 18 part series articles from Scott Mitchell.
It's a very deep explanation of all the features that regards Authentication, Authorization and Membership providers in asp.net. I did never found a better source on this from the same author.
MSDN is the best for ripping the lid off: http://msdn.microsoft.com/en-us/library/ff647070.aspx
I am currently converting a very old, but working classic ASP site to ASP.Net.
It has a completely custom written user management system. Whilst it works fine, it really needs a refresh as I want it to be more flexible for some future projects in the works.
When I asked someone about this, they said "You need to use the Microsoft Provider" and gave a lecture on how Microsoft release all these things for free and how good they are and should be re used as much as possible.
I have done quite a bit of research on it (mainly looking at the videos on http://asp.net/learn ) and am very impressed by some of the features as there appears to be drag and drop components for items that would take me ages to write.
However, the current membership database is complicated to explain, it is a completely custom written database that has many internal relations... It is not really "compatible" with the default Microsoft Provider.
I have taken a look at How Do I: Create a Custom Membership Provider?, but I feel a little out of my comfort zone and worried it will either be slow, introduce a security hole or simply won't work.
At the end of the day, the Microsoft Membership Provider should work for me - the only customisations I really need is the login to use the username/password field in my database and the create user script which has a lot of custom code to several third party systems (needing to provision services etc.).
I was just wondering, what would you do if faced with a similar situation?
Use the Microsoft Membership Provider and somehow get it to work for you (although I would like suggestions)
Use the Microsoft Membership Provider but use custom provider that is customised around your code.
Use your own completely customised solution?
That video does complicate things :) If you're going to implement a custom provider then reflector over the existing one is a good place to start :)
As a quick and dirty option you could, of course, hack the stored procedures that the SQL Membership provider uses but the custom code to provision services is probably stretching that.
If you think about it the remote provisioning of services doesn't really belong in a membership provider, it's not really a membership function - all membership does is provide usernames and passwords and authentication around them. My own feeling is that you should move the provisioning of services out of there, and perform it on the ASP.NET site after a user has been created - even if that's just calling a stored procedure once the membership provider has done its thing. If you do this you may find that the SQL membership provider will do everything you need it to (probably with the Roles & profile providers too), and thus you have way less code to write!
I've been in similar situations in the past. In both cases we created custom implementations of the providers (MembershipProvider, RoleProvider, ProfileProvider) around the existing mechanism.
In both cases we only used the provider implementations for read-only access, e.g. to give us the easy validation gubbins in web.config and suchlike. The user administration code was left well alone as it worked just fine.
If the existing provider works (has the right fields for your data), use that to start. You can VERY easily replace that with a customer provider later (just a single config value change).
Beware there isn't an "out of the box" ASP.NET management interface for that, you'll need to roll your own or use a third party one.
Use my specialized MembershipProvider to work against my own database tables.
Fairly new to ASP.NET's membership roles and forms authentication, it would seem that this would save more time and effort for my implementation.
But, I would also like to know if it comes in all goodness or does it carry any extra baggage (cons) in terms of:
Performance
Scalability
Thanks in advance for your replies.
I have never had a problem with performance or scalability with the default providers. Here are two tips that I've picked up along the way.
If you are using the providers and hashing passwords in a load-balanced setup. You will have to specify your machine key in the web.config
By default, users roles are not cached so every time you need to check a user role, you will make a round-trip to the DB. Using the cacheRolesInCookie="true" attribute in the tag in the web.config will cache them for you.
I've used the SQL Membership providers in ASP.Net in many large scale web applications and have never had any issue with it.
In our current application we've had to add extra fields and we expose these using an extra API.
Optimize ASP.NET Membership Stored Procedures for greater speed and scalability
Short answer: no real baggage in terms of performance and scalability. If anything, the real baggage is in terms of testability and portability (gobal static singletons are bad), but you can code around that.
It will probably work just fine, you can always switch provider or write your own later on.
I've written a provider that works as a layer between the ASP.NET authentication system and POCO classes together with a repository and nHibernate, that way I can let users login and get authenticated the ASP.NET MVC out-of-the-box-way, yet have the users and roles as any other model/view/controller in my system. Also by using IoC and interfaces I can use the exact same provider in different projects that handle users in different ways. Yay. Strange though that something like that didn't come out of the box.
If you use the default providers then it can be quite difficult to do things like search or filter users or do admin-type things, since you can't (easily) query the database directly. You have to go through the API, and it's quite limited. So, if you want to produce a lot of reports on users, be aware this is not easy to to efficiently.