I am in the process of implementing my own solution to my problem.  My requirements were too advanced for any products available...  i quickly realized just how complicated the whole idea is to implement.

It looks like there are a few solutions out there that will assist with allowing multiple parent portals to share users; but I ended running into two problems that those solutions did not solve:

1)  I want users that are logged into www.domainA.com and then browse to www.domainB.com using the same browser session to not have to log in again.  This is very important for my requirements.  Existing solutions would allow for the same username and password however would not implement cross-domain logons.  This entire project became very large very fast.  Cookies cannot be transfered easily from domain to domain.  I ended up having to come up with a clever solution using iframes, webservices, javascript, and advanced business and data layers to manage this process.  At this point the solution has been bench tested but not production tested.

2)  I realized that my concept had a security flaw in it.  Eventually I want to allow non DotNetNuke applications, or even a completely separate install of DNN on another machine to integrate with the system...  I may or may not trust the people setting up the services that use my service.  I realized that in order to prevent malicious phishing as effectively as possible, as well as prevent untrusted participants on my system from saving passwords they shouldn't have acess too - I would need to redirect users to a single sign-on webpage that always had the same URL.  That way durring registration and logon I can remind users to ALWAYS check to make sure they were giving their username and password to the Trusted SSO service, and not any other websites...   on the backend the SSO service then looks up a unique portaluser password per site; stores that information into an encrypted cookie using iframes and some backend webservices for the webservers to talk to each other - and redirects the user to the site they wnated to log into...

This all turned into a huge product, but was very important for me to solve because the different sites that use my SSO actually compete with each other, and manage their own user rights; so I needed to make sure to protect the user password from the participating sites themselves.  My live SSO site is going to be at www.SkydiveSecure.org; however while i have a mostly working solution on my private servers, I have not updated that URL in a month or two.  I expect to be going live with it before november 1st.

Unfortunatly, the project has become too large a scale for me to be able to effectively "shrink-wrap and distribute" without spending a lot of time in making it user friendly.

Based on all that's involved, I would be really supprised if the DNN core were to implement anything like what I described above anytime in the next two years..  It's actually pretty darn flexible already.  Using the provider model made the DNN part of my work the easiest.

If you're hurting for the functionality that I described above badly enough that you're going to have to write it yourself if you can't find someone to offer you a package; you're welcome to write me at mattchristenson at realskydiving dot com.

If you do pick one of the existing solutions out there, be advised taht a few of them have a problem where user password changes do not get properly propigated from portal to portal..  i forget which ones, but it's a pretty serious issue that you may not even realize is an issue until when you think you're close to done.

good luck.