I'm hoping for some feedback on the plausibility/sanity of the idea.

We are a non-proift that uses a tool named Raiser's Edge to manage all of our constituent's data.  Who has joined our organization, when they expire, etc.

We are using DNN 4 for some of our sites, and we are considering moving the aspnet_ tables to a separate database server. We would have a sync app that would update role information based on membership data in our constituent database, (Raiser's Edge), and make sure that the users in the aspnet_ tables that mapped back to entries in Raiser's Edge had the proper roles.

For instance, if a member's record in Raiser's Edge indicated that they were a member, then their record in the aspnet_UsersInRoles tables should also indicate that they are in the role we are using in DNN for members.  The sync app should make sure this is the case, and would run once per day.  Thus, when they login to DNN, they can access members only pages.

However, upon inspecting some of the internals of DNN, it looks like DNN also uses some of its own tables (e.g., Users, Roles) in order to track user data.  Our sync app would have to update these tables as well, I take it?

What is the reason for multiple tables?  Is this a design that we should expect to stay (and anything we do should expect accomodate it indefinitely), or is it something we should expect to go away as DNN develops, and we will be left with everything being stored by the providers?

Also, what do others think of this plan?  So far my investigations into this make it seem quite plausible, but I'm looking for feedback from the community.

We've considered writing our own providers (membership, roles, etc.), but have received substantial discouragement from the community, as they've told us that things are "going to change" in the next release of DNN (although nobody knows when that will be).

Which begs another question: if we implement the idea I am suggesting, are we looking at substantial changes to our sync app once the new release of DNN comes out?  We're hoping we're avoiding big problems by doing it this way, instead of trying to write our own providers.

Posted on forums.asp.net as well, although I suppose the preferred place to respond is here.

I've spent the last couple of hours searching for a module that does just that - syncs DNN members and users in an external database.

I've found lots of posts about how to custom develop this type of authentication, but nothing that's anything close to just installing a PA.

I'm thinking this should be an enhancement request for DNN core itself -- the ability to authenticate with external sources.  As an example of the functionality that most people seem to be looking for:

1. Give database connection information

2. Give a table name

3. Match the DNN columns needed in the DNN tables to the columns in the external table

DNN then authenticates against the external database, then syncs user data with DNN tables.