I've been working on creating a custom DNN membership provider which will have the user table contained in another db but maintain the user joining tables (UserPortals, UserRoles) in DotNetNuke.  I am running into the following problems:

1.) Little to NO documentation on creating a custom DNN membership provider

2.) I'm not sure if DotNetNuke.Security.Membership.Data.DataProvider abstract class is used in more than just the configured MembershipProvider.  With the reflection use throught DNN I'll have to look through all of the code to find out who uses this class and if this class is required for a membership provider implementation.  I've already found the default role provider does use this.  This has a major impact on my design.  If I can just implement a custom DNN membership provider then I can encapsulate my logic into the membership provider and not have to worry about a static datalayer class.

3.) Why are the base DataProvider.GetInstance and static constructors pretty much hardcoded to SqlDataProvider?  I want to use the other SqlDataProvider for everything besides membership so I can't  change the DefaultProvider attribute on the data node.  But since this constructor is hardcoded to use reflection, irony anyone, to create the SQLDataProvider I will have to create a new static constructor on the concrete class.  Why not just add another property to the data node or to the membership node?

It seems like there are no extensibility points in the membership provider.  You pretty much have to build your db and code exactly like what is already done, which begs the question why even make this configurable and extensible.  My example should be a common hook, to have user data stored elsewhere and role data stored in dnn. 

So my end solution is as follows:

1.) Copied and pasted the AspNetMembershipProvider class

2.) Wrote my own stored procedure to insert users into dnn that specifies a userId.

3.) Rewrote the CreateDNNUser method to use the new insert stored procedure.  Rewrote the CreateMemberhipUser method to insert into my custom db.  Yes that is CreateMemberhipUser not CreateMembershipUser, result of step 1.

4.) Hardcoded the install SuperUser and portal admin accounts to int.MaxValue & int.MaxValue -1 due to some sweet logic in the install module that aparently thinks that if a a user id is less than 1 then it is an error. 

5.) Wrote a custom User screen using the UserController.

6.) Convinced the client that  Dot Net Nuke was a piece of junk and that all of their future projects should not even consider DNN.

Zambonilli wrote It seems like there are no extensibility points in the membership provider.  You pretty much have to build your db and code exactly like what is already done, which begs the question why even make this configurable and extensible.  My example should be a common hook, to have user data stored elsewhere and role data stored in dnn.

We are considering DNN for a huge switch over project but it is issues like this and the issue of pushing modules down through portals which may be the deal breaker for us.