brian wroteI thought I posted last week on this...
Brian .. are the UCanUse SSO modules not working with 4.4+?
I thought at one time (recently) you were working with the core team on developing an updated solution?
I also thought the core team had SSO across portals on the roadmap?
UCanUse User Attributes, our custom registration product, has been updated to work with the new DNN provider models. UCanUse Portal Mapper (which supported SSO and portal groups for DNN 3.0/4.0) is not compatible with DNN 3.3/4.3 and higher. We participated in the 3.3/4.3 beta through the platinum benefactor program and offered feedback regarding the new DNN provider design. However, we never worked with the core team to upgrade Portal Mapper to DNN 3.3/4.3. Portal Mapper consists of a customized Membership and Profile provider (ASP.Net 2.0 providers). It works by mapping portal-specific application names e.g. dnn_0 to admin-defined application names. This approach is completely incompatible with DNN 3.3/4.3.
The problem with the new implementation…
DotNetNuke MUST be the owner of all user information. But what if I don’t want DNN to manage my account information? Consider this use case scenario…
Our UCanUse website runs on DotNetNuke. I’d like to expand our site as follows…
- I want two separate DNN installations, not necessarily the same versions.
- I want a separate (non-DotNetNuke) ASP.Net 2.0 application
- I want all web applications to share membership/profile information. I don’t care if each app maintains its own roles.
- I’d like to keep my membership information in a separate database providing easy: backups, ability to do a clean DNN install
This scenario would have been possible with DNN 3.0/4.0 (perhaps with some minor modifications). How can I accomplish this with DNN 3.3/4.3? This isn’t a rhetorical question, I really need an answer.
Thanks,
Brian