Hi there,


I was wondering if it's possible to replace the DNNProvider with a custom one without breaking future updates.

I don't know if this is the best approach, but if someone wants to give it's opinion, please be my guest.

What we are trying to do is have a centralized Database to manage users and roles that work across multiple portals. That database would be the replication of some tables of the DotNetNuke database (mainly users and roles tables).
The user and role management would be made within the website, where the Host can see all the users.

The reason for this is that some of the users are the same across portals, and if we simply duplicate the user for multiple portals, we don't get a centralized management of the user (for example, if the user change his password, he must change within the 2 portals).

Our idea is to break appart the user management from the DNN portals so that it can be reused by other portals, but still get all the membership management that DNN has to offer.
Beside this there are other tables that relates some info for each user.

Hope I was clear enough, so someone can help me out pointing the right way.


Thanks in advance!

Hi Mitchel,

Thank you for your feedback.

I guess will stick with creating only a custom authentication provider.

We will implement individual instances of DNN and not child portals, and share users between them. If we customize membership too, we'll loose the authorization and module/page security that DNN offers.

Afterwards we'll think in developing a central administration to manage all the portals.
We may have to append more individual instances if this implementation goes well.


Best regards,
João