Kennster,
Off the top of my head I wasn't sure, so I went back through a couple of posts in the benefactors forums that Charles (who's making all the membership changes), and a few benefactors have had on this area. I've cut and pasted a few key pieces from a variety of posts below, the hyphens seperate the posts(hopefully the people who originally posted them won't mind my theft *grin*):
-------------------
To summarise, the expected behavior for Users in 3.3/4.1.
A single user can be a member of many portals in the same way as they used to in 2.x.
There is a single entry for the user in the Users table and corresponding aspnet_Users table.
UserPortals controls their membership in each portal.
UserProfile controls their Profile - which is different in each portal.
-------------------
History of dotnetnuke user's
In DNN 2.1.2
All user data was stored in the Users table.
The authorization flag was stored in the UsersPortals table. This makes it possible to authorize users on a per/portal basis which is ideal.
It made sense from the user's perspective. If I log into portal A and change my address, I don't have to log into portals B, C and D to make the same change. It behaves like a single account.
In DNN 3.1,2/4.1
The Whidbey Membership providers were used. Each portal had a separate set of data. It made sense from a user's perspective each account was completely isolated.
It behaves like separate websites. We created *product name removed* to support single-sign-on, the best of both worlds.
In DNN 3.3/4.1
This release is somewhere in the middle. Some information is shared such as username, displayname, I guess first/last name, email address. Other information is stored per/portal, e.g. address, phone, etc.
Does this make sense to the user?
I can login to portal A and B using the same username/password.
If I change my email address in portal A, it will be changed in portal B. But if I change my address in portal A I have to change it in portal B too.
If I hide my address in portal A it may be visible in portal B. I
If I change my first name in the membership section it will update in both portal A and portal B. If I change my first name in the profile section on portal A it won't update in either membership section and it won't update in the profile section on portal A.
Conclusion…
Splitting the data will confuse users. It will also make reporting difficult for administrators. There won't be any good way to aggregate user information across portals. Is the address correct in portal A or portal B?
I don't think the current implementation is sufficient to share users across portals.
Recommendation:
Super User account data is shared across portals and it works great!
Why not share data for all users?
The host defines the properties shared by all portals. These would include all the standard default properties like name, address, etc. The portal admin defines portal-specific properties.
I don't think there's any technical reason a user can't have both global and portal-specific properties.
-----------
there is a reason for the DNN 3.3 behaviour: the new user profile can be customized per portal, which is of value in a multi-portal environment with independant portals. You are right, that in a scenario with SSO a common provile would be preferable. It looks like there is a need for both: shared and portal individual properties. It would be preferable, if the concept could be extended, so the user profile is a combination of host and portal properties.
--------
We are dependent on the behavior of a 3rd-party component (Memberbership) that is really designed by MS for single portal envirnoments.
With the new abstraction of the provider, it would be possible to create a new concrete provider that works around these issues.
The request for single sign-on capabilities (which in effect this is), to revert back to how it was done in 2.x has been a pretty vocal one from the community.
We will review these issues, and see if there is a soln which can achieve both goals.