I am developing a set of modules for some organization, that would deploy them across multiple related portals hosted collectively. Although the portals will have their own users, but if there is any common user on 2 or more portals with same username, he/she needs to have a unique profile across portals.

Moreover, all portals need to have same Profile Property Definitions. If a Portal Admin add or modifies a property name, it should propagate across portals.

There are 2-3 ways to achieve this, in the custom profile provider being developed.

The first one was to set all Definitons as System Definitions when being added & set their PortalID to -1. Would that resolve the issue??

The second one is to have a dummy portal at ID 0, which would never be accessed. However, whenever Profiles or definitions are being added or modified, the Provider can route all operations to Portal 0 definitions.

The third one is to have a normal Portal at 0th position & still route all Profile requests to it.

Which one is the best option??? And is there any better???

I mean I need to design the Module myself, for better integration with the rest of the modules. I was just looking for an advice on the best way to do it, while maintaining maximum compatibility with DNN core.

The way I plan to do it is to prepare a custom Provider. That provider would map all Profile requests for any portal to the default 0 portal when sending into the database, and on the way back, it encapsulates the resulting IDataReader in such a way that all other fields are directly passed on from the base DataReader, but PortalId field is mapped back again to the current portal id, in which the custom provider is executing.

Is there any chance of some issue with that approach?? Or is there a better approach???