I'm having trouble wrapping my brain around the DNN membership provider and how to replace it with a custom membership provider. I sure hope someone out there can help me.

We have an ASP.NET 2.0 application with its own very simple membership provider, storing user info in a SQL database, and we would like to build DNN sites that authenticates against the other application's users. We don't want to replicate data and/or manage user data in multiple data stores. We just want these DNN sites to use the custom application's users.

So, first of all, is this actually possible? I've read in some places that even with a custom membership provider, the user data has to be replicated in the DNN database.

Second, how can I do this? Do I need to replace the AspNetMembershipProvider or the DNNMembershipProvider? Or both? What about roles? Or maybe I don't even have to mess with the membership provider if I just use a custom authentication provider. Would that work?

Any help whatsoever would be greatly appreciated. Thanks!

Tim

Thanks, Brian.

Unfortunately, the no-replication requirement is not something I can change. And I'm trying to do this in DNN 4.4, BTW. We really want to take advantage of the latest version for this project, because we want the reliability and performance improvements.

I have been able to use Henry Kenaum's article on the Engage Software website to replace the AspNetMembershipProvider with a custom one that really does exactly the same thing. But when I try to hook it up to the other database, I get problems. Still need to work through those, but one thing I can already see is that it still looks at the DNN db for authentication.

If you want to replace the Membership Provider, Roles Provider, and Profile Provider (a huge pain in the ass) you will be able to get away with not duplicating data in tables, however it would make a lot more sense for you to create a membership provider that maintains both the DotNetNuke architecture, and your own architecture.

You can use the ASP.NET provider as a perfect example, because that is exactly what that provider does - integrates with the ASP.NET Membership provider while also updating the DNN tables.

Be aware that you will both have to create the providers and also replace the HTML modules... don't forget about the HTML Modules like I did and wonder what's not working :)

Having done all this: Your work will become a lot easier if you can be assured that the DisplayName and Username will never change.

As far as simplicity: Replacing the model is no easy task: Expect to spend about 80 developer hours if you're an expert .NET developer with moderate DNN experience; or ~100 hours if you have no DNN experience or experience working with provider models and HTML Modules.This project is by no means a project that someone who is newer to .NET should attempt to tackle; 

Part of this time will be affected by questions like: Will you allow users to change passwords in DNN?  If the answer is yes - you need to make sure to fill in all of these methods...   If the answer is no, you're going to be making some custom login forms and a custom manageusers.aspx to accomidate the 'broken' stubs - unless it is okay to release a product where you tell your users "Don't do this - that will break things..."; but this is rarely the wise move.

If done right - you can be sure that most core DNN upgrades will not cause problems; I haven't seen anything in the roadmap that would cause the membership module signatures to have to change and break compatability.

Having done work like this before, if you are interested in hiring out the project; I do have some open time coming up :) mattchristenson@realskydiving.com