RFC: Future of User Data

[sleupold]

Description of Problem

DNN currently uses a single user object for all sites within a multitenant instance. There is one user with ID, Login Name, Display Name, Email address, first name and last name, shared by all sites. Besides, each user has membership to (each or specific sites) and a profile for each site (containing individual first name and last name as well)

There had been frequent complaints about same user might not be created for a second site, unless using same credentials. And modifying first or last name does not get properly reflected (affect current site or all sites???) - while updating other profile properties affect current site only.

Proposed Solution Option 1

sync FirstName and LastName across all sites within installation (like DNN 3-5.5). Any change will affect all sites, as user.FirstName and user.LastName become "master" again.
Implementation should be trivial.

Proposed Solution Option 2

generalizing solution 1, we may sync across sites all profile properties with same name and data type, i.e. if a user updates his address, it will automatically affect all sites. This may also been applied to superusers as well to avoid special treatment of them. we may add a host setting "syncUserProfiles" to enable this feature.
This will not cause significant effort to implement

Proposed Solution Option 3

decouple user profiles from sites. Each site (or mastersite of a site group) gets its totally independent user profile, user objects are site specific and a user "myusername" from site A does not share anything with "myusername" from site B.
This will cause the biggest effort and may fail, if 3rd party modules didn't place an FK on users table.

Proposed Solution Option 4 (half way 3)

don't touch current user object (including aspnet_users and aspnet_membership), but move properties "DisplayName". "FirstName" and "LastName" to UserPortals table (maybe extended by prefix and middlename). The formula to (optionally) construct the displayname from firstname etc. nees to be moved from HostSettings to portalSettings as well, allowing it to be defined per site.
In a multi-tenant DNN instance, this will keep the constraint that a user can only register to a second site with same username and email address (or just email address, if it is used for login) using the same password, but may used different first name, last name and display name, and if he decides to leave one site, these information may get obfuscated (or deleted). We are still open to implement the feature of syncing names and profile properties, if desired. This may cause compatibility issues, if 3rd party extensions rely on the current data structure.
Note: I would not move the names only to the properties table, as this table is not really efficient for retrieving the values. We could also add a "calculated" profile data type, which generates its content from other columns of users, portalusers and userprofile tables instead of relying on names - as a default to be edited or readonly.

Alternatives Researched

There are pros and cons for each option, the biggest con to option 3 is the risk to fail upgrade for 3rd party modules. IMO option 2 would provide the best benefit for current users.

Affected version

• 10.x or later

[MaiklT]

To give my two cents: I think that solution option 2 would be the most "logical" enhancement, but there could be some problems with the GDPR (also with solution option 1) as well, if a user wants to get deleted from one portal, but not from the other. What happens when he is removed from that portal, but his userid is still somewhere in a comments section or a forum - will his name still be displayed? There is a need to accomplish this, or a solution where users and portals are strictly separated.
I have once worked for a bigger organisation that has setup different portals for different projects, something like a.organisation.xyz, b.organisation.xyz etc. The biggest issue was that when a user, who was already registered for project A and wanted to register for project B but using a different password (which is respected as a good practice) got confused, because he got a message that this user already exists. Most of them went on and choose a different username, and created a second, third, etc. login. This was definitely not the intention.

[mitchelsellers]

Overall I like the behavior of Solution 1, as that has the least impact as the user is still in control of the visibility etc. If we expand this to other fields, I'm a bit concerned that with Option 2 we would get into a situation where a user could have something that was "private" on one installation and public on another etc. It sounds like you might already be thinking of this, but just a through.

[roman-yagodin]

Vote for Solution 3 as most simple and bullet-proof. Some things will break, one way or another.

[KenTombs]

I would follow MaikITs thinking that data privacy has some potential horrors here, and this will follow through all future legislation even the US' I believe. The user is central to everything and if that person makes a subject access request, some poor admin will have to manually look at all 'Fred Bloggs' on a system and decide if they are the same person. Imagine that with 100,000 users! If a person's name is on a forum entry then that's open for discussion in the portal's privacy policy as deletion doesn't necessarily mean redaction. Pseudo naming is a whole other bag of worms.

Go for the single user record with access to portals as necessary. Whether what they have is public or private content makes little difference in practice, its what you hold that is important. You just must not mix up users even if they share the same name, thus creating an inadvertent disclosure of someone else's data. Not so much a problem for employees of the same business, a nightmare if the platform is public.

[roman-yagodin]

I have once worked for a bigger organisation that has setup different portals for different projects, something like a.organisation.xyz, b.organisation.xyz etc. The biggest issue was that when a user, who was already registered for project A and wanted to register for project B but using a different password (which is respected as a good practice) got confused, because he got a message that this user already exists. Most of them went on and choose a different username, and created a second, third, etc. login. This was definitely not the intention.

I think this case could be resolved using external authentication systems, like AD. Just not "using a different password for every project" in the same organisation, of cause 😄

[MaiklT]

I think this case could be resolved using external authentication systems, like AD. Just not "using a different password for every project" in the same organisation, of cause 😄

No. Because most of the users were not members of the organization itself, and therefore not "objects" in the AD. And you can't force people to use Facebook, Google or whatever authentication.

[roman-yagodin]

I think this case could be resolved using external authentication systems, like AD. Just not "using a different password for every project" in the same organisation, of cause smile

No. Because most of the users were not members of the organization itself, and therefore not "objects" in the AD. And you can't force people to use Facebook, Google or whatever authentication.

OK, it looks like special case for me - and as with all special cases we need solid (read "simple") base for third-party extensions which would provide solutions for different cases. I think it's not very hard to implement some kind of sync between different user profiles by some matching field like email - if it really needed.

Still like to see more love to site groups in DNN... For solution 3, it's likely better to have different account types for single site and site group.

[sleupold]

@MaiklT, @KenTombs, @roman-yagodin
Regarding privacy, we are in the same situation now: if a user registered for multiple sites using same username and passwords, his displayname, first name and last name is shared and can be retrieved in forums etc. from users object, where the information is still needed for the other sites, he is still an active member of. A module can check for userportals.isdeleted or the record existing, but this is not under control of DNN and I fear, a number of modules will miss this requirement.
I added option 4 above. where those fields would be moved to userportals table, i.e. become site specific. This will not affect login name and email address (which should not been displayed to other users anyways), but in alternative 4, the display names could be obfuscated or erased per site.
However, if you are using public registration on multiple sites with email as user name, the user can register only to a second site, if using the same password or a different email address.

[sleupold]

@mitchelsellers
when syncing the properties in option 2 or 4, we would for sure not touch visibility settings of the properties and might not sync, if there has not been a value entered before. Besides, this should be an option, the host may enable for superusers, admins or all users,

[sleupold]

IMO, this is the general question: how many DNN instances are used for multiple sites with public access targeting different audiences (i.e. without using site group feature) - and how big is for these sites the risk of same user trying to register? if the sites are totally independent (e.g. shared DNN hosting), the biggest constraint currently is registration being blocked, if email used for login and the address is already used in a different site. This can only be solved by option 3, otherwise individual DNN instances should be used.
If, on the other hand, users are aware that the sites are somehow "connected" (same owner,...), they would expect updates to their profile affecting all sites, not just the current one, which would lead to option 2 or 3 with syncing the profile.

[sleupold]

PS: if we are not implementing Option 3, we should at least display a hint to a member of multiple sites, when he updates his user name or password ("Your account data has been updated. Please note, this affects your membership for domain1.com and domain2.org")-

[valadas]

This RFC is still to keep right ?

[mitchelsellers]

Yes, we need to get someone to lead the implementation on this one.

[dbacher]

Each tenant needs its own credential set.

The fact you have previously logged in to Example Corporation, should not impact a log in to Unrelated LLC. ASP.NET 2.0's Membership and Profile provider use the application ID for this, and if you set it up correctly - the versions of DNN that use the membership providers would just do the right thing here and keep the data separate.

And no, I don't set them up that way either.

However, if you;'re looking at GDPR - it would be all sorts of thorny that when you logged into Unrelated LLC, all your profile fields magically appeared because you previously had signed on at Example corp.

There's all sorts of other issues, too. Imagine a corporation is working with a freelancer, now they go to another corporation - you're going to share their access control, etc. and that's probably not the right thing to do.

If you are going to multitenant in the software versus pushing towards a solution like Docker for that case, then I think you have to go with Option 3 or 4, or introduce a tenant ID and use that in place of the portal ID for this. (that is a better solution than 3 for multitenant situations, particularly when hosting for corporate IT).

If you remove multitenant support entirely, and force them to use IIS or a solution like Docker, that fixes it as well - at least in theory. But if you share globally across unrelated tenants, that's a significant issue in multitenant where the tenants do expect their data to be completely logically separated from everyone else's.

And it causes all sorts of problems with data portability as well - say that someone wants to bring their data to your service, if they can't extract their users in isolation - that really sucks badly. Similarly, if someone wants to leave your service and take their hosting elsewhere, or even if you just want to move to another database for performance reasons, it's a huge freaking pain if it isn't per tenant or per portal.

Just saying.

[mitchelsellers]

@dbacher all great points. For sure a heck of a lot of work and a very breaking change, but something to consider.

[stale[bot]]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[sleupold]

this is still valid and needs to be turned into a bundle of action items.

[stale[bot]]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[MaiklT]

this is still valid and needs to be turned into a bundle of action items.

[thabaum]

I have thought long and hard on this topic. I believe I have created a number of issues in the past that are directly related to this issue being discussed.

I believe that in my mind each registration or user should be considered an object. That object is part of one portal or a master portal (site group) either way another object. When joining sites together a master portal is created. This should be the portal each user is registered to a site that gets added to a site group should then have that users registered Portal ID link to the master portal for all users so they sync with the master site portal id. And a way to merge users possibly asking them to fill in the blanks as needed or select the information that best fits between the two when they log in possibly. If you ever remove a site from a site group you should then have options of which users you want to move if any to that site.

It would also be nice if security roles traveled with the user id plus site id and a master site security roles are added to all sites in the site group. So you can have "Content Managers" role appear on all and manage them from any portal in that site group.

The profiles should all be the same for a group and registration fields should align with master portal settings and those fields should be set across all portals for viewing profiles and updating user information.

The issue is the Unique Email that is set in the web.config. This needs to be set to a scope that is sites or site groups using a Unique Email per site or site group.

If you have this set in the web config you run into issues allowing people in a similar area of sites that happen to be on the same DNN instance is you cannot register or login on different sites or click on a verification link if in a site group.

This would definitely take some careful thought making a solution that can cure these user account issues.

This is my two cents hopefully some of it makes some...

[valadas]

Testing a comment

[stale[bot]]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[MaiklT]

Still an issue.